AW: [aosd-discuss] Questions on aspects and orthogonal concerns

[Dean Wampler]

Loesch Felix (CR/AEF4) wrote:
> [snip]
 >
> Why should we use aspects then if they are neither orthogonal nor
> oblivious?
> 
> You could achieve the same by separating the functionality into a new
> function 
> and call it from the base code. 

This is the crucial point. If you only have to insert that call a few 
times, then aspects are overkill. However, if you have to insert it 
hundreds or more times (logging/tracing being an obvious example), then 
  you lose the modularity of that concern. Note that you /still/ have a 
logging/tracing module (e.g., Log4J), but the /use/ of it is 
cross-cutting and scattered. This is bad for many reasons, including
1) Maintenance is hard and error prone:
   a) It's hard to use it consistently everywhere.
   b) Try replacing Log4J with the JDK's logger!
2) Reuse of the tangled modules is hard because you have to pull along 
Log4J, etc.
3) Code comprehension is compromised by the clutter.
4) Unit testing is more difficult because of the explicit dependencies.
5) Tracing the completion of non-functional requirements (which are 
often cross-cutting) to the implementation (which often comes out 
cross-cutting) is practically impossible. (Thanks to Ramnivas Laddad for 
recently pointing out this issue...)
6) ...

You may already know these points ;^)

> What is in your opinion the advantage of aspects over normal
> decomposition of a system into modules? 
> Is it only the fact that you do not have to place the method / function
> calls into the base code? 

AOP is complementary to other modularity approaches. You will definitely 
still have objects (in most cases ;^), just less tangled ones!

> I am asking these questions because it is considerably hard to convince
> people of 
> aspects that have never heard of them and do not have a computer science
> background. 

True enough.  The "meta-point" is always that AOP, like OOP, patterns, 
etc. is a tool that's appropriate in some contexts but not others. I 
think the reason AOP is emerging now and being embraced by the 
Enterprise Java community (in particular), is because it addresses a 
recurring design problem that has grown painful to the point that older 
modularity solutions are no longer "good enough".

dean

-- 
Dean Wampler, Ph.D.
dean at aspectprogramming.com
http://www.aspectprogramming.com
http://www.contract4j.org
I want my tombstone to say:
    Unknown Application Error in Dean Wampler.exe.
    Application Terminated.
    [Okay]    [Cancel]