Re: [aspectj-users] Aspect Oriented Programming (AOP): Using AspectJ to

[Arno Schmidmeier <A@xxxxxxxxxxxxxxx>]

On Friday 24 January 2003 17:18, R. Dale Asberry wrote:
> Thanks for your input... I enjoy having people challenge my assumptions!
>
> The article wasn't so much about specific coding standards as it was about
> using aspects to help enforce them.  It was also about ways to introduce
> the technology to higher-ups that don't understand it.  

I was aware of that fact. I just opt for a better example, or a more detailed 
elaboration of the limitations of this example.

> However, I don't
> think you're getting the meaning of my suggestion.  The problem is not
> about variable renaming (easily solved as you suggest), 

I named the argument variable renaming, only because it is often quoted as an 
argument for the set/get for access of private member variables. So let's 
focus on the second and much more important argument code growth and aging.

> but about code
> growth and aging:  programmers forget or don't notice run-time VALUE
> dependencies.  

Yes, I agree here.

> The easiest plain-old-Java approach is to encapsulate that
> functionality in a setter or other state-modifying method.  Yes, you can
> argue that aspects should handle these interdependencies, but that is only
> true for those applications that fully account for an AOP approach (which I
> STRONGLY advocate).  

Exactly that is my argument. An application/project who is using aspects, 
other than simple debugging aspects should use that approach. However to be 
even capable to use this approach, the exisiting coding rule of accessing 
private members has to be dropped. 

> One other critical point you miss is that in the real
> world, many programmers have only passable critical thinking and
> programming skills, 

Having beeing responsible for the education of the development department of 
Sirius Software for many years, I am aware of the fact.

> as well as, long learning curves for, and emotional
> resistance to, picking up a new technology such as AOP.  

And here I disagree absolutly. It is true, AOP as a new programming paradigma 
has a very long learning curve for the average programmer, if he does not get 
educated correctly. 
If you train them correctly the learning curve can be drammatically improved.
Good training includes showing them old and deprected idioms, show them the 
new idioms, which are replacing the old ones, and explain why the new one is 
superior and discuss all the pros and cons.

<shameless advertising>
This is one of the services I provide.
</shameless advertising>

> Whether you
> disagree or dislike my statement, the truth of the matter is that I've
> spent more time on bugs due to this particular problem than any other. 

I buy that argument.

> This coding standard and aspect will rein those problems in to some extent.

The coding standard does not help at all.
The coding standard does not solve the stupidity of the developer.

public void foo(){
  //some caluclation;
  x1=result;
  dependingfromx=somefunctionfrom(x);
}

is often written with this coding standard as:
public void foo(){
  //some caluclation;
  setX1(result);
  setDependingFromX(somefunctionfrom(getX1());
}

so this coding standard does not improve anything. 
if  setDependingFromX(somefunctionfrom(getX1()); is moved to the function 
setX(), fine, but I am convinced, that every AOP trained developer who moves 
the code over there, would also move the code to the relevant aspect. 

>  Personally, I think that an aspect/rules approach is by far the best
> approach to implement object state-change management.
>

I agree here, too.

So summing all up.
For your article, I recommend to drop this example and find a better new one.
The coding rule is only valid for all projects, which do only use plain old 
Java and where AspectJ is only used as a QA tool.
HOWEVER TEAMS, WHO ADOPT ASPECTJ, SHOULD DROP THIS RULE ASAP.
I know of several java applications, which got a good performance benefit 
after they have been transfered to AspectJ, only by dropping this rule. 

That is another important message to managers:
"with AOP you often can eliminate OO-overhead, needed for flexibility
in OO-code".
I strongly recommend to let a very experienced AOP consultant/trainer/mentor 
update your java coding style guides to AspectJ coding style guides. 
<shameless advertising>
This is one of the services I provide.
</shameless advertising>


kind regards
   Arno

******************************************************************************
Arno Schmidmeier
+49/9151/90 50 30
or A@xxxxxxxxxxxxxxx
******************************************************************************
Yes, I have realized several projects with AspectJ.
Yes, I do provide consulting for AspectJ.


> ----- Original Message -----
> From: "Arno Schmidmeier" <A@xxxxxxxxxxxxxxx>
> To: <aspectj-users@xxxxxxxxxxx>; "R. Dale Asberry" <lists@xxxxxxxxxxxxxxx>
> Sent: Friday, January 24, 2003 11:57 AM
> Subject: Re: [aspectj-users] Aspect Oriented Programming (AOP): Using
> AspectJ to implement and enforce coding standards
>
>
> Some additional comment:
>
> Following example is IMHO partially valid for plain old java projects.
>
> >>As objects become increasingly complex through their lifetime, changing a
>
> single member variable may require updating another variable or interacting
> with another class.  Coders are sometimes unaware of these obfuscated
> constraints due to lack of documentation and convoluted coding.  Forcing
> programmers to use setter methods provides a single point of entry to
> update state rather than having it scattered and/or (incorrectly) copied
> throughout the class.  The following pointcut and advice enforces setter
> methods: pointcut directMemberAssignment():
>         set(* *.*) && !withincode(* set*(..));
> declare error: directMemberAssignment():
>         "Coding standards require the use of a setter for all " +
>         "member variable assignments, even within the class itself.";
> << (from the website)
>
> This codingstyleguide should be dropped/modified for AspectJ based
> projects. The access to private members of a class doesn't need to be
> protected by set and get methods anymore. The potentially required
> flexibility can be easily realised with (inner aspects) in AspectJ.
> I do not buy the argument of cost of renaming either. Most modern IDE
> offers these renaming functionality for free. (Most often found under a
> refactoring term).
> The additional overhead in performance and lines of code easily outrun in
> my projects at Sirius the flexibility for "legacy" java developers.
>
> But please note: I DO NOT lobby for the use of protected or private
> variables
> here.
>
> kind regards
>    Arno
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users

--