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.
Technorati tags: aspect oriented programming, aop, aspect, cross cutting, cross cutting concerns, separation of concerns, encapsulation
Copyright Abhijit Nadgouda.


September 3rd, 2006 at 11:34 pm
[...] Though not popular yet, there are more than a couple of programming types. The archaic, but very effective procedural programming, the logical programming, the popular imperative programming and object oriented programming, the now popular functional programming and the new ones like aspect oriented programming. Wow, that’s quite a list! Sometimes the requirements can demand a specific programming style. A feature of functional programming is the multiple dispatch ability, which can make software development easier in some cases. An example that made rounds recently was that the Linspire/Freespire project adopted Haskell, a functional programming language for its core development. [...]
November 13th, 2006 at 6:30 pm
[...] The LoD also leads us to Aspect Oriented Programming, which deals with separation of concerns. Rumbaugh summarizes the Law of Demeter as: A method should have limited knowledge of an object model. This view leads to aspect-oriented programming: we pull out the method and transitively all its auxiliary methods into a separate aspect. This works best if the separate aspect has limited knowledge about the object model. [...]
December 10th, 2006 at 10:06 am
[...] Technology Review has a followup of their interview with Bjarne Stroustrup. This continues with C++ questions and programming styles rather than problems in programming. Some of the highlights are that Stroustrup does not think Aspect Oriented Programming will be picked up outside academia because of practical problems with overhauling the tool chain. He also talks about futures of programming. I am a little more optimistic about AOP and I think what has been missed out is functional programming. [...]
October 23rd, 2007 at 8:10 pm
[...] Programming and Aspect Oriented Programming are related to each other. Some Adaptive Programming patterns like Class Graph require separation [...]