• 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

Modularize crosscutting concerns

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I read in one of the articles that AspectJ "modularizes crosscutting concerns". I don't know what this means?
When someone says "modularize" I think of components that are de-coupled from each other. e.g. via an interface. "Crosscutting concerns" doesn't mean anything to me however.
Ultimately what I want to know is why I should use AspectJ. If it's adding a 4G layer on a 3(.5)G language then I'm not convinced. If it's assisting with common patterns or similar then I probably am.
Thanks,
Paul Kelcey
 
Author
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paul,
A crosscutting concern is a requirement, design, or implementation that spread over multiple modules. There are many examples of such concern: logging, tracing, dynamic profiling, service-level agreement, policy enforcement, pooling, caching, concurrency control, security, transaction management, business rules, and so forth.
A traditional implementation of a crosscutting concern causes its code to be tangled with the module�s core concern. For example, the Account class in a banking system may contain some code to perform logging, concurrency control, transaction management, authorization and so forth. Further the same concerns are addressed by multiple modules. For example, you can expect the Customer class to address the same crosscutting concerns. This is called code scattering.
The objective of aspect-oriented programming (and therefore AspectJ) is to modularize such concerns. Instead of embedding crosscutting logic into the core classes, you implement a new unit of modularity called �aspect�. Look at logging example in https://coderanch.com/t/91659/java/week-book-give-away
You can also look at example in chapter 10 of AspectJ in Action (available for free download. See URL in my signature).
-Ramnivas
 
Paul Kelcey
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your response. That makes sense. I'll check out the URL you've provided. As an example, if I had existing framework code that I wanted to sandbox, I would probably and painfully go through it and add the necessary doPriviledged calls etc. Is this the type of thing I can modularize into a separate module? I'm not concerned specifically about sandboxing, I'm just trying to grasp the concept of modularization. That's why I say "that type of thing" rather than "that thing specifically".
Cheers,
PK
 
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
Paul,
The example of doPrivileged() is exactly the focus of chapter 10 of AspectJ in Action (avaialble as a free sample chapter). See URL in my signature.
-Ramnivas
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic