hope that everything is going best in your life.
This is a third part of my tutorial on the topic of Aspect-Oriented Programming … its too late .. I know … a month or more!! … second part was posted i think 35 40 days back … and after that i got too much busy with some projects … plus my notebook had some problem with display hardware. Though i have composed this part many days back final draft wasn’t compliled till today …. the thread of black berry application tutorial is also waiting for next part … seems i’m too much lazy …
Anyhow.. here are some more concepts regarding AOP. Due to shortage of time i will not include programing example today … the next part will cover all previous theory with practical examples … today just grasp few more concepts …
In this part, you will know some of basic terms/concepts that are core of AOP. You have to keep these things in considerations while building your application with AOP. let have a look over them …
in very black-box definition, aspects in AOP are like classes in OOP. we put all the code that has scattered across the application in single unit call aspect, or in other words we express cross-cutting concerns in stand-alone modules called aspect (first benefit of AOP that it collects all scattered or tangled code across the application in form of cross cutting concerns and put them in separate units). For example, as we discussed in last part, logging code can cross-cut many modules, yet the aspect of logging should be separate from the functional concerns of the module where logging code was written. Aspects are similar to classes in their declaration, and they define types, just as classes do. In addition to its declaration, aspects contains both point-cuts and advice. We will define these two concerns in next sections.
A join point could be any point in the flow of your program. As name depicts this is a point in our application or source code where our program and aspect meet each other. or in other worlds, this is the point where AOP play its role. Join points represent well-defined points in a program’s execution that could be any method/constructor calls, method/constructor execution, field get and set, exception handler execution and/or static and dynamic initialization. You told your compiler via joint points that at this point inject the code from aspects and make the final executable program.
The advice holds those piece of codes that actually executes when AOP play its role in our program. It may contain code scattered across the application. Advice is a piece of code that we inject into our program when a join point is reached. You define advice relative to a point-cut like advice can execute before, after, or around a join point. It is an additional code that runs along with the execution of our running program.
Again talk about logging. It is a concern that cross-cut across the application, which means the same code for logging can be found in various modules of an application. To understand the concept of advices, just think that we first define joint points in our application where we need logging. it means we find those methods where same logging code is present. secondly we put all logging code (infact same piece of code) in separate pieces of code called “advice” and then while compilation of our program, compiler inject advice’s code when its join point is reached. By doing that we picked all occurrence of same piece of code and put it in separate entity.
Don’t be confused between advice and aspect. To understand the difference just think of aspect like class and advice as to any method in that class. got it …. !!!!
Simply a pointcut is a set of join points. Whenever the program execution reaches one of the join points described in the pointcut, a piece of code associated with the pointcut (called advice) is executed. This allows a programmer to describe where and when additional code should be executed in addition to an already defined behaviour. This permits the addition of aspects to existing software.
I love this feature of AOP. Believe me, if you get the real soul of this, you will become a fan of AOP, like I’m. The introduction allows aspects to modify the static structure of a program. By using an introduction, aspects can add new methods and variables to a class, declare that a class implements an interface, or convert checked to unchecked exceptions. To understand what we can get by using Introductions, consider the following real-life scenario.
In every institute, the student has to pay their fee on a monthly or semester basis. A student gets his/her fee slip from the accounts branch and submits it to the bank and get a receipt. His/her account file has been updated with a copy of the fee receipt. That’s looks fine in such a scenario.
What if a student unable to submit his/her fee till the deadline??? he/she has to submit a request form for granting him an extension in fee submission or even for allowing him/her to submit his late fee. In such a case accounts branch will issue him a separate fee slip mentioning the late fee fine. He/she will submit his late fee and will get the fee receipt. In his record, few additional documents will be filed .i.e. an application for allowing late fee, a late fee submission receipt, some other documents (like medical certificate etc) to prove why he/she was unable to submit the fee within time.
In both cases, different kind of data was filed though the process was same .i.e. submitting fee.
Now let try to automate this scenario as a software module. You need to create a class having basic attributes related to fee like paymentDate, amount. The rest of the attribute that you need to track late fee submission will be stored in an aspect. In case of any late fee case, the aspect will inject (or introduce) additional variable/methods into the existing class so that you can store and retrieve information as per the scenario. Remember that class structure will not change, just a new version or object will have some additional attribute. Hence different objects of the same class may have a different kind of attribute due to the introduction feature of aspects.
It weave our aspect and other business logic into single/final executable program. It works at compilation level of source code. How does it work is beyond the discussion of this tutorial. I will write a short note about its core functionality later on. Right now just think with AOP, we start by implementing our project using our OO language (for example, Java, or C++ ), and then we deal separately with crosscutting concerns in our code by implementing aspects. Finally, both the code and aspects are combined into a final executable form using an aspect weaver. As a result, a single aspect can contribute to the implementation of a number of methods, modules, or objects, increasing both reusability and maintainability of the code. We just define join-points, point-cuts, advices and aspects along with our business logic of program and then aspect weaver merge (infact weave) these things in our source code at compilation time.
in a conventional way, our source code is simply compiled by language compiler and produce final executable code.
|Aspect Weaver first weaves your aspects, point-cuts, join-points, advice into our source code and make a final script of code that will be ready to be compiled by language compiler, hence producing an executable program containing our business logic along with AOP features.|