• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

AspectJ : coupling and decoupling question

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Author
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
John,
I suggest you read chapter 10 as well. The purpose of examples in chapter 3 is mostly to introduce the language and not so much design techniques. In chapter 5 onwards, you will see that the coupling introduced by (sub)aspects in very light � at the same level as two object coupled through interfaces.
Hard-coupling also has a place when using AspectJ � usually to refactor out some common code in a class or two. In fact, for such kind of implementations, I often use a nested aspect inside the class I want to crosscut. This is much like refactoring into a private method, except now I use an aspect to avoid code calling that method from multiple places.
-Ramnivas
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So AspectJ allows nested advice. Is inheritance supported? Is it even relevant for implementing aspects?
 
Ramnivas Laddad
Author
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lasse,
AspectJ allows nested aspects. AspectJ also allows aspect inheritance (an extremely useful concept), abstract aspects and abstract pointcuts.
-Ramnivas
 
John Zoetebier
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ramnivas,
The authentication and authorization example in chapter 10 is very impressive.
Abstract aspect AbstractAuthAspect is a nice example of how you can write an aspect without any reference to a join point, as the joint point is abstract as well. A sub aspect can now implement the concrete joint points. You do not even have to define interfaces to enable communication between aspect and aspected class. Very clever done !
These abstract aspects open the way to build generic aspects which can be used as a light-weight EJB system with the added advantage that you are more flexible in the implementation of an aspect.
With an appication server you either go with the cross-cutting concern implemented or not. There is no way to change the business logic.
With AspectJ you can tune an aspect exactly to the requirements of your organization without the added complexity and overhead of an application server.
You are however careful in describing the AspectJ solution as light-weigth EJB.
Do you mean this in the sense of: you only use those aspects what you need ?
 
I was her plaything! And so was this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic