Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Question on architectural aspects

:: 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


Back to the top