Hi Ramnivas,
With a lot of interest I have been reading chapter 3 of "AspectJ in Action: Practical Aspect-Oriented Programming" which I downloaded from
http://www.manning.com/laddad One of the most fundamental design principles underpinning software design is the principle of coupling and decoupling of components: maximum coupling with a component and maximum decoupling beween components.
A striking example of this architecture is the application server running
EJB components.
All application logic is within the EJB components while the infra-structure (cross-cutting concerns in AOP terminology) is handled by the application server.
In your logging example you claim that the aspected classes are oblivious of the logging aspect. This is right and is is line with decoupling components.
However the aspect itself needs to have an intrinsic knowledge of the structure of each class involved. The logging example is 100% generic, but other examples from chapter 3 refer hardcoded to the names of joint points.
This hardcoded link between aspect and aspected classes strongly couples the aspect to the aspected classes.
The logging can be achieved in an 100% decoupled way with an applicatio server. Similar for other cross-cutting concerns.
For those not asleep yet, here is my question:
What kind of benefits does AOP deliver to warrant a hard coupling of components, thereby violating a fundamental design principle ?