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

[Arno Schmidmeier <A@xxxxxxxxxxxxxxx>]

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

On Friday 24 January 2003 14:37, R. Dale Asberry wrote:
> Thanks for the feedback!  I was focusing on showing possible uses for
> aspects and not so much on completeness.  I guess it shows ;-)
>
> Also, I'm currently working on an article to show how to use aspects to
> implement/enforce design patterns.  If anyone has any work they'd like to
> contribute, it would be much appreciated!
>
> > - Declaring an error on the following pointcut misses the
> >   case where a field in one class is set by another class,
> >   or where one field is written from another setter;
> >   it also requires constructors to use setters, even
> >   though some setters are written to assume the object
> >   has been initialized.
>
> Good catch... The first issue is in the Javadoc, but I didn't consider the
> last point.  That should be easy to fix.  Any ideas about how to catch
> those other situations at compile time?
>
> > - The following pointcut is pretty expensive at compile time,
> >   and applies to system library calls which might be defined
> >   to return null at various points:
>
> Any ideas for a less expensive technique?  I changed the code so that it
> won't throw an exception, but will call System.err.println() with the same
> message.  Sometimes null return values from system calls can cause
> confusion, so at least it signals the issue.
>
> > - fyi, I don't understand your logging aspect.  For example,
> >   I'm not sure what you intended, but you have
> >   one logger, not multiple (per-class) loggers, here:
>
> Oops... that wasn't one of the test cases :-)
>
> ----- Original Message -----
> From: "Wes Isberg" <wes@xxxxxxxxxxxxxx>
> To: <aspectj-users@xxxxxxxxxxx>
> Sent: Thursday, January 23, 2003 10:57 PM
> Subject: Re: [aspectj-users] Aspect Oriented Programming (AOP): Using
> AspectJ to implement and enforce coding standards
>
> > Nice topic.  I'm curious what Ron Bodkin thinks about it,
> > since he's also interested in enforcing coding standards.
> >
> > Here's some feedback based on a brief review of the article
> > but not looking at the sample code download.  Some code comments
> > and then general ones:
> >
> > - Declaring an error on the following pointcut misses the
> >   case where a field in one class is set by another class,
> >   or where one field is written from another setter;
> >   it also requires constructors to use setters, even
> >   though some setters are written to assume the object
> >   has been initialized.
> >
> >     pointcut directMemberAssignment():
> >       set(* *.*) && !withincode(* set*(..));
> >
> > - The following pointcut is pretty expensive at compile time,
> >   and applies to system library calls which might be defined
> >   to return null at various points:
> >
> >     //The first primitive pointcut matches all calls,
> >     //The second avoids those that have a void return type.
> >     pointcut methodsThatReturnObjects():
> >           call(* *.*(..)) && !call(void *.*(..))
> >
> >
> > - fyi, I don't understand your logging aspect.  For example,
> >   I'm not sure what you intended, but you have
> >   one logger, not multiple (per-class) loggers, here:
> >
> >     //Static introduction!
> >     private static Logger ILoggable.fLogger;
> >
> >   (same comment for your method declaration)
> >
> >   I'm not sure why there is a logger instance in the (singleton?)
> >   aspect which tracks the handlers, either.  Not thread-safe?
> >
> >   For per-class logging under AspectJ 1.0, one solution is
> >   presented in the old user mailing list archives (I think with
> >   a title like "accessing static members for Log4J").  Perhaps
> >   your solution works in 1.1; as I said, I didn't try the code,
> >   so forgive any misperceptions.
> >
> > Your distinction between runtime and compile-time aspects
> > might be unclear.  It might help to explain that declare error/
> > warning works only at compile-time, and only with staticly-
> > determinable pointcuts.
> >
> > Finally, a list of resources at the end might be helpful. Some
> > of the articles listed on the AspectJ PARC page are on point.
> >
> > Wes
> >
> > > "R. Dale Asberry" wrote:
> > >
> > > I started writing this article last October, but only recently
> > > completed it.  Please let me know what you think!
> > >
> > > Aspect Oriented Programming (AOP): Using AspectJ to implement and
>
> enforce
>
> > > coding standards
> > > http://www.daleasberry.com/newsletters/200210/20021002.shtml
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users

-- 

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