Writing a software program is automating real world systems.
Object Oriented Programming (OOP) has brought in a systematic way of capturing and designing the business information and processes. OOP provides the object model that is closer to the real world models. OOP breaks down the big system into components that are easier to handle. These objects provide encapsulation and their reusability allows a central point of control of their functionalities.
Typically, the business processes define the algorithms used for methods and the interactions between these objects. The point of creation and destruction and duration of existence of an object and its communication with other objects is designed by understanding when is it required in the business processes. This directly targets and satisfies the business requirements.
However, there are some requirements of a software system that have to be satisfied, irrespective of the business processes. A very common example of this is exception handling. These are orthogonal requirements, they are mostly unaffected by the business requirements that we saw earlier. To satisfy these orthogonal requirements, the code has to be inserted in multiple places, across all the components and modules. These are called cross-cutting concerns – they exist in all modules irrespective of the modules’ primary functionalities. Because the cross-cutting concerns are never part of the primary functionalities, they are also addressed as secondary requirements. Some other examples are logging, authentication, memory management, performance optimization and synchronization. If at any time later, if any of these requirements change, it becomes a nightmare to go and consistently change the scattered code. This tangling of code contributes heavily to the complexity of the code and hence the software.
Aspect Oriented Programming (AOP) approaches this with the concept of separation of concerns. It allows the programmer to specify aspects of a concern separately and then combines them to provide the final execution. This not only physically separates the aspect code from the primary functionalities, but also enables a centralised control of the code that was scattered earlier.
AOP helps in modularizing the cross-cutting concerns (secondary requirements) leading to better reuse and encapsulation.
This allows the programmer to change the functionalities for these secondary requirements without having to modify the object model. The implementation for the primary requirements and secondary requirements are physically separated and results in better design and maintainability.
Copyright Abhijit Nadgouda.