Back to VSLive! San Francisco Show Daily Home

email article printer friendly more resources

6 Myths of Aspect-Oriented Programming
Learn the truth behind the common misconceptions about AOP.
by Tom Barnaby

February 1, 2005

Note: Tom Barnaby is presenting "Aspect-Oriented Programming in .NET" at C# Live! in San Francisco, Tuesday, February 8. This content is from that session.

With the popularity of languages such as C#, Java, and VB.NET, object-oriented programming (OOP) finally has become the predominate method for describing and implementing applications. Even now, however, several other programming paradigms are vying for your attention. Of these, one seems to have found some momentum: aspect-oriented programming (AOP). As with any new concept, particularly one as radical as AOP, the volumes of hype and counter-hype can be overwhelming. As a result, inaccuracies regarding AOP continue to confuse developers as they try to understand its concepts, motivations, and application.

In this article, I'll highlight and argue against what I believe are the most egregious examples of AOP myths. Hopefully this will encourage more productive discussions concerning the viability of AOP while clarifying the concepts for those just beginning to explore the AOP universe. If you need a little AOP primer before diving into these myths, check out an interview with Gregor Kiczales, one of AOP's pioneers (see Resources).

Myth #1: AOP Replaces OOP
AOP certainly is different from the traditional object paradigm, but it's a solution to a distinct class of problem: the cross-cutting concern. This also happens to be a problem OOP cannot solve elegantly on its own. Therefore, AOP complements traditional OOP; it's a tool you can apply when OOP fails you.

Myth #2: AOP Has Few Applications Beyond Logging
Almost everyone who attempts to introduce AOP concepts uses logging as an example; it's the "Hello World" of AOP. Although those who have been exposed to AOP previously might groan at yet another logging example, the fact remains that it is the most effective way to teach AOP's concepts.

But logging is not the only, or even the most important, application of AOP. Look carefully at any large application and you will see an abundance of cross-cutting concerns: transaction management, usage profiling, resource pooling, policy enforcement, and role-based security, to name a few. Interestingly, many of these concerns traditionally are handled by application servers. Recognizing this, one J2EE provider, JBoss, is a strong advocate for AOP and has created an AOP-based application server framework as a lightweight alternative to a full-blown EJB container.

Myth #3: AspectJ is the Only Way to Do AOP
Usually, a developer's first exposure to AOP involves AspectJ, which is a Java language extension that provides for aspect programming. Although AspectJ by far is the most popular and proven AOP tool, it is not the only one. Several other tools have emerged that take vastly different approaches to implementing AOP. For example, the JBoss framework I mentioned previously does not require language extensions. Instead, it lets you create an aspect using an XML file and a POJO (Plain Old Java Object). Also, many .NET implementations leverage attributes to avoid new language constructs and provide AOP functionality to any .NET language.

Myth #4: AOP is Too Hard
I believe this myth is bolstered by a smidgen of truth. More than a few developers are frightened by the bizarre AOP lexicon, the power and complexity of AspectJ, and the possibility of unintended side effects when applying multiple aspects. That said, the beauty of AOP is that, unlike OOP, it does not require every developer in the project to participate. Instead, a small team of your best developers and architects can implement the required aspects while the rest can rely on traditional OOP to implement the domain logic. This is "separation of concerns" at its finest. Furthermore, AOP is no more daunting than OOP. With time and practice, AOP terminology and concepts can become as familiar as encapsulation, inheritance, and polymorphism.

Myth #5: .NET Attributes = AOP
Unfortunately, I am partly responsible for perpetuating this myth, so let me do my part to debunk it. .NET attributes are amazingly useful and innovative. The application of attributes alone, however, does not equate to AOP. That said, you can use attributes to implement an AOP framework in .NET, and many early .NET AOP tools have done exactly that.

Myth #6: AOP is the Universal Solvent
When a concept as exciting as AOP comes along, it's easy to become a little too passionate and oversell its utility. To their credit, the main AOP proponents have been quick to acknowledge that, unlike OOP, AOP does not represent a general approach to modeling applications. Instead, AOP solves only one class of problem: the cross-cutting concern. This one problem, however, occurs repeatedly throughout an application, resulting in higher development costs and much higher maintenance costs. So, though it is narrowly focused, AOP solves a critical problem facing today's developers.

AOP is an immensely useful concept to have in your developer arsenal. Unfortunately, .NET AOP tools remain scarce. But if you want to experiment with AOP in .NET, I recommend a framework called Rapier-Loom.NET (see Resources). Give it a try and I think you'll agree that AOP is an exciting idea that elegantly solves the issue of cross-cutting concerns.

About the Author
Tom Barnaby is a Microsoft MVP and an instructor at Intertech Training. Tom has authored or coauthored several books including Distributed .NET Programming in C# and Applied .NET Attributes. As a member of the INETA Speaker's Bureau, Tom regularly presents at developer conferences and .NET user groups across the nation.