crosscuttingconcerns

Posted by mgroves on May 14, 2012  •  Comments (0)  •  Tags: books

I have just signed a contract with Manning to write a book. Working title: Aspect Oriented Programming in .NET.

I am very pleased to be working with Manning, who not only has a good reputation in the developer community, but is also the same publisher who put out AspectJ in Action, by Ramnivas Laddad, which is definitely one of the top books on AOP to this day (albeit with a Java focus).

I hope to keep putting out some good blog posts on this site, but with this book and some other projects coming up, I probably won't be writing near the quantity of blog posts.

For those who helped me get this far, (you know who you are), whether it be a large contribution or small, family, friend, or one of my 140-character mentors, you have my eternal gratitude. But I probably won't see you for a while, since I now have to chain myself to a radiator near my computer in order to get this book written, written well, and written on time.

Posted by mgroves on April 25, 2012  •  Comments (0)  •  Tags: architecture

AOP is best used for cross-cutting concerns, which are often non-functional requirements. But what's the difference between functional requirements and non-functional requirements?

A functional requirement is a requirement about what an application should do. This is manifested in a form that the user can easily observe. Business rules, UI logic, etc.

A non-functional requirement is a requirement about how an application should work. This is stuff that a user typically doesn't see (and probably doesn't care about). Logging, caching, threading, etc.

So here's a quick exercise for you:

Which of these are functional and which are non-functional? Why?

1. Addresses should be US-only, ZIP Codes must be five digits
2. Every method call should log its own name and arguments to a text file.
3. When returning a list of Customers, only Customers the current user is authorized to see should be returned.
4. When submitting a new Customer, it must be put in a pending queue for approval by an administrator.

I'll post my answers in a later post, but feel free to leave your answers in a comment.

Posted by mgroves on April 19, 2012  •  Comments (0)  •  Tags: Weekly Concerns, ruby, decorator

Maybe this series will turn into an Every-Other-Weekly Concerns?

• The Ruby Rogues podcast discussed AOP in a recent episode (episode 46). It's a good idea to listen to the whole podcast for context, but they don't really start discussing AOP directly until about 28 minutes in.
• The proxy/decorator pattern gives some of the same benefits that AOP can give you. Derick Bailey blogged about using proxies and decorators in JavaScript.
• A couple of white papers for you:
• FeatureC++ and AOP - What's feature-oriented programming?
• AOP is Quantification and Obliviousness - "obliviousness" often has a negative connotation, but I believe AOP in a team setting on a properly architected application can free up developers to concentrate on adding business value without having function requirements slowing them down

That's it for this week. Have a great weekend.

Posted by mgroves on April 19, 2012  •  Comments (0)  •  Tags: .NET, attributes

Attributes in .NET are classes that derive from the Attribute class. Here's an example of an attribute as seen in ASP.NET MVC:

Attributes themselves don't actually do anything: they are strictly meta data. It's up to a framework or tool (ASP.NET MVC, WCF, PostSharp, to name a few) to interpret and use any code in or to infer any meaning from those attributes.

Attributes can have contructors, and you can use those constructors when putting an attribute on a class. But you can only use constant values (like a string literal, an integer literal, an enum literal).

You also can't use type parameters on an attribute, but you can use typeof() when using an attribute.

As I stated above, attributes don't actually do anything on their own. To see what attributes are applied, use Reflection. For instance, to get attributes set on a class:

Posted by mgroves on April 17, 2012  •  Comments (0)  •  Tags: Single Responsibility Principle, SOLID

One of my core motivations for using AOP is that it can bring the single responsibility principle to places that would otherwise be difficult or impossible without AOP.

To review, here's the single responsibility principle in a nutshell:

A class should have one, and only one, reason to change.

Why is this a good principle? I think that the ObjectMentor white paper on SRP [PDF] sums it up very nicely, but basically if you have multiple concerns in a single class, those concerns become tangled together. This isn't a huge problem until you need to make a change (which never happens in software, right?). If I want to change responsibility A, I now have to involve the code for responsibilities A and B (and C and D, etc). All these responsibilities are coupled. If I make a change, I could break the class in multiple ways, affecting every one of the coupled concerns (unless I have a good suite of unit tests, which is unlikely if I have a very coupled set of concerns).

To avoid coupling, a good rule of thumb that I use is to describe what a class does in one sentence. If I have to use the word "and", then it's probably doing too much, and should be split into 2 or more classes.

Examples:

• PersonRepository: this class persists person objects to a database. Check! There's no "and", so this class is only doing one thing.
• BillPayService: this class submits transactions to the payment processor and stores payment history in an audit database. Bzzt! It's doing two things. Maybe I should consider a PaymentProcessorService and a PaymentHistoryRepository refactor.
• AccountController: this class routes the user to the appropriate account views (and logs any invalid request errors). I'll stop belaboring the point and leave this an an exercise to the reader.

Next >>