What is the big idea of ​​implementing AOP

Question

I wanted to clarify for me.

I read about the concept of AOP, and I realized that this is a great way to share cross-sectional services. (registration, security, transaction ...)

But I would like to say / ask something about this idea and its implementation.

I read that there are some ways, like AspectJ, JBOSS AOP, to assimilate AOP for my business logic.

but hasn't it been here for a long time?

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

Why can't I create a Singleton bean to make sure that it will have only one instance, and as soon as any component needs its registration / security service, it will look for and use it.

Why do I need to understand and have all these “big” implementations like aspectj or jboss AOP? What am I missing here?

Answer 1

The idea of ​​AOP is to maintain common logic in one place (the decision of which is also made by your singleton decision) and is "invisible" (transparent). With AOP, your sign-up code is not even part of the business logic; it is being downloaded behind the scenes.

It is also more dynamic - you do not need to call your singleton service every time you need to keep a log. Just configure the pointcut once (for example: "all setters in this package"), and registration will be applied to all existing and new code.

In addition, AOP is much, much more flexible and powerful. You can ask the AOP implementation: "Please start the transaction every time I call a method starting with" save* "and taking one argument" or "if the returned Customer method throws a subclass of exceptions from IllegalAgumentException , call this method again."

AOP is much more than just grouping together common logic.

Answer 2

You do not understand what AOP is. The idea of ​​AOP is 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 cross-cutting issues (logging, security, transaction management) are outside the business code, rather than being mixed with the business code and repeated ad nauseam.