What is aspect-oriented programming?

In summary, Aspect Oriented Programming (AOP) is a programming model that allows for the proper separation of responsibilities, considering features that are essential for a group of objects, but are not their direct responsibility.

AOP is orthogonal because it usually involves concepts that are independent of the layer and have no direct relation to the functional requirements of a system.

Examples of AOP application are: log generation, access control and exceptional treatments, transactions.

For example, the method below (in Java) contains fictitious business logic and various required treatments on any enterprise system: transaction, security, and logging. I tried to make the example so as not to hurt principles and good practices of Object Orientation.

See method:

//Inversão de Controle: dependências são recebidas por parâmetros
void processarOperacao(TransactionManager transacao, LogManager log, SecurityManager seguranca, OperacaoDAO dao, Operacao operacao) {
    try {

        //segurança
        if (seguranca.usuarioEstaLogado()) {
            log.info("Falha de segurança"); //log
            throw new AcessoNegadoException();
        }

        //transação
        transacao.begin();
        processamentoComplexoOperacao(operacao);
        dao.salvarOperacao(operacao);
        transacao.commit();
        log.info("Sucesso"); //log

    } catch (ErroNegocioException e) {
        //tratamento excepcional
        log.error("Falha", e); //log
        transacao.rollback(); 
    }
}

The main problems with the code above are:

• It will be repeated in all system methods.
• 99% of the code deals with orthogonal things, that is, business logic is lost amidst various technical issues.

With AOP we can let the developer focus on logic and delegate these other details to a framework or container with AOP support.

Let's now see an example using AOP:

//dependências
@Inject OperacaoDao;

@UsuarioDeveEstarLogado //segurança
@Transactional //transação
void processarOperacao(Operacao operacao) {

    processamentoComplexoOperacao(operacao);
    dao.salvarOperacao(operacao);

}

Have you seen the difference? I'll explain:

• Dependencies : A framework injects dependencies, so you do not need "dirty" signatures or constructors, that is, with parameters unrelated to logic.
• Security : frameworks can intercept methods, so I suppose your framework will intercept the call to all methods that have the @UsuarioDeveEstarLogado annotation and execute a logic that you write in one place. >
• Transaction : The framework automatically creates the transaction when it finds the @Transactional annotation. It also controls the commit or rollback depending on whether the method has thrown an exception.
• Logging : The AOP framework can automatically intercept and log all method calls and exceptions that occur.

About being bad or not, does not exist, what exists is whether or not it is appropriate to a particular situation and will depend very much on the developer and what is being developed. In particular, OOP has always solved our problems perfectly, so we have never had the need to develop something in a new paradigm. And as an observation we can use OOP together with POA.

Follow some texts and their references that I have here in my history.

  In computer science, aspect-oriented programming, or POA, it is a paradigm of computer programming that allows software developers to separate and organize code according to their importance for application (separation of concerns). The whole program written in the object-oriented paradigm has code that is foreign to the implementation of the behavior of the object. This code is all that is used to implement secondary functionality that is spread throughout the application (crosscutting concern). The POA allows this code to be encapsulated and modularized.

Reference: link

  

It is known that in software development there are properties that do not fit into   components of functional decomposition, such as: exception handling,   real time, distribution and competition control. They are usually scattered   components of the system affecting performance or application semantics.

     

Although they can be viewed and analyzed relatively separately, their   implementation using object-oriented or structured languages becomes confusing and   your code is spread through the application code, making it difficult to separate the   functionality of these properties.

     

Aspect-oriented programming is an approach that allows the separation of these   orthogonal properties of the functional components in a natural and concise way, using abstraction and composition mechanisms for the production of code   executable.

Reference: link

  When something similar to the audit log occurs, ie an interest to cross the application, inferring many modules, or more directly, this interest "cut" the application, we say if it is a hot interest. The goal of aspect-oriented development is to encapsulate these intersecting interests into modules physically separate from the rest of the code. The modules that harbor these interests are called aspects. If we think in abstract terms, the orientation to aspects introduces a third dimension of decomposition. Remembering what we have seen, OO decomposes the system into objects (data) and methods (functions). In turn, objects and methods can still be decomposed according to a common interest. By grouping each interest into a distinct module, we will have aspect orientation.

Reference: link