Every once in a while, when advocating AOP, people ask me whether this programming technique is useful apart from stuff like logging, security, instrumentation, etc, etc.
Usually I answer that I wouldn’t know, but i do know that especially in enterprise application development there so many quality concerns similar to the above, that AOP can be considered just that and still very much is worth the effort.

Even though I usually take the easy way out, I strongly believe that AOP concept can be applied to more than logging.

In fact, one of the AOP examples that are often used is about a drawing application.

Consider the following object-oriented code:

 
Using aspect-oriented programming, the requirement above (updating the display) can defined separately from all the other functionality this fictitious application may provide.




Why is it so hard to come up with AOP examples that are *not* about our “usual suspects”?

Well, mainly because most of this is hidden in the domains you work in. Finding them requires knowledge of this specific domain and proper analysis and design. The domains I am familiar with are the generic requirements developers often face when writing software (logging, caching, security, exception handling, whatnot).

Eventually most of the domains have all sorts of requirements that apply to each other and can be separated from each other; helping us to make our designs clearer and structure our code better.