You may have heard the term “Aspect-Oriented Programming” or “AOP”, but not yet understand what it is and where it fits into your development. In this post I introduce the concept and some terms. In the next post we’ll look at some examples.
The Concept of Aspect-Oriented Programming
The core concerns of a software system are the main functions the system performs. For example, the core functionality of a financial system is to process financial transactions, and track customers and accounts. As developers, we model these core concerns as separate, collaborating classes.
Most software systems also have many secondary concerns that affect the core concerns. Secondary concerns include things like transaction management, user authentication, security, logging, and cacheing. We often use the identical code to perform the secondary functions in all the core classes. Because these secondary functions cut across many unrelated classes, we call them cross-cutting concerns.
Aspect-oriented programming (AOP) is a programming approach that identifies these common concerns. In AOP, these are called horizontal cross-cutting business concerns. AOP models them as separate concepts. Instead of repeating the same code in many classes, we encapsulate these business requirements into separate classes, called aspects.
AOP complements object-oriented programming (OOP). It provides another way of thinking about design and program structure. The key concept in OOP is the class, while the key concept in AOP is the aspect.
The AOP Alliance Project
The AOP Alliance project is a joint open-source project. The goal of the AOP Alliance goal is not to develop a new AOP model, or to provide a standard AOP implementation. The goal is to standardise the use of AOP so that AOP implementations speak the same core language. This helps to:
- Simplify AOP development by using a common API.
- Reuse existing AOP components instead of recreating them from scratch.
- Simplify the development of AOP tools.
The AOP Alliance has driven many of the terms and concepts we use.
Aspect-Oriented Programming Terminology
AOP terminology is not very intuitive. But, as always, we need to learn the terms:
Aspect
The aspect is the central concept. It models some functionality (e.g. transaction management) that cuts across multiple classes. An aspect is a combination of advice and a pointcut.
Join point
A point during the running of a program, such as a method invocation or the handling of an exception. This determines “when” code gets run. These are points in the program where extra functionality can be inserted (joined). Many AOP implementations support method execution join points; some support field references as join points.
Advice
The code that runs at a particular join point. This is “what” code gets run. The advice can run before, after, and around join points. AOP frameworks often model advice as an interceptor, and can chain many interceptors around a join point.
Pointcut
A filter expression (a predicate returning a boolean result) that selects matching join points from all the possible join points. The concept of pointcut expressions is central to AOP. Many AOP frameworks use the AspectJ pointcut expression language. Pointcut expressions use pointcut designators, like execution, args, within, this, etc., to find matching methods to which some advice can be applied.
The above components of an AOP language define a join point model (JPM).
AOP is implemented in Java in various ways. These include dynamic proxies, interceptors, filters, bytecode translators, load-time and runtime code weavers, etc.
AOP Implementations
There are many Java AOP implementations. Here are some you might come across:
- AspectJ is an AOP extension to the Java language, and defines new AOP related keywords. It requires a separate compiler.
- AspectWerkz supports both annotation and XML based AOP styles. AspectJ and AspectWerkz joined forces from AspectJ version 5.
- BCEL: a bytecode translator to analyse, create, and manipulate binary Java class files.
- cglib: a bytecode generation library which can generate dynamic proxy objects and intercept field access.
- JBoss AOP: interception and metadata-based AOP framework running on JBoss and Wildfly JEE application servers.
- Spring AOP: interception and metadata-based AOP framework running in a Spring container.
These implementations show that there is no good or bad implementation. Different implementations suit certain problems and/or environments.
What’s Next?
In the next post I’ll illustrate the main AOP concepts with some code examples.
Don’t forget to leave a comment – it helps me to know what topics to cover.