RE: [aspectj-users] Question on architectural aspects

[Russell Miles <russellmiles@xxxxxxx>]

Hi Lendvai,

Thanks so much for the feedback :) Started some pretty heated debates here so I'll keep you posted. From my perspective I can see both sides, which doesn't help much, but with enough opinions maybe I can start to develop one of my own on this :) 

Thanks again,

Russ Miles

On Tuesday, December 02, 2003, at 01:29PM, Lendvai Attila <Attila.Lendvai@xxxxxxxxxxx> wrote:

>:: on the small scale in terms of the clever things that can be 
>:: done, but isn't that getting awfully close to using aspects 
>:: to do clever things that the language is specifically 
>:: attempting to prevent us from doing? 
>
>if you ask me, i always disliked when language designers were trying to
>be smart and limit the possibilities to their taste.
>
>software development is a composition, and each problem needs its own
>composition. now, static OOP gives a very limited tool for composition
>that the whole world is trying to overcome by generating programs,
>introducing aspect languages, etc. instead of thinking more generally
>about the problem, providing tools for meta-programming, etc.
>
>:: I always understood the more system level selling point for 
>:: applying aspect concerns across the big picture, but when 
>:: aspects start to seriously affect the underlying 
>:: architecture of the business logic I get worried as I feel 
>:: that one of the rules of aspect orientation is to apply 
>:: aspects to business logic, not define the business logic 
>:: itself in aspects. I guess the rule I tend to use is develop 
>
>imho it all depends on what the business logic needs. if it's the usual
>accounting/user management/etc with a db in the background then you are
>right. write the logic in plain java and support with aspects as a
>painless solution.
>
>but if the requirements are more complex, in other words the software to
>be done requires more complex composition, then you are better off by
>implementing it with aspects. (if you are tied to java)
>
>also this "more complex composition" is relative. it's better said so
>that it's more farther from the OOP model, so the implementation in the
>OOP model is more complex/less intuitive.
>
>:: the application using good OO and patterns, identifying 
>:: cross cutting concerns for the aspects to be developed for, 
>:: and then bring both parts together ... but the business 
>:: logic still makes sense to me in plain OO. 
>
>what if there's a line in the requirements that sais whenever a property
>is changed of an entity, and this entity is on a list of entities
>configured at runtime, then an audit log must be created with these
>informations...
>
>what about plain java for this?
>
>i don't want to say that AOP is the ultimate tool for universal
>composition of software systems, but it's definately ultimate compared
>to OOP. intresting reading about composition and complex systems:
>http://www.lucs.lu.se/People/Henrik.Gedenryd/Squeak/UC/UCpaper.pdf
>
>:: I guess I'm not clearly seeing the advantages of applying 
>:: aspects on a class by class basis, or to invoke 
>:: architectural decisions such as OO patterns, but I am 
>:: definitely seeing worrying problems where developers are 
>:: going to be coming to new applications and are going to find 
>:: it increasingly difficult to understand the business logic 
>:: as it is being applied using aspects.
>
>it's not because of AOP, it's because of the complexity of the problem.
>and it will not help anything if you have a complex problem with a
>sloppy OOP implementation with lots of redundancy, and you can
>understand random three classes easily. could be that those three
>classes have nothing to do with the problem domain and they are there
>only to overcome the limits of OOP composition.
>
>this is related to the "average programmer" argument that i dislike,
>too. solutions of complex problems will be complex, and need flexible
>and sometimes complex tools/languages. and you can not prevent someone
>from writing bad code by limiting the complexity of the language, but
>you can pretty easily prevent someone from writing optimal code
>(maintenance, speed, or whatever counts) by limiting the flexibility of
>the tools in the name of the average programmers... but it's only my
>opinion.
>
>:: I know this is not a technical AspectJ question, and I 
>:: apologise once again if this is the wrong place, but this 
>:: discussion is killing me at work with my OO people and I'm 
>:: desperate to fully understand the motivations behind aspects 
>:: being used on the small scale.
>
>imho, the more you limit the redundancy in a system the better. of
>course only to that extent that you can manage the  complexity of the
>implementation itself...
>
>the more you can understand the problem domain, the more fine grained
>composition you can design to put togather a system that models the
>problem domain. if you start leaving redundant stuff in the
>implementation due to the limits of the composition abilities of your
>tool/language, or due to the limits of the understanding of the problem,
>then you find yourself in the usual regression of software solutions.
>the impelmentation gets more and more harder to evolve as the domain is
>understood more and more, bugs start creeping in due to incosistencies
>all around, etc.
>
>some toughts about succinctness: http://www.paulgraham.com/power.html
>
>:: <Never any offence intended>
>
>me neither. not to mention that aspectj, with java and it's libs behind
>it, is still a lot more powerful for real world solutions then any fancy
>new language today...
>
>just some toughts,
>
>101
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>