[aosd-discuss] AOP and Modern OO approaches

[Dean Wampler]

Charles,

I agree that depending too much on fine-grained controls causes  
problems. If you create lots of detailed, explicit dependencies  
between modules, you will have serious trouble with long-term  
maintenance. The paper by Tourwe, et al. on the "AOSD/Evolution  
Paradox" demonstrated this. In fact, it's a familiar problem from  
OOD, as well. I discussed it in my industry track paper at AOSD '07,  
which looked at OOD principles applied to AOD.

I think we need to figure out how to hide these fine-grained details  
behind appropriate abstractions and then do all our aspect coupling  
(weaving, etc.) using these abstractions.

Concerning the goal of identifying the cross-cutting concerns early,  
I think that is certainly desirable, but the nature of development  
these days requires agility and responsiveness to changing  
requirements. Hence, we'll never succeed at identifying all of them  
up front. We need to figure out how to be agile with aspects, too, in  
my opinion.

Yours,

dean

On May 9, 2007, at 9:19 AM, Donisthorpe C ((AT)) wrote:

> Dean,
>
> Your suggestion that 'its a paradox that modularizing global, cross- 
> cutting behaviours require very fine-grained control' is   
> interesting and prompts the following thought.
>
> It would be more efficient to limit the effect of cross-cutting  
> behaviours and reduce the overhead of 'fine-grained control' in the  
> software.  This would have the benefit of simplifying the software  
> development task. It could be simplified if crosscut influence were  
> minimised or constrained at the system level prior to software design.
>
> I think that crosscuts can be tackled at different levels in the  
> development process and that early identification can make the  
> detailed design task easier.   EA could simplify the system  
> architecture and reduce the need for crosscutting effects by  
> identifying and developing the headline aspects.
>
> Perhaps, this analysis approach could be enhanced to help reduce  
> the possibility of system failure as not all crosscut effects can  
> be predicted within a large complex system.
>
>
> Regards
>
> Charles
>
>
> From: discuss-bounces at aosd.net on behalf of Dean Wampler
> Sent: Wed 09/05/2007 14:07
> To: vamsidhar sharma
> Cc: discuss at aosd.net
> Subject: Re: [aosd-discuss] AOP and Modern OO approaches
>
> Since I wrote the presentation, perhaps I should field the question ;)
>
> All I meant by this statement is that AOP expands the options for
> changing program behavior at the level of the class, individual
> objects, and even individual methods and fields in an object. The OO
> mechanisms you mention take you most of the way and they are great
> when you can choose which subclasses to define and instantiate. Then
> you can override methods as needed to change the behavior locally.
>
> You don't always have that freedom in some real-world systems, so
> it's nice to have tools with sophisticated "join point models" that
> let you reach into existing classes and objects and modify their
> behavior, even dynamically. The better AOP tools let you specify
> conditions for when this behavior should occur. For example, you can
> say that "new behavior" N should only be added to a particular method
> M if it is being called in the context of another method M1 and data
> D has a particular value, etc., etc.
>
> However, the important point isn't that you have more fine-grained
> control over the objects in the system. Rather, the important point
> of AOP is that you can specify in one place (a "module") the state
> and behaviors you want that are shared among an arbitrary number of
> classes and objects that might not have any other relationship.
>
> Perhaps it's a paradox that modularizing these global, cross-cutting
> behaviors requires very fine-grained control.
>
> Hope this helps.
>
> Dean
>
> On May 9, 2007, at 5:55 AM, vamsidhar sharma wrote:
>
> > While understanding AOP I found this article by Robert Martin
> >
> > http://objectmentor.com/resources/articles/AOP_in_Ruby.pdf
> >
> > In this the author says that modern OO desgin approaches like
> > inheritance, design patterns, Inversion of control containers etc.
> > work at a coarse grained level of interaction..
> >
> > Can anyone clarify what that means.. the coarse-grained level?
> >
> > Thanks
> > Vamsi
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > _______________________________________________
> > discuss mailing list    -    discuss at aosd.net
> >
> > To unsubscribe and change options, go to:
> > http://aosd.net/mailman/listinfo/discuss_aosd.net
> >
> > Check out the AOSD.net Wiki: http://aosd.net/wiki
>
> Dean Wampler, Ph.D.
> dean at objectmentor.com
> http://www.objectmentor.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]
>
>
>
>
> _______________________________________________
> discuss mailing list    -    discuss at aosd.net
>
> To unsubscribe and change options, go to:
> http://aosd.net/mailman/listinfo/discuss_aosd.net
>
> Check out the AOSD.net Wiki: http://aosd.net/wiki

Dean Wampler, Ph.D.
dean at objectmentor.com
http://www.objectmentor.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]



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20070510/b5094b8c/attachment.html