Aspect Oriented Programming (Part-1)

Posted on Updated on

Hello Everyone.

Hope you are doing best in all aspects of your life.

Today, I’m going to start new series of tutorials on new topic .i.e. Aspect Oriented Programming, in which you will learn about new programming aspectparadigm (though it’s too old), its basics, its core concept, comparison with current programming paradigms like Object Oriented Programming (OOA) and finally implementation for any real world problem or scenario.

Again, may be my writing style, sentences structure, grammar, spells are not up to the mark, but it isn’t an issue, i will try to focus on contents and concept so kindly accept my apology in advance.

I will post 3, 4 articles for this topic, dividing this in following possible sections

  • Object oriented programming approach and some flaws
  • Core theme of Aspect Oriented Programming
  • Solutions provided by AOP against OOP flaws
  • Important terms use in AOP talk
  • A programming example with OOP and AOP
  • Introduction of aspectJ, a java implementation of aspect oriented approach.

Object Oriented Programming Approach

Computer software or programs are an automation of real world scenarios, a transformation of manual work into computer operated systems. Many approaches are in practice to design and develop more usable, user friendly, easily evolevable and maintainable computer systems. Different approaches handles under-considerate domain with its own style. Object oriented approach focuses on data, takes anything in real world as data having some attributes (data fields) and some operations (methods). This approach evolves in sixth decade of last century when the computer system becomes much more complex and the current programming paradigms were not much capable to cope with required features to facilitate both developer and end users. At that moment researches were make on some new style of programming and then introduced “data focused” approach .i.e. object oriented programming where everything in real life was considered as object, in other words every noun is an object. We design systems based on these nouns in real world like Pay, Account, Employee, Product, PurchaseOrder, Invoice etc

Object oriented approach was at its peak in mid 80’s and late 90’s, even still a great number of computer systems are being developed using object oriented approach, but from its birth, it is facing many critics. Though the implementer of this approach are introducing many new features day by day in their respective languages compilers but only adding feature after feature into something don’t makes it better. Polymorphism, encapsulation, abstraction no doubt are building block of any mature programming language and should available implicitly, yet still there are few areas where developer need more ease and re-usability of their efforts and code. Those area were perceived and make researches and then new approach was presented to design and develop software module with more ease in re-usability of existing code, more ease in extendability and maintainability. This approach was AOP.

Did you ever feel that while development in object oriented world, you have you rewrite same chunk of code in different classes/methods to achieve a same goal? like (as a very simple example) in data access layer, you have to open database connection, maintain its session, writing query, call to database to fetch data and at the end, closing and the database connections and sessions. Like following

method Fetch_Employee_DATA{

open data base session;
create query to fetch data;
call to database to fetch data;
close database session;
return results;


here the bold text are those lines of code you have to write in each method you call to fetch data from database, other lines are method specific and depends upon the business logic.

As an other example, if you have to log each and every database call .i.e. the query to database, its parameter, the returned results etc, then you have to write same line of codes every time in each method that is going to interact with database. The above method will look like

method Fetch_Employee_DATA{

log start of method;
open data base session;
create query to fetch data;
log query and its parameters;
call to database to fetch data;
close database session;
log returned data from database;
log end of method;
return results;


Again the bold lines are those lines of code you are replicating in each method to achieve a same gaol. Don’t you think you’re spending a lot of time writing the same bits of code when it comes to implementing the individual methods. These things like logging, security checking, transaction management are such aspects of the systems that are orthogonal to the specific application. Every organization need them and every developer has to implement them in their respected module, classes and methods. In short the method hasn’t concern with these replicated lines, or the core concern of the method is to fetch employee, not to log database transactions, session maintenance etc. Every class or method is doing something extra time and again that doesn’t concern to their core requirement.

To small projects for small level organizations, it may work. But what if you are going to design and develop a banking system, an ERP for large scale company, or a payroll system for big industry … where the modules are interlink cohesively, the domain is very large, covering all business scenario of under-considerate organization. In such system, you can’t afford such framework and design that is difficult to extend, maintain and reuse. You can’t let your developers to spend time and resources over rewriting the same bit of code in every class and method, instead of focusing core business logic of that class. In other words, you can’t let everyone to focus on those things that are not concerned with their core task.

Consider the above example again. You are working in on a project (let suppose inventory management). While developing different features or modules, you have to call database to fetch and insert data as per business logic and domain requirement. We have seen that in every method you write, you are writing code of opening database session, and for closing it properly. In a medium and large scale project, the number of methods doing the same things could be hundreds. Any how, you complete your task and deploy the application at client site. Next time you are ask to maintain logs for each database interaction (as we discussed above) you instantly recall the number of classes and methods where you have to write code related to logging …. you have more then 40, 50 classes (let suppose) and there are hundreds of methods interacting with database. You have to open each method’s body and has to write logging code there ….

“Sir it will take atleast 4,5 days to complete this task”

“4, 5 days, but way, its really a simple task”

“indeed its simple but i have review each and every package, class and method to embed logging code there. To make sure the sustainability of application, i have to test it thoroughly to check that our existing application are new changes are running fine”

“hmmm ok, add someone else with you and try to complete it within 2,3 day, there are lot of other things too to do”

“sure i will”

This is the expected dialog between a developer and his manager/team lead while incorporation a simple change in running application. See, the actual lines that has to write in every method are very simple, just 2, 3 lines. But when it span over entire application with hundreds of packages/classes/methods then it becomes worst, consuming your more resources in term of human effort, time and budge.

Think again … is the logging concerned to method which was written to fetch data from database? Should a developer concern with database issues like opening a session and closing it properly who want to focus his attention to design an optimal query to fetch data from database?

In next post i will introduce Aspect Oriented Programming (AOP) and will discuss how AOP provides solutions for problems we discussed earlier.

Share on Facebook


5 thoughts on “Aspect Oriented Programming (Part-1)

    rizwan said:
    October 27, 2009 at 11:55

    Ans, its really a good post. you keep your style simple and understandable. I’m waiting for next post … plz be quick

    Athar said:
    October 28, 2009 at 01:40

    Its quite helpful and great work.

      Ans responded:
      October 28, 2009 at 08:34

      Thanks athar for reading the post and for your comments. i will try my best to make it more simple in understanding.

    […] is a second part of tutorial on aspect oriented programming. In last part, we discussed little about object oriented approach to design and develop computer based system and […]

    Ans responded:
    November 4, 2009 at 20:00

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s