Aspect Oriented Programming Tutorial :: Core Concept (Part-2)

Hello All.
Hope that you all are doing best in all aspects of your life…

This 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 some issues with this approach. We talked about issues those are not concerned with a developer of specific module but he/she has to care those things, we saw a small chunk of code and realized that same lines of code are repeating in different classes/methods time and again and a developer has to write them even when those lines are not concerned with core logic of that method or developer’s expertise.

In this part i will present aspect oriented approach to cope with such issues and to design/develop your application’s architecture with much better way. Again, may be my writing style, sentences structure, grammar, spells are not up to the mark, but it doesn’t matter, neither i’m going to tech you English nor it is an English literature class, so don’t worry 🙂 , i will try to focus on contents and concept so kindly accept my apology in advance.

Concern
orite, lets start … we know that every class, method or package in our software system has some responsibility in over all flow of application. Like some packages/classes for session management, some classes to obtain and mange database connections, some classes act like delegates, some work at middle layer to control transaction management etc … there are many other classes too that we develop as per user interface or to perform some other functionality. Anyone can guess the purpose of a class or method by just looking at its name (if good programming practices are in practice). Mean every class/method has something to concern with it, and in any application there are many possible concerns like managing role/permissions, fetching data as per specific criteria at specific screen, to control navigation, to handle session management and many others. So concern mean anything important that has to be done in software system. Any logic, any piece of code, or even a complete module.

Cross Cutting Concerns
While analyzing the user requirements and business scenarios in client’s world, you can analyze different concerns that you have to handle … and while you list down them you will realize that there are few things that are overlapping in each module or in different business scenario, or more precisely they span over different module or concerns. They present in all modules or help other modules to perform their concerning task properly. Such overlapping things or concerns are called cross-utting concerns. Means they cross cut different modules or concerns and present across the application in same form. In other words, These cross-cutting concers are pieces of logic that have to be applied at many places but actually don’t have anything to do with the core business logic of that particular class or method.

Issues with Cross Cutting Concerns
At this point I’m assuming that you have understand the term of concern and cross-cutting concerns. Again in short, concern is any functionality/logic/module/code that you have to implement to achieve some business goal; cross-cutting concerns are those concerns that are spread over the application and replicates in different concerns, got that!!! Good.

The biggest issues with cross cutting concerns are that they replicates in all applications, exists in different part of your code in more or less same form. Let consider the previous example again to clarify this point.

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;

}

Consider the above piece of code (in natural language). Last time we analyze that the bold lines can be found in every method of your application that fetch data from database, and wants to log different activities/interaction with database server. In any application, the logging and mechanism of interacting with database are major activities that have to perform again and again. In others words, logging and database interaction are two major concerns. Plus these concerns are also cross-cutting concerns because they are spreading across the application. In every method you can find them. You have no other option other than to write these lines of code in every method. What maximum you can do is to make separate classes and write all code there. Whenever you need logging and database interaction, just call methods of those classes. But again the problem is that you have to write call to those classes in every method; even a single line. This single line of code is much costly when you have to write them in every method of your class. One thing more, what if you need to have little change in that line? Again you have to edit/modify all those methods?

This thing become worst when a person that hasn’t concerned with such issue but he/she has to care about them. A person who has primary responsibility to write an optimal query to fetch data from database against a certain criteria but he/she is wasting his/her time in managing logging and database connectively issues. Is that fair? Absolutely not ..

The ideal solution for such issues is to identify and separate those piece of code/logic that span over the whole system, means their cross-cutting behavior or attribute should eliminate. Is there any way in OOP to do that? There isn’t unfortunately.

Aspect Oriented Programming Approach

No doubt Object-oriented programming (OOP) is a mainstream programming paradigm now a days. It provides software re-usability by providing design and language constructs for modularity, encapsulation, inheritance, and polymorphism. Though OOP has credit in implementing large scale projects and system, still it has some problems. It is practically proved that developers faces some problems in maintaining their code while working on large scale projects. An attempt to do a minor change in the program design may require several updates to a large number of unrelated modules. In other words, they have to change/update those modules that has no concern with core logic of required changes; more technically, they have to update many cross-cutting concerns at many places of code while doing a minor change in existing system. Hence OOP don’t have any concrete solution for managing and handling cross-cutting concerns in a software system. In object-oriented programming the natural unit of modularity is the class, and a cross-cutting concern is a concern that spans multiple classes (logging, context-sensitive error handling, performance optimization, and design patterns)

Aspect oriented approach provides solutions for such issues. It provides a way to design a software system architecture while considering the issue of cross-cutting concerns. It cleanly separate the cross-cutting concerns among different modules and treat them as autonomous construct hence remove their cross-cutting behavior.

To understand the core of AOP approach, again consider the previous example. If I remove the bold lines then remaining method will look like

method Fetch_Employee_Data{

create query to fetch data;
call to database to fetch data;
return results;

}

Here the developer hasn’t any worry about how connection with database is handling, how the logging happen. He just has to write those lines of code that belongs to core logic of that method. In other words, he is just concerned with core logic and doesn’t need to worry about other things. Doesn’t look good han??? AOP says that the class or method should perform only its concerned task and shouldn’t worry about other things. It provide a way to modularize different aspects of a system in least cohesive fashion.

How this happen? In AOP world, you pick all cross-cutting concern and develop them as separate entity, and when you need them in your code, just inject their functionality at run time. Looks strange?? i know at first glass it does. ok i try to clear by an example. Again consider the same example. In our Fetch_Employee_Data method we introduced logging to log all interaction with database server. We noticed that we have to write same line of code in every method. Now AOP says that pick these line of code, put them in separate entity, and wherever you need that logging functionality, just tell the compiler to inject logging in your method at your mentioned location; sounds good han …. it is indeed …. see you don’t need to write same code time and again in each method but only once in separate entity and compiler is injecting it in every method you mention. I will tell you latter how to write separate entity and how to tell compiler to inject at run time but right now just try to grasp core idea behind aspect oriented approach and how it is different from object oriented.

To me AOP is some kind of meta-programming. It complements object-oriented programming by facilitating another type of modularity that pulls together the widespread implementation of a cross-cutting concern into a single unit. These units are termed aspects, hence the name aspect-oriented programming. By compartmentalizing aspect code, cross-cutting concerns become easy to deal with. Aspects of a system can be changed, inserted or removed at compile time, and even reused. One thing to be noted is, that AOP does not replace OOP but adds certain decomposition features. I say it a nice add-on to OOP.

In next part i will tell you about major term used in aspect oriented programming. You learn how to pick cross-cutting concerns from system and write them as aspect; and how to tell compiler to inject them at run time. Till now i was talking in much generic fashion just to clear the concept, in next part i will discuss things pragmatically so be ready….

Author Profile

Aasim Naseem

Hey, Thanks for your interest. I’m a PMP, AWS Solutions Architect, and Scrum Master certified professional with 17+ years of hands-on experience leading projects, building teams, and helping organizations deliver software solutions better, faster, and smarter.

Outside of work, I’ve got a deep curiosity for history — especially ancient civilizations like Egypt. I also enjoy reflecting on the everyday moments that shape how we live and work. This blog is my space to share insights, lessons, and thoughts from both my professional journey and personal interests.

Thanks for reading — and I hope you will find something here that matches your interest.

Latest entries

• IslamJune 6, 2025 | Read Count: 282Economic impact of Eid-ul-Adha
• PMP CertificationMay 23, 2025 | Read Count: 492Best PMP Study Resources for 2025 (Books, Courses, Tools & More)
• Agile & FrameworksMay 7, 2025 | Read Count: 462Agile vs Scrum: Finally Understanding the Difference
• Agile & FrameworksApril 25, 2025 | Read Count: 493When Not To Use Agile: 5 Signs You Need a Different Approach