aspect oriented programming and design

Aspect-OrientedProgramming and Design

For Java and AspectJ

Dean WamplerObject Mentor, Inc.

[email protected]

1Friday, September 7, 2007

http://creativecommons.org/licenses/by/3.0/







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


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

For example...


Cleanand

Simple4Friday, September 7, 2007

However,

Real applications need:

public class BankAccount {

public Money getBalance(){...}

public void credit(Money m) {...}

public void debit(Money m) {...}

...

}

Transactions

Persistence

Security


public void credit(Money m) { if (unauthorized()) throw new ...(); Money saveBalance = balance; try { beginTransaction(); balance += m; persistBalance(balance); } ...

Back to our example...


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


What’s wrong??


We’re mixing multiple domains,

Transactions

Persistence

Security

with fine-grained intersections.

“Problem Domain”

“tangled” code

“scattered” logic


Aspects restore modularity byencapsulating the intersections.

Transactions

Persistence

Security

TransactionAspect

PersistenceAspect

SecurityAspect


Obvious uses:

PersistenceTransactions

SecurityLogging

others...


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


Back to what we want...


public aspect PersistentAccount{ pointcut newBalance ( Account a, Money newBal): set (Money Account.balance) && args (newBal) && this (a); ...

Back to our example...class-like declaration

named set of “join points”

bind variables

any time “balance” is setremember new value

remember “this”


... after ( Account a, Money newBal) : newBalance(a, newBal) { persist(a, newBal);}


“after advice” same arguments

same pointcut

body of the advice


Types of advice

beforeafter returningafter throwing

afteraround


Other terms

• Join point

• Pointcut

• Advice

• Cross-cutting concern

• Introduction (a.k.a. Inter-type declaration)

• Aspect


Pure Java AOPSpring AOPJBoss AOP


Spring AOP@AspectJ Support


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

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


<aop:aspectj-autoproxy/>...<bean id=”persistantAccount” class=”...PersistentAccount”> </bean>

auto-configure @Aspects

The usual Spring bean stuff...

<aop:config> <aop:advisor pointcut="....newBalance()" advice-ref="tx-advice"/> </aop:config>

<tx:advice id="tx-advice"> <tx:attributes> <tx:method name="*" propagation="REQUIRED"/> </tx:attributes> </tx:advice>

Wire another advice using XML


Spring’sDependency 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)

Account

name

Account

first_namelast_name

Version 1 Version 2

???X


Aspects make initial version easier,

But subsequent versions harder!


AOP-Evolution

Paradox!


Obliviousness ...

... is like that.


We forgot established

OOD Principles.


Principles of OOD

11


Single Responsibility Principle

A class should have only one reason to change.

#1


Open-Closed Principle

A module should be open for extension, but closed

for modification.

#2


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?

is a


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

An Aspect Refactoring...



{...} 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();

} 45Friday, September 7, 2007

Liskov Substitution Principle

Subtypes must be substitutable for their

base types.

#3


Square is a Rectangle?is a

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...



{...} List<Point> getVertices() {...}}

Need to Change Polygon:

Occasionally need to break OCP...

Package private!


package shapes; // same packageimport ...;

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,0)

(0,5) (2,5)

(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);assertEquals(3, r.getWidth());assertEquals(5, r.getHeight());



Prove it! (or not...)

is a


...Rectangle r = new Square(p00,p50,p55,p05);assertEquals(5, r.getWidth());assertEquals(5, r.getHeight());

r.setWidth(3);

assertEquals(3, r.getWidth());assertEquals(5, r.getHeight());

What if I Use a Square?

This won’t pass!



Not inthis context!!

is a


LSP

Context Dependent!

Is


LSP Is the Basis for

Design by Contract


Shameless Plug...61Friday, September 7, 2007

@Contractpublic abstract class Polygon implements Shape { @Pre(“index>=0”)@Post(“$return != null”) public Point getVertex(int index){...}

}

Contract4J: DbC for Javaannotation-based


Dependency Inversion Principle

Abstractions should not depend upon details.

Details should depend upon abstractions.

#5


Client

Service

Client Service

Service


Client «aspec t»ClientService

Service


Service

Client Service

Service


New AOD Principles


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

No


Open-Closed Principle: UpdatedA module should be open for

extension, but closed for source and contract modification.


public aspect Tracer { before(): call(* Polygon.*(..)) { log(thisJoinPointStaticPart); } }

public class LoggedPolygonDraws { public void draw() { log(“Polygon.draw”); super.draw(); } }

Similar!


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 “firstName” and “lastName”??


Pointcut Inversion Principle

Pointcuts should not depend upon concrete details.

Pointcuts should depend upon abstractions.


The Future of AOP


• Much hyped in the 90s

• All or nothing proposition

• ... due to internal dependencies

Components and Frameworks

Can aspects reduce the coupling and make them more reusable?



Service


Service


• High-level defines policy

• Low-level defines details

Improved Architectures

Better separation using aspects?


• Domain-Specific Languages for the high-level

• Connect to low-level details with aspects

Improved Architectures


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.intersection


Obvious uses:

PersistenceTransactions

SecurityLogging

others...


The future?

Better architectures(Domain-specific languages)

Better components and frameworks


Thank You!

• [email protected]

• http://objectmentor.com

• http://aspectprogramming.com

• http://contract4j.org

• http://aquarium.rubyforge.org


mailto:[email protected]

mailto:[email protected]

http://objectmentor.com

http://objectmentor.com

http://aspectmentor.com

http://aspectmentor.com

http://contract4j.org

http://contract4j.org

http://aquarium.rubyforge.org

http://aquarium.rubyforge.org








aspect oriented programming and design

Technology

public void creditmoney

public class account

public interface shape

public money getbalance

public string tostring

public string polygon

public interface drawable

drawablepublic void