Codesmells for AspectJ

AOP refactoring and code smells

Towards a Catalogue of Refactorings and Code Smellsfor AspectJ

AOP Seminar - Session 15

Sander Mak

Center for Software Technology, Universiteit Utrecht

Januari 15, 2007

Center for Software Technology Sander Mak

AOP refactoring and code smells

Outline

1 Introduction

2 AOP and refactoring

3 The paper

4 Other approaches

5 Conclusion

6 Questions


AOP refactoring and code smells > Introduction

In the beginning

Influential book by Martin Fowler (1999)

Preceded by PhD work of William Opdyke(1992)

Many papers on OO refactoring followed



Define refactoring

What is refactoring?

Subtitle of Fowler’s book: improving design of existing code

Refactoring is the process of changing a software system in such a waythat it does not alter the external behavior of the code, yet improvesits internal structure. Martin Fowler

Behavior preserving

Structure changing

Improving design

Refactorings are small transformation steps for code



Why refactor?

Maintainable code

More understandable codeCompliance to standard practicesSpeeds up development

Reusable code, separate structure from app. logic

Pinpointing bugs becomes easier

Essential ingredient of agile processes

Source code is the main communication medium

XP Rule

”Refactor Mercilessly”

Summarizing: to increase both quality and productivity of a developer



When to refactor?

Rule of Three

If you do something similar 3 times in arow... refactor it!

When adding new functionality

fit it in elegantly by refactoringotherwise risk spaghetti-code...

During code review

Everytime you find a code smell



Code smells

A code smell is a heuristic that might indicate the need for refactoring.

Examples:

Feature envy a class is more concerned with other classes’data than with its own

Long parameter list pass enough parameters to let a method find whatit needs, but nothing more

Temporary field class member is used where local local scope wouldhave been appropriate

These have been published along with refactorings to cure the smells


AOP refactoring and code smells > AOP and refactoring

AOP and refactoring

Observation:

AOP and refactoring share a common high-level goal:Creating systems that are easier to understand and maintain

Simplicity - less errors

Clarity - communicate intentions

Brevity - conciseness over verbosity

The cardinal rule of writing unmaintainable code is to specify each factin as many places as possible and in as many ways as possible.- Roedy Green in: How to write unmaintainable code



Refactoring extended

AOP can take over where OO refactoring ends:



Good style

When there are several ways to solve a problem,how do we pick the right wayTM?

Follow intentions of language

Languages dictate composition mechanismsIdeally: each concern separated, but you cannot separate what youcannot compose later

Experience

Follow good style rules

E.g. as documented in catalogueAvoiding code smells


AOP refactoring and code smells > The paper

The paper

Towards a catalogue of refactorings and code smells for AspectJ

Based on PhD work of M. Monteiro, written with his supervisor J.Fernandes

Premises of the paper:

1 There is no notion of good AOP style yet

2 This can be improved by providing a catalogue of refactorings andsmells

3 Toolsupport for integrating AOP with refactoring is lacking

Preservation of intention over preservation of behavior



The paper

Three categories of refactorings:

1 OO → AspectJ (10)2 AspectJ internal refactorings (6)

part of OO refactorings can be ported to aspectsother refactorings handle new concepts, e.g. pointcuts

3 Inter-aspect refactorings (11)

Idea is to sequentially compose these refactorings.

Fragile pointcut problem is not addressed explicitly



The paper

What is not in the paper:

Formalism for AOP refactoring

Authors follow format introduced by Fowler:

Typical situation, Recommended action, Motivation, Mechanics,Examples

Tool support

Neither for application .... nor detection

Metrics

Mentions related work for AOP complexity metrics though



Approach

Empirical: take existing, appropriate codebases and experiment.

Attempt 1

A workflow program was decomposed into use cases. Use cases werecaptured in AOP style.

Four AOP refactorings could be described

Invaluable experience was gained

Monolithic aspect

Aspect was not exemplary for AspectJ usage

Conclusion: good OO style pre-condition for extracting aspects



Approach

Empirical: take existing, appropriate codebases and experiment.

Attempt 2

AOP design pattern implementations of Hanneman & Kiczales werestudied. Goal: try to describe transformation of OO → AOP in termsof refactorings

Great variety of different aspects

No domain knowledge necessary

Some refactorings were too case specific (this needs to berecognized)



Approach

Considerations regarding this empirical approach:

Result: realworld solutions to realworld problems

It worked for OO, so why not for AOP

Result may be skewed because of case selection

E.g. exception handling was not considered

Generality of findings is debatable



OO to AOP refactoring

Replace implements with declare parentsProblem: interface adds secondary role to a class

Usually combined with inline interface with aspect



AOP internal refactoring

Introduce aspect protectionProblem: restrict usage of inter-type field to aspect and its sub-aspects




Minor criticism:

A bit of a hack

Very specific to AspectJ

In comparison, a refactoring like replace inter-type field with aspectmap is much more general .

Also, OO refactorings can be used in aspects (extract method,intra-method refactorings)




Minor criticism:

A bit of a hack




Remark by Wouter

In the ”Introduce Aspect Protection” section, you might want to havesome modifier that takes care of the protection?

Sure, that would make this refactoring unnecessary




Minor criticism:

A bit of a hack




Remark by Elmar

Some of the refactorings like ”Introduce Aspect Protection” seem tothank their existance to (unclear, incomplete, faulty) semantics ofAspectJ. Take for example the ”Introduce Aspect Protection” Can’twe argue that some of these semantics for AspectJ should change,instead of making a work around using refactoring?

Indeed. Still the existance of this refactoring in the cataloguemakes a programmer aware of the issues.




Replace inter-type field with aspect mapProblem: aspect introduces additional state to a class, but it mightnot need it all the time, so resources are wasted

Inter-type declarations affect all instances of a class

Inter-type declarations last a lifetime

Solution: Maintain mapping to additional data in aspect, re-route allfield accesses to the aspect

Highly similar to relationship aspects! This refactoring constitutesmoving from static to dynamic relations.



AOP generalisation refactoring

Goal of these refactorings: transform an application specific aspectinto a generalized, reusable aspect.

Again, much of the OO idiom can be ported to aspects, with subtledifferences:

There is no inheritance/overriding between advice (as opposed tomethods)

Therefore it sometimes necessary to push down advice

Weaving behavior might be surprising



AOP generalisation refactoring

Pull up inter-type declarationProblem: inter-type declaration is better placed in a super aspect (notbecause of duplication!)

Issues:

Targets of inter-type declarations receive an instance of thedeclaration per aspect

When refactoring identical inter-type fields to super aspect, onlyone instance is created at weaving time

Compare to making a field static

With more than one sub aspect most likely not behavior preserving



AOP code smells

Describe what code should not be like

Smells can lead to specific refactorings

Smells are somewhat subjective

Some of Fowler’s smells hint at cross-cutting concerns

Captured by ’extract feature into aspect’ refactoring

This paper describes 3 smells



AOP code smells

Smell 1: double personality

Class has multiple roles

Recall superimposed roles in design patterns

Secondary role might be cross-cutting

Smell 2: abstract classes

Abstract classes need to be extended

Preventing the extending class to inherit from other classes

Default implementations can be provided by inter-typedeclarations

Smell 3: aspect laziness

Overuse of inter-type declarations

Real AOP smell


AOP refactoring and code smells > Other approaches

Automation

Catalogues are cool, but...

All these smells and refactorings deal with concerns that areinherently scattered

I think automation is essential to:

1 Detect OO → AOP refactorings

2 Detect refactorings within aspects

3 Apply AOP refactorings

This session’s paper agrees, but does not contribute



AOP code smells

Related work on code smells:

Detecting bad smells in AspectJ Piveta et al.

Describes 5 AOP smells

Provides algorithm to find these

A prototype implementation is available

Contains a case study on three AspectJ systems

Algorithms are not very sophisticated



AOP code smells

Described smells and algorithms:

1 Anonymous pointcut definitions

2 Large aspects

3 Lazy aspects

4 Feature envy (defined as: class containing pointcut)

5 Abstract method introduction

Implemented in plugin for AspectJ eclipse extension



AOP code smells

Described smells and algorithms:

1 Anonymous pointcut definitions

2 Large aspects

3 Lazy aspects

4 Feature envy (defined as: class containing pointcut)

5 Abstract method introduction

Implemented in plugin for AspectJ eclipse extension

Architecture plugin



Anonymous pointcut detection



Anonymous pointcut detection

In other words: all pointcuts containing AspectJ pointcut primitives



Abstract method introductions

Abstract methods demand implementation, creates unnecessarycoupling between aspect and class



Case study

Programs analyzed:

AspectJ examples

Design pattern implementations Hannemann & Kiczales

GlassBox inspector (J2EE monitoring app)

Results: very little smells found, besides many anonymous pointcuts

.. these are not necessary bad, most of them are used once



Case study

Programs analyzed:

AspectJ examples

Design pattern implementations Hannemann & Kiczales

GlassBox inspector (J2EE monitoring app)

Results: very little smells found, besides many anonymous pointcuts

.. these are not necessary bad, most of them are used once

Output analysis



Smell metrics

Mentioned in previous paper:

Metrics based refactoring Simon et al.

More formalized metrics, and graphical representation.



Smell metrics

Mentioned in previous paper:

Metrics based refactoring Simon et al.

More formalized metrics, and graphical representation.

Output analysis

Not aspect oriented (yet)



Refactoring tool

AspectJ Refactoring Tool (ART), Iwamoto et al.

Works on PDGs, not on ASTs:

Program Dependence Graph

Existing formalism

Like control flow graph

With additional information on data

Automates application of refactorings



Refactoring tool

24 refactorings areproposed:

OO → AOPrefactorings

internal AOPrefactorings

there is ample overlap withsession paper

Difference: refactorings arecomposed with laws

Example law, move field to aspect:



Aspect Mining

So far we’ve seen tools to:

Find code smells

Find OO refactorings

Apply refactorings

In order to find OO → AOP refactorings, we need something likeaspect mining.



Aspect Mining

So far we’ve seen tools to:

Find code smells

Find OO refactorings

Apply refactorings

In order to find OO → AOP refactorings, we need something likeaspect mining.

Question: Rinse

Refactoring code into aspects can become a little tedious when tryingto track down all classes involved in say a observer pattern. There isresearch being done in aspect mining techniques [1] do you think withthe proposed catalogue of refactorings and code smells for AspectJ andthese aspect mining techniques we could come anything close to thecurrent support for refactorings in IDEs for normal OO concerns?[1]: Applying and combining three different aspect Mining Techniques



Aspect Mining

Approach created at TU Delft, combines and compares three aspectmining techniques:

1 Fan-in analysis

2 Identifier analysis

3 Dynamic analysis

Each of these is tested on JHotDraw, a graphics application createdto showcase good usage of design patterns.



Aspect Mining

Fan-in analysis

Count number of locations from which control is passed into amodule

In OO: fan-in for method M is number of distinct bodies that cancall M

Idea: if a method is called from many places, it is probablycross-cutting

Certain treshold needs to be in place (experimentally determinedvalue: 10)

Analysis excludes getter/setters and utility methods like toString()



Aspect Mining

Identifier analysis

Lexical analysis of identifiers in code

Split composed name into single words

Take stem of words

Group common words

If a group is scattered over multiple classes/methods: it isprobably a cross-cutting concern

Depends on naming conventions



Aspect Mining

Dynamic analysis

Analyse execution traces of (instrumented) program

Run program with different scenarios (use cases)

Keep track of locality in code (call stack)

Analyse which methods relate to which use case and which aregeneric

Depends on well-chosen scenarios



Aspect Mining

A framework was devised to test all analyses. Some concerns asdetected:

Contract enforcement (pre-condition checking)

Undo

Observer pattern

Persistance (read/write functionality)

All three techniques found the most common concerns. Fan-in wasfound to be suitable for larger applications, and the techniques werecomplementary for uncommon concerns.No production quality tool was implemented.



Other tools/methods

Rolebased Refactoring Hannemann & KiczalesProgrammer maps conceptual concerns to codefragments. Tools helps with mapping, andwith manipulating the code fragments.

Aspect mining tool Lexical analysis and type based analysis, withstand alone visualizer. Based on modified ajc

FEAT/ConcernMapper Eclipse plugin to navigate/analyze/refactorAspectJ code.

Concern Manipulation Eclipse plugin (originally by IBM) to manageEnvironment and build concerns in code. No analysis.


AOP refactoring and code smells > Conclusion

Concluding remarks

The paper gives a thorough description of a catalogue

Unfortunately, it does not consider much more

Especially more could be said on toolsupport

Moving refactoring from OO to AOP brings in a lot of subtleties(aspects vs. classes)

AOP refactoring research field is fairly new and open

There are many (research)tools, but

Its not very clear how these all relate and how powerful they areTo answer Rinse’s question: I don’t think it comes near legacyrefactoring support yet


AOP refactoring and code smells > Conclusion

Concluding remarks

The paper gives a thorough description of a catalogue

Unfortunately, it does not consider much more

Especially more could be said on toolsupport

Moving refactoring from OO to AOP brings in a lot of subtleties(aspects vs. classes)

AOP refactoring research field is fairly new and open

There are many (research)tools, but

Its not very clear how these all relate and how powerful they areTo answer Rinse’s question: I don’t think it comes near legacyrefactoring support yet

Master’s thesis

May be someone should take on this challenge and survey theAOP refactoring tools field and create the ultimate formalism andtool for AOP refactoring :-) ?


AOP refactoring and code smells > Questions

Question: Wouter

I think that some of the problems could be solved better with someJava and/or AspectJ changes, for example:In section 4.2 ”generalize target type” refactoring is used:

private interface NewTypeClass {}declare parents: SomeClass implements NewTypeClass;

This makes the code better by defining a role/type that the class then’implements’. But the Interface/implements constructs of Java aren’treally designed for modeling roles right? I think that there might be aneed for some stronger or better typing system than this (maybesomething like Haskell’s?).

Let’s discuss



Question: Wouter

Can you elaborate a bit on the main items that you think could beadded to Java or aspectJ that will help the refactoring?

Sure. Short answer: nothing. Why?

Refactorings per definition depend on a language

And aim to optimize usage of a language, e.g.:

goto considered harmfulswitch is codesmell in presence of inheritance/polymorphism

Certain refactorings can hint at language improvement though

Changing a language could be seen as an ’ultimate refactoring’, and itwould allow new refactorings



Question: Wouter


Sure. Short answer: nothing.

Why?








Question: Wouter


Sure. Short answer: nothing. Why?








Question: Gerbo

The designers of Java had their reasons not to allow multiple(implementation) inheritance, but AspectJ opened some sort of backdoor by using (interfaces combined with) aspects for it. And the papereven recommends this usage (“Split abstract class into aspect andinterface” and “change abstract class to interface”), which possiblycreates the ‘diamond problem’. So, what do we think of this - theoriginal Java design ideas versus these abstract class code smells?



Question: Gerbo


Question: Niels

The abstract class code smell just seems like a solution for multipleinheritance. It looks like another way to describe it is: ”Wheneveryou extend a class just for the implementation you should useinterfaces and inter type declarations.”. Or do I see this wrong?



Question: Gerbo


Diamond problem



Question: Gerbo

Common solution for diamond problem:

Fix the ordering in which superclasses are consulted

Perl, Python

Fully qualify calls to methods in superclasses

C++

About the refactorings:

Together, the pair effectively extracts a mixin from the originalabstract class

mixin: class that provides functionality to other classes, not createdfor stand-alone use



Question: Gerbo

Now if we would want to create a diamond, we have to:

have 2 interfaces

each having a method in common

inter-type declarations forcing these interfaces on a single class

have 2 default implementations of this common method asinter-type addition

This last point will be flagged by ajc

Conclusion: no multiple inheritance, rather: default implementationsfor interfaces.



Question: Nabil

Could you please elaborate more on when to use Extend MarkerInterface with Signature? Because according to the authors it is usedwhen you need to call a method that is specific to a type implementingan interface that doesn’t declare the wanted method. However in theprecondition the authors argue that this refactoring is only feasible ifall types implementing the interface export the signature of themethod we want to call. So if all types export the signature then themethod we want to call is not specific to a certain type, thus norefactoring is required. And if the types implementing the markerinterface don’t export the signature and we have to enforce them toexport the signature, then I would rather stick with downcast solution.But instead of doing it as illustrated in the paper, I would defineanother interface extending the marker interface and make it declarethe specific method and then make the specific type implement thenew interface.



Question: Nabil

public class A {

public static void doA(){}

}

public class B {

public static void doB(){}public void specificMethod(){}

}

public aspect AA {

interface Role{}interface Role2 extends Role{public void specificMethod();}

declare parents: A implements Role;declare parents: B implements Role2;

public void something(Role obj){((Role2) obj).specificMethod();}}



Question: Nabil

public class A {

public static void doA(){}

}

public class B {

public static void doB(){}public void specificMethod(){}

}

public aspect AA {

interface Role{}interface Role2 extends Role{public void specificMethod();}

declare parents: A implements Role;declare parents: B implements Role2;

public void something(Role obj){((Role2) obj).specificMethod();}}

Solution in paper

Inter-type method introduction:

public abstract void Role.doSomething();



Question: Nabil

Comparing the solutions:

Specific type for downcast not necessary at compilation

But Nabil’s solution solves this by inlining a second interface

Drawback: all classes with marker interface must implementinjected method

Nabil’s solution avoids this

.. paper calls its solution stopgap for a reason, they had aspecific scenario in mind

In short: I like your solution better, though the original one ’tidies up’a bit more



Question: Niels

The ”Push down” refactoring rules are better (less code duplication) ifthe recommended action proposes another super-aspect which extendsthe previous super aspect (in cases where code duplication wouldoccur) right?

All I can say:Push down refactorings do not avoid code duplication, but try to get amore logical placement for concerns in the aspect hierarchy. It couldeven lead to code duplication!

But I’m not quite sure what you mean, could you explain a bit more?



Question: Jinfeng

Suppose we have a pointcut call (public * *(..)), and it would matchevery public method call. And suppose we refactor a public method toa private method. (Then we might also need to modify the pointcut.So that would be a problem.) Can we detect and solve this problemwhen refactoring (to preserve the behavior)?

This is called the fragile pointcut problem, and is indeed a veryimportant issue when refactoring OO code in the presence of AO code.

Almost all ’traditional’ (Fowler) refactorings can potentially breakpointcuts.Wloka et al. created a tool that explicitly synchronizes (updates)pointcuts when refactoring, using a change impact analysis. Most toolsignore the issue it seems.


Codesmells for AspectJ

Technology

Transcript of Codesmells for AspectJ