Mastering AOP: Designing Joinpoint Interfaces for Clean Module Architecture

Understanding a module’s design starts with its interface; by examining interfaces we can infer the overall implementation and simplify construction. The article begins with the background of Aspect‑Oriented Programming (AOP) and shows how to derive the necessary interfaces to describe a module’s functionality.

AOP Motivation and Basics

Object‑oriented programming (OOP) leads to duplicated code when many unrelated classes need the same behavior (e.g., logging, security). AOP introduces a horizontal dimension that separates such cross‑cutting concerns from the vertical class hierarchy.

Three Core Steps of AOP

Identify join points – the locations in the program where cross‑cutting logic can be applied.

Define the cross‑cutting logic (the advice).

Weave the advice into the identified join points.

Developers mainly focus on writing the advice; the framework determines the join points, avoiding repetitive code in each class.

Example Code

public class Test {
    public static void main(String[] args) {
        // @1
        B b = new B();
        // @2
        b.method();
        // @3
        B.say();
    }
    static class B {
        // field
        // @4
        private String name;
        // constructor
        public B() {
            // @1.1
        }
        // instance method
        public void method() {
            // @2.2
        }
        // static method
        static void say() {
            // @3.3
        }
    }
}

From this example we can categorize join points into two major groups: fields and methods (including constructors, instance methods, and static methods).

Designing Joinpoint Interfaces

In Java, everything is an object. A class consists of fields and methods (constructors, instance methods, static methods). The AOP Alliance uses AccessibleObject to abstract common behavior. A joinpoint interface must provide two pieces of information:

If the join point applies to an object (field, method, constructor), it must return both the AccessibleObject and the target object because reflective invocation requires the instance.

If the join point applies to a class (static method), only the AccessibleObject is needed.

Additionally, the interface may need to support chaining multiple advices, similar to the Chain‑of‑Responsibility pattern (e.g., Tomcat filters, Netty handlers). The AOP Alliance defines a Joinpoint interface for this purpose:

public interface Joinpoint {
    Object proceed() throws Throwable;
    Object getThis();
    AccessibleObject getStaticPart();
}

proceed()

triggers the next advice in the chain. getThis() returns the current target object (null for static join points). getStaticPart() returns the underlying Method or Constructor object.

Extending Joinpoint Interfaces

Beyond the base Joinpoint, specific sub‑interfaces can represent constructors, methods, or fields, allowing callers to retrieve the exact reflective element needed for execution.

Weaving Strategies

Static weaving : A custom class loader modifies bytecode during class loading to insert cross‑cutting logic.

Dynamic weaving : Uses runtime proxies (JDK dynamic proxy) or bytecode generation libraries (CGLIB) to create proxy objects that delegate to the original target while applying advice.

Spring AOP adopts dynamic weaving: it generates a proxy that holds a list of interceptors (advices). When a method is invoked, the proxy executes the interceptor chain before delegating to the target method.

AOP Alliance Interface Overview

These few interfaces provide a lightweight, language‑agnostic contract that frameworks like Spring implement to achieve modular, reusable cross‑cutting behavior.