AOP Reimagined: Decoupling Cross-Cutting Concerns in TypeScript, C#, and Java

Your business logic is beautiful. It’s clean, expressive, and solves exactly what the user needs. Then, reality hits. You need to add logging. You need to verify permissions. You need to manage database transactions. You need to handle retries.

Suddenly, your five-line ProcessOrder method is buried under twenty lines of "noise." This is the problem of Cross-Cutting Concerns—functionalities that affect multiple layers of an application but don't belong to the core business logic of any single module.

Enter Aspect-Oriented Programming (AOP).

AOP is a programming paradigm that aims to increase modularity by allowing the separation of these concerns. Instead of scattering logging code everywhere, you define it in one place (an Aspect) and tell the framework where to apply it (a Pointcut).

In this guide, we will explore how AOP is implemented in three of the most popular ecosystems today: TypeScript, C#, and Java. While they look similar on the surface, their underlying "engines" are fundamentally different.

The AOP Lexicon: Speaking the Language

Before we dive into code, we need to align on the four horsemen of AOP:

1. Aspect: The module that encapsulates the cross-cutting concern (e.g., LoggingAspect).
2. Join Point: A specific point in the application execution (usually a method call).
3. Pointcut: A predicate that matches Join Points (e.g., "all methods in the Service namespace").
4. Advice: The actual code that runs at a Join Point (Before, After, or Around).

1. TypeScript: The "Active Interceptor" Pattern

In the TypeScript ecosystem, AOP is primarily achieved through Decorators. Unlike Java or C#, TypeScript decorators are active functions. They are executed when the class is defined, allowing you to literally wrap the original method with a new one.

The Implementation

Here is how you would implement a @Log decorator that works across TypeScript, but we'll focus on the modern Method Decorator.

// The Aspect (Decorator Function)
function Log(target: any, propertyKey: string, descriptor: PropertyDescriptor) {
    const originalMethod = descriptor.value;

    // The Advice (Around)
    descriptor.value = function (...args: any[]) {
        console.log(`[LOG] Calling ${propertyKey} with:`, JSON.stringify(args));
        
        try {
            const result = originalMethod.apply(this, args);
            console.log(`[LOG] ${propertyKey} returned:`, JSON.stringify(result));
            return result;
        } catch (error) {
            console.error(`[LOG] ${propertyKey} failed with:`, error);
            throw error;
        }
    };
}

class OrderService {
    @Log // Applying the Aspect
    process(orderId: string, amount: number) {
        // Pure Business Logic
        return { success: true, id: orderId };
    }
}

Why it works: TypeScript's compiler replaces the process method with the function returned by the decorator. It’s a direct, runtime function-wrapping mechanism.

2. Java (Spring): The "Runtime Proxy" Pattern

Java, specifically via Spring AOP, takes a different approach. It uses Annotations as passive markers and Dynamic Proxies to orchestrate the logic. When you call a method on a Spring Bean, you are often calling a "wrapper" object created by Spring.

The Implementation

// 1. The Marker (Annotation)
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Loggable {}

// 2. The Aspect
@Aspect
@Component
public class LoggingAspect {

    // The Pointcut & Advice (Around)
    @Around("@annotation(Loggable)")
    public Object logExecution(ProceedingJoinPoint joinPoint) throws Throwable {
        String methodName = joinPoint.getSignature().getName();
        Object[] args = joinPoint.getArgs();

        System.out.println("[LOG] Calling " + methodName + " with: " + Arrays.toString(args));

        try {
            Object result = joinPoint.proceed(); // Execute original method
            System.out.println("[LOG] " + methodName + " returned: " + result);
            return result;
        } catch (Exception e) {
            System.err.println("[LOG] " + methodName + " failed: " + e.getMessage());
            throw e;
        }
    }
}

// 3. The Target
@Service
public class OrderService {
    @Loggable // Marker detected by Spring
    public OrderResult process(String orderId, double amount) {
        return new OrderResult(true, orderId);
    }
}

Why it works: Spring detects the @Aspect and the @Loggable annotation. At runtime, it generates a proxy for OrderService. When process() is called, the proxy runs the LoggingAspect code before and after the real method.

3. C#: The "Metadata & Interceptor" Pattern

C# attributes are passive metadata. By default, they do nothing. To achieve AOP in .NET, you historically needed a "weaver" (like PostSharp) that modified the IL code. However, modern .NET (8+) and frameworks like Castle DynamicProxy or Source Generators allow for cleaner interception.

The Implementation (using an Interceptor pattern)

// 1. The Marker (Attribute)
[AttributeUsage(AttributeTargets.Method)]
public class LogAttribute : Attribute { }

// 2. The Aspect (Interceptor)
public class LoggingInterceptor : IInterceptor
{
    public void Intercept(IInvocation invocation)
    {
        var methodName = invocation.Method.Name;
        var arguments = string.Join(", ", invocation.Arguments);
        
        Console.WriteLine($"[LOG] Calling {methodName} with: {arguments}");

        try
        {
            invocation.Proceed(); // Execute original method
            Console.WriteLine($"[LOG] {methodName} returned: {invocation.ReturnValue}");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"[LOG] {methodName} failed: {ex.Message}");
            throw;
        }
    }
}

// 3. The Target
public class OrderService
{
    [Log] // Metadata marker
    public virtual OrderResult Process(string orderId, decimal amount)
    {
        return new OrderResult { Success = true, Id = orderId };
    }
}

Why it works: Unlike Java which does this almost automatically in Spring, in C# you usually register the interceptor in your Dependency Injection (DI) container (using libraries like Autofac or Castle.Core). The virtual keyword is often required so the proxy can override the method.

Architectural Comparison: Under the Hood

When to use AOP (and when to avoid it)

AOP is a double-edged sword. It's incredibly powerful but can make debugging a nightmare if overused.

Use AOP for:

• Observability: Logging, tracing, and metrics.
• Security: Permission checks (ACL/RBAC).
• Resilience: Retretries, circuit breakers, and timeouts.
• Infrastructure: Transaction management, caching, and validation.

Avoid AOP for:

• Business Logic: If the logic belongs to the domain, keep it in the method. Hiding "how a discount is calculated" inside an aspect is a recipe for disaster.
• Complex State Changes: Aspects should ideally be stateless or handle infrastructure state (like a database connection).
• Implicit "Magic": If a developer can't understand why a value changed just by looking at the method, you've probably gone too far.

Conclusion

AOP is about separation of concerns. By moving "how we log" or "how we authorize" out of the "what we do," we create cleaner, more maintainable systems.

• In TypeScript, you have the flexibility of active decorators.
• In Java, you have the robust orchestration of Spring proxies.
• In C#, you have the precision of metadata and powerful interception.

The choice of tool depends on your stack, but the goal remains the same: let your business logic breathe.

References

1. Aspect-Oriented Programming with AspectJ, Ivan Kiselev.
2. Spring Framework Documentation: AOP, Spring.io.
3. TypeScript Handbook: Decorators, Typescriptlang.org.
4. Castle Project: DynamicProxy, castleproject.org.
5. Cross-Cutting Concerns in AI CLIs, Anderson Lima (Internal Reference).
6. Claude Code Custom Agents Guide, Anderson Lima (Internal Reference).