What is the big idea behind the AOP implementation

Question

I wanted to make it clear for me.

I read about AOP concept and I understood that it's a great way to share cross cutting services. (logging, security, transaction...)

But I would like to say/ask something about this idea and it's implementation.

I read there are some ways like AspectJ, JBOSS AOP in order to assimilation AOP to my business logic.

but wasnt it here already long time ago?

let's say for example I want to share a logging or security implementation amongs my components(Java beans, EJB'S, whatsoever.. )

Why couldn't I make a Singleton bean making sure it will has only one instance and as soon as any component will need it's logging/security service it would look-up and use it's service.

Why would I need to understand and have all those "Big" implementations such as aspectj or jboss AOP? What do I miss here?

Answer 1

The idea of AOP is to keep common logic in one place (which your singleton solution solves as well) and being "invisible" (transparent). With AOP your logging code isn't even part of the business logic, it is "injected" behind the scenes.

Also it is more dynamic - you don't need to call your singleton service every time you need logging. Just configure a pointcut once (like: " all setters in this package ") and logging will be applied for all existing and new code.

Moreover AOP is much, much more flexible and powerful. You can ask the AOP implementation: "please start a transaction every time I call a method beginning with " save* " and taking one argument" or "if method returning Customer throws an exception subclassing from IllegalAgumentException , call that method again".

AOP is much more than just grouping common logic.

Answer 2

You have not understood what AOP is all about. The idea of AOP is to be able to write

public void foo() {
    // some business code
}

instead of writing

public void foo() {
    LogManager.getInstance().log("entering foo...");
    SecurityManager.getInstance().checkUserInRole("fooer");
    TransactionManager.getInstance().startTransaction();
    try {
        // some business code
        TransactionManager.getInstance().commit();
    }
    catch(RuntimeException e) {
        TransactionManager.getInstance().rollback();
        throw e;
    }
    LogManager.getInstance().log("leaving foo...");
}

All the cross-cutting concerns (logging, security, transaction management) are outside of the business code, instead of being mixed with the business code, and repeated ad nauseam.