Discussions

News: Aspect-Oriented Refactoring Series: The Techniques of the Trade

Bookmark and Share Get thread feed

  1. Aspect-Oriented Refactoring Series: The Techniques of the Trade (9 messages)

    • Posted by: Nitin Bharti
    • Posted on: December 16 2003 10:48 EST
    The second part of the aspect-oriented refactoring series introduces several practical AO refactoring techniques. It shows how to refactor crosscutting concerns such as exception handling, concurrency control, and worker object creation. These techniques save on coding as well as improve comprehensibility and maintainability. Part 2 also discusses the role of AO refactoring in adopting AOP.

    Read Aspect-Oriented Refactoring: The Techniques of the Trade
    Reply to this

    Threaded Messages (9)

  2. Aspect-Oriented Refactoring[ Go to top ]

    I am getting really juked about the release of IDEA 4.0 with AspectJ Integration. I have high hopes that it will make many of Ramnivas's techniques as simple and intuitive as the OO Refactoring techniques are.

    "Replace argument trickle by wormhole..." I love it! Great stuff.
    Reply to this Reply to original

  3. No AOP in 4.0[ Go to top ]

    Don't mean to burst your bubble, but they dropped plans to support AspectJ in 4.0 about 2 months ago.
    Reply to this Reply to original

  4. Aspect-Oriented Refactoring[ Go to top ]

    You should check out Eclipse AJDT sub-project: http://dev.eclipse.org/viewcvs/indextech.cgi/%7Echeckout%7E/org.eclipse.ajdt/main.html
    Reply to this Reply to original

  5. Excellent[ Go to top ]

    Wow! Ramnivas has done an excellent job of explaining this. It's not an easy topic to explain.
    Reply to this Reply to original

  6. It is powerful[ Go to top ]

    Thank much Ramnivas Laddad, you and yours work is really powerfull.
    Another thinging is that, I don't know these java developers whether know delphi, in fact there are many features in delphi language to be worth java to learn, and some is more straightforward than aop, i.e. delphi's some aop features Implementation is better than aspectj, of course delphi has little of lack comparing java or aspectj.
    What about if some features is migrated from delphi?
    Reply to this Reply to original

  7. Delphi and AOP ?? Are you kidding ?[ Go to top ]

    :)))
    What on earth are you talking about ? I'm working with Delphi since it's first version till today. There's no AOP in delphi. Unless you think that event handlers with names like OnClick or BeforePost are some sort of AOP.
    Reply to this Reply to original

  8. Not Kidding[ Go to top ]

    I do not Kidding. Java just now do attribute because of AOP's fire but Delphi's attribute is just in compiler.
    H's do AOP feature in C#.
    And OO is just before tens years, but We, include you and I, are both do OO likes.
    So do not Kidding, please, just head, head, and head again.
    Reply to this Reply to original

  9. Aspect-Oriented Refactoring Series: The Techniques of the Trade[ Go to top ]

    I posted the following remark on my weblog:

    Ramnivas just published the second part of his AOP refactoring series and I have a quick remark on the second second example (listings 3 and 4) where he abstracts the concurrency mechanism in an aspect.

    I agree that the business logic that takes care of the concurrency belongs in a separate aspect, but not the pointcut definition. I think this is a very good example where the pointcut definition should be specified inside the code, not separately.

    Determining if a method should get a read or a write lock is fundamentally tied to the code inside the method, so I believe this should be specified on the method itself, with an annotation. Using a separate pointcut is inherently fragile because you have to specify the method names inside, which is error-prone because

        * Method names can change.
           
        * Their inside logic can change (you used to need just a read-only lock and now you need a write lock).

    Both these actions will force you to remember to modify your pointcut definition as well. I believe that having an annotation such as

        @ReadLock
        public float getBalance() {
        // ...
        }

    makes it easier for the developer to maintain his code.

    --
    Cedric
    Reply to this Reply to original

  10. I agree...[ Go to top ]

    I agree.

    When JSR-175 becomes a part of Java, AspectJ should (and all indications suggest, it will) support capturing join points based on metadata annotations. When that happens, the getBalance() method will look like:

    @ReadOnly
    public float getBalance() {
        // ...
    }

    And the readOperations() pointcut would be written as (the syntax is speculative):

    pointcut readOperations() : execution(* *.*(..)) && annotation(ReadOnly);

    On a related note, I prefer naming the annotation as ReadOnly (that describes a characteristic of the method) instead of ReadLock (that suggests what implementation should do with it). This way the implementation (aspects, in this case) can make an appropriate choice, such as taking no lock in a single-threaded application.
    Reply to this Reply to original