[aosd-discuss] AOP myths and realities article published

[Pascal Costanza]

On 16 Feb 2006, at 06:05, Rick Bradley wrote:

> * Ramnivas Laddad (ramnivas at aspectivity.com) [060215 12:39]:
>> IBM developerWorks has published my AOP myths and realities article
>> (http://www.ibm.com/developerworks/java/library/j-aopwork15).
>
> Ramnivas,
> Congratulations!  I enjoyed your article -- it was well written and
> covers the waterfront well.
>
> I've lurked for a long time on the aosd-discuss list because I find  
> AOP
> relatively fascinating, but I'll have to say I've found little  
> occasion
> to use AOP per se -- mostly because (at least my perception) I've  
> found
> little occasion to use Java in the past few years.
>
> For a while I thought that this was due to the relative  
> availability of
> AOP tools for Java as opposed to elsewhere.  These days I'm not so  
> sure.
>
> Programming a lot in dynamic and loosely/weakly typed [0] languages,
> especially most recently Ruby, I first noticed that I relatively had
> call for AOP constructs.  After a while, though, I realized I was  
> using
> very AOPish constructs but they simply seemed like natural idioms in
> dynamic languages.  They didn't require a new formalism or  
> terminology.
>
> I began to wonder if I'd simply picked up enough AOP by osmosis and  
> was
> applying the principles.  Possibly, but I've since noticed developers
> who exhibit no recognition of "AOP" solving problems similarly in
> dynamic languages.

This sounds interesting. It seems to resonate with similar  
experiences I have made when I switched from Java to Common Lisp a  
few years ago. I have made a number of attempts to translate the  
ideas of aspect-oriented programming to Common Lisp - see http:// 
common-lisp.net/project/closer/aspectl.html - but by now I think that  
they ultimately don't make a lot of sense. This is primarily because  
AspectJ (the dominant AOP language) relies a lot on properties of the  
textual representation of the source code with its wildcard-based  
pattern matching while a Common Lisp source code isn't really text  
anymore from a very early point (it's rather a straightforward  
rendering of an abstract syntax tree). A secondary reason is that  
there are already other constructs in Common Lisp that make it  
possible to get most of AOP features (mostly macros - which are not  
like textual C macros but more like local transformations of an  
abstract syntax tree).

So I wonder what kind of features help you to express AOP-style  
abstractions in Ruby? Could you give an example or two? ;)

> [1] Watching the talk about the Singleton design pattern I catch a lot
>     of similarities.  When Java developers talk about Singleton they
>     find plenty of reasons why Singleton is "bad" or "evil".   
> Looking at
>     Singleton from outside Java, Singleton seems perfectly reasonable
>     and useful -- it's simply the common *Java* implementation  
> which has
>     gone astray.

I don't think this has anything to do with Java here. The  
implementation of the Singleton pattern is very straightforward in  
Java, but this straightforward implementation is seldomly used. It  
roughly looks like this:

public class MyClass {

   public static class Singleton {
     public static final MyClass instance = new MyClass(...);
   }

   ...
}

+ the usual modifications of access control for the constructors.  
This is a perfectly safe implementation of the Singleton patter: 1)  
The class MyClass.Singleton will only ever be loaded if anyone will  
ever use MyClass.Singleton.instance. 2) Therefore, the initialization  
of MyClass.Singleton.instance will be performed lazily. 3) The Java  
Language Specification guarantees that this is going to be thread-safe.

The problem with the Singleton pattern rather is that it is too  
complex for the (perceived) benefits you get out of it. As a  
colleauge of mine once put it nicely, if you want to make sure that  
you only eat one cookie per day, you don't build a machine that  
ensures that you only get one cookie, you just eat only one cookie  
per day. Same with the Singleton pattern: If you want to make sure  
that you get only one instance for a specific class, create that  
instance just once and store it in a global variable. That's also  
more honest in the sense that singletons are indeed just a fancy way  
of creating global variables (and hiding that fact so that noone can  
blame you for using globals ;).

One of the remaining main benefit of using a Singleton that is  
mentioned in the GoF book is that it would be easier to later move to  
a design where you can indeed have multiple instance of the previous  
Singleton class. However, it is very likely that for such a  
fundamental design change, the way you have accessed a global  
variable is one of the lesser problematic issues. This is why the  
Singleton pattern doesn't really buy you a lot.

(IIUC, the Singleton pattern was added to the GoF book for two  
different reasons: In C++, it is necessary because C++ doesn't  
otherwise guarantee a proper order of intialization between classes,  
so lazy initialization is the only way to have a guarantee that the  
classes that you rely on are already available. In Smalltalk, there  
are simply no global variables, so the Singleton pattern is the only  
way to get them. These are the only two languages used in the GoF  
book, Java wasn't around back then. Both issues are resolved in Java:  
It defines a proper initialization sequence, and it provides global  
variables. But take this with a grain of salt, I may have made  
mistakes in the characterization of C++ and Smalltalk here...)


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium