Why AOP is useful: examples

Have you noticed that sometimes code becomes so "boilerplate" that it's repeated in every method? Imagine a project where every other method is wrapped in logging like cotton, riddled with security checks and wrapped in transactions. At some point this infrastructural code starts to eclipse the main business logic, turning simple operations into a multilayered cake of technical checks.

That's where AOP steps in — like an experienced refactorer who says: "Okay, folks, let's pull all that decorative boilerplate out." With it we can separate cross-cutting functionality from the core code and bring back its original cleanliness. Sounds tempting? Let's see how this works in practice.

Example 1: Logging

Logging is like an airplane's black box. Nobody remembers it while everything is fine, but when something breaks, it becomes indispensable. Suppose you have several methods, and in each you want to log information about the method call, its parameters, and sometimes the result.

Without AOP you'd write something like:

public void processOrder(Order order) {
    logger.info("Executing processOrder with parameter: " + order);
    // Business logic
    logger.info("Execution completed");
}

Now imagine you have 100 such methods. Problem? You bet!

How does AOP save the day?

We use aspects to automate logging. Here's an example where an aspect is created for logging:

@Aspect
@Component
public class LoggingAspect {

    private static final Logger logger = LoggerFactory.getLogger(LoggingAspect.class);

    @Around("execution(* com.example.service.*.*(..))") // Pointcut indicating all methods in the service package
    public Object logMethodExecution(ProceedingJoinPoint joinPoint) throws Throwable {
        String methodName = joinPoint.getSignature().getName();
        Object[] args = joinPoint.getArgs();
        logger.info("Method {} called with arguments: {}", methodName, args);

        Object result = joinPoint.proceed(); // Call the real method

        logger.info("Method {} returned: {}", methodName, result);
        return result;
    }
}

Now logging is handled automatically for all methods in the service package. Business logic stays as clean as a student's code after the first refactor.

Example 2: Transaction management

Transactions are like contracts between your code and the database. If everything goes well, we commit changes (commit). If something goes wrong — we roll everything back (rollback).

Consider an example: suppose you have a method that updates several tables in the database. You want the transaction to guarantee that either all operations succeed or nothing is applied.

Without AOP you'd do something like:

try {
    transactionManager.beginTransaction();
    // Business logic
    transactionManager.commit();
} catch (Exception e) {
    transactionManager.rollback();
}

AOP and transactions: less code — more magic

With the @Transactional annotation you can add transaction management without extra code in your methods. Spring itself creates an aspect that manages transactions.

@Service
public class OrderService {

    @Transactional
    public void createOrder(Order order) {
        // Adding the order
        orderRepository.save(order);

        // Updating inventory
        inventoryService.updateStock(order);
    }
}

You don't see commit or rollback — thanks to AOP for the hidden work. If something goes wrong, Spring will rollback changes automatically.

Example 3: Security

Now imagine your app has multiple access levels: users, admins, moderators. You need to forbid certain methods for inappropriate roles. You could go the "old-school" route:

if (!user.hasRole(Role.ADMIN)) {
    throw new AccessDeniedException("Access Denied");
}

But that code quickly grows and pollutes the business logic. AOP comes to the rescue again!

AOP for access checks

We add an access check via an aspect:

@Aspect
@Component
public class SecurityAspect {

    @Before("@annotation(CheckSecurity) && args(user,..)")
    public void checkAccess(User user) {
        if (!user.hasRole(Role.ADMIN)) {
            throw new AccessDeniedException("Access Denied");
        }
    }
}

We add a custom annotation @CheckSecurity that marks methods requiring security checks:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface CheckSecurity {
}

Now, to apply the aspect just annotate the necessary methods:

@Service
public class AdminService {

    @CheckSecurity
    public void performAdminTask(User user) {
        // Administrative logic
    }
}

Voila! Access checking is moved to a separate layer, and the business logic is clean again, like a freshly erased board in the lecture hall.

What did we just do?

We looked at three of the most popular AOP use cases:

1. Logging: instead of adding logs in every method, AOP lets you do it centrally, keeping business logic clean.
2. Transactions: instead of manually managing transactions, you let Spring's aspects handle them.
3. Security: AOP helps separate access checks from business logic, making the code cleaner and safer.

All these approaches can be used and combined in real projects to reduce code volume, improve readability and simplify maintenance.

Typical mistakes and caveats

In practice, when using AOP, you may run into some "fun" moments that are worth keeping in mind:

1. Avoid complexity with pointcuts: using overly complicated expressions for pointcuts can make aspects hard to read and debug. Don't write "regexes for philosophers".
2. Testing aspects: code in aspects is often ignored in tests, but that's a mistake. Use simple unit tests or integration tests to make sure aspects do their job.
3. Performance: ensure aspects don't add unnecessary overhead to the application. For example, don't log gigabytes of information in production — use logging levels wisely.

In this lecture we learned that AOP isn't just a buzzword, it's a real superhero tool. Logging, transactions, security — that's only the beginning. The question now isn't "why AOP?", it's "why don't I use it more often?".