developer to dynamically modify the static OO model to create a system that can grow to meet new requirements.
AOP allows you to dynamically modify your static model consisting mainly of business logic to include the code
required to fulfill the secondary requirements or in AOP terminology called cross-cutting concerns (i.e.
secondary requirements) like auditing, logging, security, exception handling etc without having to modify the
original static model (in fact, we don’t even need to have the original code). Better still, we can often keep this
additional code in a single location rather than having to scatter it across the existing model, as we would have to
if we were using OOP on its own.
AOP nomenclature is different from OOP and can be described as shown below:
Join points: represents the point at which a cross-cutting concern like logging, auditing etc intersects with a main
concern like the core business logic. Join points are locations in programs’ execution path like method &
constructor call, method & constructor execution, field access, class & object initialization, exception handling
pointcut: is a language construct that identifies specific join points within the program. A pointcut defines a
collection of join points and also provides a context for the join point.
Advice: is an implementation of a cross-cutting concern which is a piece of code that is executed upon reaching a
pointcut within a program.
Aspect: encapsulates join points, pointcuts and advice into a reusable module for the cross-cutting concerns
which is equivalent to Java classes for the core concerns in OOP. Classes and aspects are independent of one
another. Classes are unaware of the presence of aspects, which is an important AOP concept. Only pointcut
declaration binds classes and aspects.
Weaving is the process for interleaving separate cross-cutting concerns such as logging into core concerns such as business logic code to complete the system. AOP weaving composes different implementations of aspects into a cohesive system based on weaving rules. The weaving process (aka injection of aspects into Java classes) can happen at:
- Compile-time: Weaving occurs during compilation process.
- Load-time: Weaving occurs at the byte-code level at class loading time.
- Runtime: Similar to load-time where weaving occurs at byte-code level during runtime as join points are reached in the executing application.
So which approach to use? Load-time and runtime weaving have the advantages of being highly dynamic and
enabling changes on the fly without having to rebuild and redeploy. But Load-time and runtime weaving adversely affect system performance. Compile time weaving offers better performance but requires rebuilding and redeployment to effect changes.