Self-Injection In Spring

Aspect-Oriented Programming (AOP) is a programming paradigm that aims to enhance the maintainability, and reusability of software systems. The idea behind AOP is to identify the cross-cutting concerns, such as logging, error handling, and security, and encapsulate them in separate modules, called aspects, that can be applied to the different modules of the system without modifying their code.

Self-Injection In Spring

AOP Limitation

However, AOP has some limitations, one of which is that it cannot be applied to self-invoking methods. Self-invocation refers to a situation in which a method calls itself recursively, without any external intervention. In this case, the method is responsible for executing its own behavior and cannot be modified by an external aspect.

The reason why AOP cannot be applied to self-invoking methods is that aspects are typically implemented as interceptors that wrap the method being intercepted. An interceptor is a piece of code that executes before or after the intercepted method and can modify its behavior or the data it operates on. However, in the case of self-invoking methods, there is no external call to intercept, as the method calls itself. Therefore, the interceptor cannot be applied to modify the behavior of the method, as it may intercept the interceptor itself, leading to an infinite loop.

Consider the following example of a self-invoking method in Java:

@Service
public class MyClass {

    public void executeTransaction(Transaction trx) {
       if(this.isValidTransaction(trx)) {
        // CODE GOES HERE...
       }
    }

    public Boolean isValidTransaction(Transaction trx) {
       // CODE GOES HERE...
    }
}

Self-injection

To overcome this limitation of AOP, a technique known as self-injection can be used here which involve injecting the Service(Bean) inside itself

The code shown previously will be transformed as follows:

@Service
public class MyClass {

    @Autowired
    private MyClass myClass;

    public void executeTransaction(Transaction trx) {
       if(myClass.isValidTransaction(trx)) {
        // CODE GOES HERE...
       }
    }

    public Boolean isValidTransaction(Transaction trx) {
       // CODE GOES HERE...
    }
}

By injecting the bean in itself, we overcome the AOP limitation where no longer the same object calling itself, it is another instance (different reference) calling it.

Self-Injection Risk

Although self-injection can be used to overcome the AOP limitation of not being able to apply aspects to self-invoking methods, it can also introduce new risks to the software system.

1. self-injection can lead to circular dependencies between modules, which can make the code difficult to maintain and test. self-injection can make the debugging harder when trying to understanding how the code is behaving, as it creates additional complexity and makes it harder to track the flow of data between different parts of the system.
2. self-injection can lead to memory leaks and performance issues, as it creates additional instances of the same class that need to be managed by the garbage collector. This can lead to increased memory usage and slower performance, especially in systems that process large amounts of data or have high concurrency.

While self-injection can be a useful technique in some cases, it should be used with caution and only when necessary to overcome specific limitations of AOP. It is important to carefully consider the potential risks and trade-offs before using self-injection in a software system.