Codesmells for AspectJ

AOP refactoring and code smells

Towards a Catalogue of Refactorings and Code Smells
for 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

Introduction
1

AOP and refactoring
2

The paper
3

Other approaches
4

Conclusion
5

Questions
6


AOP refactoring and code smells > Introduction

In the beginning

Inﬂuential book by Martin Fowler (1999)

Preceded by PhD work of William Opdyke
(1992)

Many papers on OO refactoring followed



Deﬁne 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 way
that it does not alter the external behavior of the code, yet improves
its internal structure. Martin Fowler



Deﬁne 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 way
that it does not alter the external behavior of the code, yet improves
its internal structure. Martin Fowler

Behavior preserving
Structure changing
Improving design

Refactorings are small transformation steps for code



Why refactor?

Maintainable code
More understandable code
Compliance to standard practices
Speeds 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



Why refactor?

Maintainable code
More understandable code
Compliance to standard practices
Speeds 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 a
row... refactor it!
When adding new functionality
ﬁt it in elegantly by refactoring
otherwise risk spaghetti-code...
During code review
Everytime you ﬁnd 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 ﬁnd what
it needs, but nothing more
Temporary ﬁeld class member is used where local local scope would
have 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



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 fact
in 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 mechanisms
Ideally: each concern separated, but you cannot separate what you
cannot compose later
Experience
Follow good style rules
E.g. as documented in catalogue
Avoiding 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:
There is no notion of good AOP style yet
1

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

smells
Toolsupport for integrating AOP with refactoring is lacking
3

Preservation of intention over preservation of behavior



The paper

Three categories of refactorings:
OO → AspectJ (10)
1

AspectJ internal refactorings (6)
2

part of OO refactorings can be ported to aspects
other refactorings handle new concepts, e.g. pointcuts
Inter-aspect refactorings (11)
3

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 workﬂow program was decomposed into use cases. Use cases were
captured 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 were
studied. Goal: try to describe transformation of OO → AOP in terms
of refactorings
Great variety of diﬀerent aspects
No domain knowledge necessary
Some refactorings were too case speciﬁc (this needs to be
recognized)



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 ﬁndings is debatable



OO to AOP refactoring

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

Usually combined with inline interface with aspect



AOP internal refactoring
Introduce aspect protection
Problem: restrict usage of inter-type ﬁeld to aspect and its sub-aspects




Minor criticism:
A bit of a hack
Very speciﬁc to AspectJ




Minor criticism:
A bit of a hack

In comparison, a refactoring like replace inter-type ﬁeld with aspect
map is much more general .

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




Minor criticism:
A bit of a hack

In Remark by Wouter
comparison, a refactoring like replace inter-type ﬁeld with aspect
map the ”Introducegeneral .Protection” section, you might want to have
In is much more Aspect
some modiﬁer that takes care of the protection?

Also, OO refactorings canthis used in aspects (extract method,
Sure, that would make be refactoring unnecessary




Minor criticism:
A bit of a hack
Remarkspeciﬁc to AspectJ
Very by Elmar
Some of the refactorings like ”Introduce Aspect Protection” seem to
thank their existance to (unclear, incomplete, faulty) semantics of
In comparison, a refactoring like replace inter-type ﬁeld with aspect
AspectJ. Take for example the ”Introduce Aspect Protection” Can’t
map is much more general .
we argue that some of these semantics for AspectJ should change,
instead of making a work around using refactoring?
Also, OO refactorings can be used in aspects (extract method,
Indeed. Still the existance of this refactoring in the catalogue
makes a programmer aware of the issues.




Replace inter-type ﬁeld with aspect map
Problem: aspect introduces additional state to a class, but it might
not need it all the time, so resources are wasted
Inter-type declarations aﬀect all instances of a class
Inter-type declarations last a lifetime




Replace inter-type field with aspect map
Problem: aspect introduces additional state to a class, but it might
not 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 all
field accesses to the aspect

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



AOP generalisation refactoring

Goal of these refactorings: transform an application speciﬁc aspect
into a generalized, reusable aspect.

Again, much of the OO idiom can be ported to aspects, with subtle
diﬀerences:

There is no inheritance/overriding between advice (as opposed to
methods)
Therefore it sometimes necessary to push down advice
Weaving behavior might be surprising



AOP generalisation refactoring

Pull up inter-type declaration
Problem: inter-type declaration is better placed in a super aspect (not
because of duplication!)

Issues:
Targets of inter-type declarations receive an instance of the
declaration per aspect
When refactoring identical inter-type ﬁelds to super aspect, only
one instance is created at weaving time
Compare to making a ﬁeld 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 speciﬁc 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-type
declarations
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 are
inherently scattered

I think automation is essential to:
Detect OO → AOP refactorings
1

Detect refactorings within aspects
2

Apply AOP refactorings
3

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 ﬁnd 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:
Anonymous pointcut deﬁnitions
1

Large aspects
2

Lazy aspects
3

Feature envy (deﬁned as: class containing pointcut)
4

Abstract method introduction
5

Implemented in plugin for AspectJ eclipse extension



AOP code smells

Architecture plugin
Described smells and algorithms:
Anonymous pointcut deﬁnitions
1

Large aspects
2

Lazy aspects
3

Feature envy (deﬁned as: class containing pointcut)
4

Abstract method introduction
5

Implemented in plugin for AspectJ eclipse extension



Anonymous pointcut detection



Anonymous pointcut detection

In other words: all pointcuts containing AspectJ pointcut primitives


Abstract method introductions
Abstract methods demand implementation, creates unnecessary
coupling 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
Output analysis

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



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 ﬂow graph
With additional information on data

Automates application of refactorings



Refactoring tool

24 refactorings are
proposed:
OO → AOP
refactorings
internal AOP
refactorings
there is ample overlap with
session paper

Diﬀerence: refactorings are
composed with laws



Refactoring tool

Example law, move ﬁeld to aspect:
24 refactorings are
proposed:
OO → AOP
refactorings
internal AOP
refactorings
there is ample overlap with
session paper

Diﬀerence: refactorings are
composed with laws



Aspect Mining

So far we’ve seen tools to:
Find code smells
Find OO refactorings
Apply refactorings

In order to ﬁnd OO → AOP refactorings, we need something like
aspect mining.



Aspect Mining

So far we’ve seen tools to:
Find code smells
Question: Rinse
Refactoring refactorings
Find OO code into aspects can become a little tedious when trying
to Apply refactorings
track down all classes involved in say a observer pattern. There is
research being done in aspect mining techniques [1] do you think with
In the proposed catalogue of refactorings and code smells for AspectJ and
order to ﬁnd OO → AOP refactorings, we need something like
aspect mining.mining techniques we could come anything close to the
these aspect
current support for refactorings in IDEs for normal OO concerns?
[1]: Applying and combining three diﬀerent aspect Mining Techniques



Aspect Mining

Approach created at TU Delft, combines and compares three aspect
mining techniques:
Fan-in analysis
1

Identiﬁer analysis
2

Dynamic analysis
3

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



Aspect Mining

Fan-in analysis
Count number of locations from which control is passed into a
module
In OO: fan-in for method M is number of distinct bodies that can
call M
Idea: if a method is called from many places, it is probably
cross-cutting
Certain treshold needs to be in place (experimentally determined
value: 10)
Analysis excludes getter/setters and utility methods like toString()



Aspect Mining

Identiﬁer analysis
Lexical analysis of identiﬁers 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 is
probably a cross-cutting concern
Depends on naming conventions



Aspect Mining

Dynamic analysis
Analyse execution traces of (instrumented) program
Run program with diﬀerent scenarios (use cases)
Keep track of locality in code (call stack)
Analyse which methods relate to which use case and which are
generic
Depends on well-chosen scenarios



Aspect Mining

A framework was devised to test all analyses. Some concerns as
detected:
Contract enforcement (pre-condition checking)
Undo
Observer pattern
Persistance (read/write functionality)

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



Other tools/methods

Rolebased Refactoring Hannemann & Kiczales
Programmer maps conceptual concerns to code
fragments. Tools helps with mapping, and
with manipulating the code fragments.
Aspect mining tool Lexical analysis and type based analysis, with
stand alone visualizer. Based on modiﬁed ajc
FEAT/ConcernMapper Eclipse plugin to navigate/analyze/refactor
AspectJ code.
Concern Manipulation Eclipse plugin (originally by IBM) to manage
Environment 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 ﬁeld is fairly new and open
There are many (research)tools, but
Its not very clear how these all relate and how powerful they are
To answer Rinse’s question: I don’t think it comes near legacy
refactoring 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
Master’s thesis
Moving refactoring from OO to AOP brings in a lot of subtleties
May be someone should take on this challenge and survey the
(aspects vs. classes)
AOP refactoring tools ﬁeld and create the ultimate formalism and
tool for refactoring research ﬁeld is fairly new and open
AOP AOP refactoring :-) ?
There are many (research)tools, but
Its not very clear how these all relate and how powerful they are
To answer Rinse’s question: I don’t think it comes near legacy
refactoring support yet


AOP refactoring and code smells > Questions

Question: Wouter

I think that some of the problems could be solved better with some
Java 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 deﬁning a role/type that the class then
’implements’. But the Interface/implements constructs of Java aren’t
really designed for modeling roles right? I think that there might be a
need for some stronger or better typing system than this (maybe
something like Haskell’s?).



Question: Wouter

I think that some of the problems could be solved better with some
Java 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 deﬁning a role/type that the class then
’implements’. But the Interface/implements constructs of Java aren’t
really designed for modeling roles right? I think that there might be a
need for some stronger or better typing system than this (maybe
something like Haskell’s?).

Let’s discuss



Question: Wouter

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



Question: Wouter


Sure. Short answer: nothing.



Question: Wouter


Sure. Short answer: nothing. Why?
Refactorings per deﬁnition depend on a language
And aim to optimize usage of a language, e.g.:
goto considered harmful
switch 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 it
would allow new refactorings



Question: Gerbo

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



Question: Gerbo

Question: Niels
The designers of Java hadsmell just seems like a allow multiple
The abstract class code their reasons not to solution for multiple
(implementation)looks like another AspectJdescribe it is: ”Whenever
inheritance. It inheritance, but way to opened some sort of back
door byextend (interfaces combined implementation you should use
you using a class just for the with) aspects for it. And the paper
even recommendsinter type declarations.”. Orclass intothis wrong?
interfaces and this usage (“Split abstract do I see aspect and



Question: Gerbo
Diamond problem

The designers of Java had their reasons not to allow multiple
(implementation) inheritance, but AspectJ opened some sort of back
door by using (interfaces combined with) aspects for it. And the paper
even recommends this usage (“Split abstract class into aspect and



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 eﬀectively extracts a mixin from the original
abstract class
mixin: class that provides functionality to other classes, not created
for 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 as
inter-type addition



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 as
inter-type addition

This last point will be ﬂagged by ajc

Conclusion: no multiple inheritance, rather: default implementations
for interfaces.



Question: Nabil

Could you please elaborate more on when to use Extend Marker
Interface with Signature? Because according to the authors it is used
when you need to call a method that is specific to a type implementing
an interface that doesn’t declare the wanted method. However in the
precondition the authors argue that this refactoring is only feasible if
all types implementing the interface export the signature of the
method we want to call. So if all types export the signature then the
method we want to call is not specific to a certain type, thus no
refactoring is required. And if the types implementing the marker
interface don’t export the signature and we have to enforce them to
export the signature, then I would rather stick with downcast solution.
But instead of doing it as illustrated in the paper, I would define
another interface extending the marker interface and make it declare
the specific method and then make the specific type implement the
new interface.


Question: Nabil

public aspect AA {
public class A {
interface Role{}
public static void doA(){} interface Role2 extends Role{
public void specificMethod();
} }

public class B { declare parents: A implements Role;
declare parents: B implements Role2;
public static void doB(){}
public void specificMethod(){} public void something(Role obj){
((Role2) obj).specificMethod();
} }
}



Question: Nabil

public aspect AA {
public class A {
Solution in paper interface Role{}
Inter-type static void doA(){}
public method introduction: interface Role2 extends Role{
public void specificMethod();
} }
public abstract void Role.doSomething();

public class B { declare parents: A implements Role;
declare parents: B implements Role2;
public static void doB(){}
public void specificMethod(){} public void something(Role obj){
((Role2) obj).specificMethod();
} }
}



Question: Nabil

Comparing the solutions:
Speciﬁc 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 implement
injected method
Nabil’s solution avoids this
.. paper calls its solution stopgap for a reason, they had a
speciﬁc 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) if
the recommended action proposes another super-aspect which extends
the previous super aspect (in cases where code duplication would
occur) right?



Question: Niels

The ”Push down” refactoring rules are better (less code duplication) if
the recommended action proposes another super-aspect which extends
the previous super aspect (in cases where code duplication would
occur) right?

All I can say:
Push down refactorings do not avoid code duplication, but try to get a
more logical placement for concerns in the aspect hierarchy. It could
even 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 match
every public method call. And suppose we refactor a public method to
a private method. (Then we might also need to modify the pointcut.
So that would be a problem.) Can we detect and solve this problem
when refactoring (to preserve the behavior)?



Question: Jinfeng

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

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

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

Codesmells for AspectJ

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Codesmells for AspectJ

Similar to Codesmells for AspectJ (20)

More from Sander Mak (@Sander_Mak)

More from Sander Mak (@Sander_Mak) (20)

Recently uploaded

Recently uploaded (20)

Codesmells for AspectJ