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

["R. Dale Asberry" <lists@xxxxxxxxxxxxxxx>]

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.  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), but about code growth and
aging: programmers forget or don't notice run-time VALUE dependencies.  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).  One other critical point you miss is that in the real world,
many programmers have only passable critical thinking and programming
skills, as well as, long learning curves for, and emotional resistance to,
picking up a new technology such as AOP.  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.  This coding standard and aspect
will rein those problems in to some extent.  Personally, I think that an
aspect/rules approach is by far the best approach to implement object
state-change management.

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