Aspect Oriented Programming and Design

Aspect-Oriented
Programming and Design
For Java and AspectJ

Dean Wampler
Object Mentor, Inc.
dean@objectmentor.com

Friday, September 7, 2007 1

public class Account {
public Money getBalance()
{...}
public void credit(Money m)
{...}
public void debit(Money m)
{...}
...
}


For example...
public void credit(Money m) {
balance += m;
}


Clean
and

Simple

However,
Real applications need:

Transactions
public class BankAccount {
public Money getBalance(){...}
public void credit(Money m) {...}
Persistence
public void debit(Money m) {...}
...
}
Security


Back to our example...
if (unauthorized())
throw new ...();
Money saveBalance = balance;
try {
beginTransaction();
balance += m;
persistBalance(balance);
} ...


...
} catch (...) {
balance = savedBalance;
} finally {
endTransaction();
}
}


What’s wrong??


We’re mixing multiple domains,
with ﬁne-grained intersections.
“tangled” code
Transactions

Persistence

Security

“Problem Domain”
“scattered” logic

Aspects restore modularity by
encapsulating the intersections.
Transaction
Transactions
Aspect

Persistence
Persistence
Aspect

Security
Security
Aspect


Obvious uses:
Persistence
Transactions
Security
Logging
others...


balance += m;
}
Back to what we want...


class-like declaration
public aspect PersistentAccount{
pointcut newBalance ( bind variables
Account a, Money newBal):
set (Money Account.balance) &&
args (newBal) && this (a);
remember “this”
... named set of “join points”
remember new value
any time “balance” is set


“after advice”
... same arguments
after (
Account a, Money newBal) :
same
newBalance(a, newBal) {
pointcut
persist(a, newBal);
}
body of the advice


Types of advice
before
after returning
after throwing
after
around


Other terms
• Join point
• Pointcut
• Advice
• Cross-cutting concern
• Introduction (a.k.a. Inter-type declaration)
• Aspect


Pure Java AOP
Spring AOP
JBoss AOP


Spring AOP
@AspectJ Support


@Aspect
class PersistentAccount {
@Pointcut
(“execution(* Account.*(..))”)
private void newBalance() {}

@After(“newBalance()”)
private void persistChange()
{...}
}


auto-conﬁgure @Aspects
<aop:aspectj-autoproxy/>
...
<bean id=”persistantAccount”
class=”...PersistentAccount”>

</bean>
The usual Spring bean stuff...

<aop:config> Wire another advice
using XML
<aop:advisor
pointcut=quot;....newBalance()quot;
advice-ref=quot;tx-advicequot;/>
</aop:config>

<tx:advice id=quot;tx-advicequot;>
<tx:attributes>
<tx:method name=quot;*quot;
propagation=quot;REQUIREDquot;/>
</tx:attributes>
</tx:advice>

Spring’s
Dependency Injection
can also wire
“POJO” aspects


Recommendation:
Use Spring to introduce AOP into your environment.


JBoss AOP works in
similar ways.


Aspect-Oriented Design
(Starting in the early years)


“Classes should be
oblivious to aspects.”


However, this leads to...


Persistence Aspect

PCD: set (* *.name)

X ???

Account Account
ﬁrst_name
name
last_name
Version 1 Version 2


Aspects make initial version easier,

But subsequent versions harder!


!
AOP-Evolution
x
o
d
a
r
a
P

Obliviousness ...
... is like that.


We forgot
established
OOD
Principles.

11
Principles of
OOD

#1

Single Responsibility
Principle
A class should have only
one reason to change.


#2

Open-Closed
Principle
A module should be open
for extension, but closed
for modiﬁcation.

An Example...


public interface Shape {
public double getArea();
public void draw();
}


public abstract class Polygon
implements Shape {
public Point getVertex(int index)
{...}
public void draw() {...}
public String toString() {...}
}


public class Square
extends Polygon {
public double getArea() {...}
}

public class Rectangle
extends Polygon {
public double getArea() {...}
}


Square is a Rectangle?

Isn’t it?


An Aspect Refactoring...

public interface Shape {
public double getArea();
public void draw();
}


implements Shape {
{...}
public void draw() {...}
public String toString() {...}
}


package shapes.tostring;
public aspect PolygonToString {
public String Polygon.toString()
{...}
}


package drawing;
public interface Drawable {
void draw();
}


package shapes.drawing;
import drawing.Drawable;
abstract aspect DrawableShape {
declare parents:
Shape implements Drawable;
public void Shape.draw() {
String cmd = makeDrawCmd();
getGraphics().sendCmd(cmd);
}
abstract String makeDrawCmd();
}

#3

Liskov Substitution
Principle
Subtypes must be
substitutable for their
base types.


What do the unit tests say?


public RectangleDrawTest {
extends ...

public void testDraw {
Shape[] shapes = new Shapes[] {
new Rectangle(...),
new Square(...)};
for (Shape s: shapes)
s.draw(); // just works...
}
}


Apparently, it is!!
(at least in this context...)


Mutability...


Need to Change Polygon:
implements Shape {
{...}
List<Point> getVertices() {...}
}
Occasionally need to break OCP...
Package private!


package shapes; // same package
import ...;
aspect MutablePolygon {
public void
Polygon.setHeight(int i) {
List<Point> list = getVertices();
// Change appropriate points...
}
public void
Polygon.setWidth(int i) {...}
}

public MutableRectangleTest ... {
public void testSetWidth{
Point p00, p20, p25, p05 = ...;
Rectangle rect =
new Rectangle(p00,p20,p25,p05);
(0,5) (2,5)

(0,0) (2,0)

public MutableRectangleTest ... {
public void testSetWidth{
Point p00, p20, p25, p05 = ...;
Rectangle r = new Rectangle
(p00,p20,p25,p05);
assertEquals(2, r.getWidth());
assertEquals(5, r.getHeight());
r.setWidth(3);
}
}


Prove it! (or not...)


What if I Use a Square?
...
Rectangle r = new Square
(p00,p50,p55,p05);
r.setWidth(3);

This won’t pass!

Not in
this context!!


LSP
Is
Context Dependent!


LSP Is the Basis for

Design by Contract


Shameless Plug...

Contract4J: DbC for Java
annotation-based
@Contract
implements Shape {
@Pre(“index>=0”)
@Post(“$return != null”)
{...}
}


#5

Dependency
Inversion Principle
Abstractions should not depend upon
details.
Details should depend upon
abstractions.

Client Service
Client

Service Service


Service
Client

Service

«aspect»
«aspect»
Client
Client
ClientService
ClientService

Service Service


New AOD Principles


package shapes.tostring;
public aspect PolygonToString {
public String Polygon.toString()
{...}
} Do introductions violate OCP??
No


Open-Closed
Principle: Updated
A module should be open for
extension, but closed for source
and contract modiﬁcation.


public aspect Tracer {
before(): call(* Polygon.*(..)) {
log(thisJoinPointStaticPart);
}
Similar!
}
public class LoggedPolygonDraws {
public void draw() {
log(“Polygon.draw”);
super.draw();
}
}

Liskov Substitution
Principle: Updated
Subtypes and aspects + base
types must be substitutable for
their base types.


public aspect PolygonMunger {
before(Polygon p): target(p) &&
call(* Polygon.draw(..)) {
p.addPoint(new Point(/*...*/));
}
}

Does this look safe??


Advice Substitution
Principle
Advice must obey the contract of
the advised join point.


public aspect CirclingPolygons {
public double Polygon.getRadius()
{...}
public Point Polygon.getCenter()
{...}
}

Huh??


Introduction
Substitution Principle
Introductions must obey the
contract of the module.


public aspect PersistentAccount {
after (Account a): target(a) &&
call(* Account.setName()) {
persistName(a.getName());
}
}

What happens when “name” is refactored
to “ﬁrstName” and “lastName”??


Pointcut Inversion
Principle
Pointcuts should not depend upon
concrete details.
Pointcuts should depend upon
abstractions.

The Future of AOP


Components and
Frameworks
• Much hyped in the 90s
• All or nothing proposition
• ... due to internal dependencies
Can aspects reduce the coupling
and make them more reusable?

«aspect»
«aspect»
Client
Client
ClientService
ClientService

Service Service


Improved Architectures

• High-level deﬁnes policy
• Low-level deﬁnes details

Better separation using aspects?


Improved Architectures

• Domain-Speciﬁc Languages for the high-level
• Connect to low-level details with aspects


public class PersistenceDSL {
public PersistenceDSL() {
after()
.calling(methodsIn(
interface(StateChange.class)))
.then(persistChange());
}
}

(Fanciful, made-up example...)


Conclusions


Real applications...

mix multiple domains...

causing tangled code.


Objects alone don’t
prevent this tangling.


Aspects modularize the
intersection
of the domains.


Obvious uses:
Persistence
Transactions
Security
Logging
others...


The future?

Better components and
frameworks

Better architectures
(Domain-speciﬁc languages)


Thank You!

• dean@objectmentor.com
• http://objectmentor.com
• http://aspectprogramming.com
• http://contract4j.org
• http://aquarium.rubyforge.org


Aspect Oriented Programming and Design

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (13)

Recently uploaded

Recently uploaded (20)

Aspect Oriented Programming and Design