WINDEV Fall 2002, Boston MA 04/18/23

Aspect-Oriented Programming:The Good, the Bad, the Ugly and the Hope

John Lam

Naleco Research Inc.

http://www.iunknown.com

WINDEV Fall 2002, Boston MA 04/18/23 2

John Lam

• Shipped 8 software products• Working around-the-clock on shipping product #9• Authored Programming ASP.NET for Wintellect• Co-authored Essential XML and Delphi Developers

Handbook• Read my web log at http://www.iunknown.com • Contact me at jlam@iunknown.com

WINDEV Fall 2002, Boston MA 04/18/23 3

Agenda

• Zooming in: Stating the problem• The Good: Aspects solve an important class of problems• The Bad: Programming stateful aspects is hard• The Ugly: Handling aspect side-effects is really hard• The Hope: Aspects find a place in your toolbox

WINDEV Fall 2002, Boston MA 04/18/23 4

The view from 35,000 feet

WINDEV Fall 2002, Boston MA 04/18/23 5

Monolithic programs

WINDEV Fall 2002, Boston MA 04/18/23 6

Modular programming

WINDEV Fall 2002, Boston MA 04/18/23 7

Object-oriented programming

WINDEV Fall 2002, Boston MA 04/18/23 8

AOP: Identifying cross-cuts

WINDEV Fall 2002, Boston MA 04/18/23 9

AOP: Defining aspects

WINDEV Fall 2002, Boston MA 04/18/23 10

AOP: Weaving aspects

WINDEV Fall 2002, Boston MA 04/18/23 11

The view from 5,000 feet

WINDEV Fall 2002, Boston MA 04/18/23 12

Monolithic programs

WINDEV Fall 2002, Boston MA 04/18/23 13

What is software?

• Software expresses solutions to problems• Humans decompose complex problems into simpler

problems• Humans express solutions to problems using a

programming language• Programming language imposes constraints on how the

problem is decomposed– "Tyranny of the dominant decomposition" – Peri Tarr

WINDEV Fall 2002, Boston MA 04/18/23 14

Tackling the software problem

• Programming in the small– Decompose problem into programming language statements

• Programming in the medium– Decompose problem into modules / classes / objects

• Programming in the large– Decompose problem into components

WINDEV Fall 2002, Boston MA 04/18/23 15

Unstructured code

• Code paths are tangled– Goto's cross each other

10 let i = 120 if i > 4 then goto 6030 print i40 i = i + 150 goto 2060 print "done"

WINDEV Fall 2002, Boston MA 04/18/23 16

Elegant unstructured code

• Code paths not tangled• Code is compact• Code is idiomatic

– Put test at end

10 let i = 120 print i30 i = i + 140 if i < 4 then goto 2050 print "done"

WINDEV Fall 2002, Boston MA 04/18/23 17

Language support for elegance

• Language support encourages (enforces?) best practices– Discourages goto

int i = 1;while( i < 4 ){ print( i );}

WINDEV Fall 2002, Boston MA 04/18/23 18

Why does elegance matter?

• Computer does not care!• Programs always change

– ~10X maintenance vs. original development

• Programs become resistant to change over time– Must be readable by others– Must have obvious extensibility points– Must have well-designed unit tests to encourage extensibility

WINDEV Fall 2002, Boston MA 04/18/23 19

Is elegance enough?

• Suitable for programming in the small• Suitable for enhancing localized understanding of code• Unsuitable for sharing secrets• Unsuitable for building larger abstractions• Unsuitable for understanding larger abstractions

WINDEV Fall 2002, Boston MA 04/18/23 20

Modular programming

WINDEV Fall 2002, Boston MA 04/18/23 21

Modularization

• Decompose problem into independent modules• Each module exposes a public interface• Each module hides implementation from caller

WINDEV Fall 2002, Boston MA 04/18/23 22

Modularization: Windows

• Windows operating system code is highly modularized– kernel32.dll– user32.dll – gdi32.dll – dbghelp.dll– ole32.dll– comctl32.dll– ws2_32.dll– mscoree.dll

WINDEV Fall 2002, Boston MA 04/18/23 23

Modularization and Abstraction

• Modularization == separation of concerns– Based on common functionality– Based on shared secrets

• Modularization encourages abstraction– Interact with module only using its interface – Lets us look at overall system structure– Lets us zoom in on one part of system at a time

WINDEV Fall 2002, Boston MA 04/18/23 24

Is modularization enough?

• Modules are too coarse-grained– Public interface is too wide (kernel32.dll exports 928 methods!)– Hierarchical organization impossible– Secrets go hand-in-hand with certain methods

• We need to raise the abstraction bar– Think in terms of smaller "bundles" of code and data– Helps us deal with increasing complexity

WINDEV Fall 2002, Boston MA 04/18/23 25

Object-oriented programming

WINDEV Fall 2002, Boston MA 04/18/23 26

Object-oriented programming

• Decompose problem into independent classes• Each class exposes a public interface• Each class exposes a protected interface• Each class hides implementation from caller• Each class hides (some) implementation from

descendents

WINDEV Fall 2002, Boston MA 04/18/23 27

System.Object

System.Web.UI.Control

WebControl

Button

Repeater

CheckBox

HyperLink

Image

AdRotator Calendar

ValidationSummary

System.Web.UI.WebControls Namespace

Label

LinkButton

Panel

RadioButton

ImageButton

Table

BaseDataList

DataList

DataGrid

ListControl

CheckBoxList

DropDownList

ListBox

RadioButtonList

BaseValidator

CompareValidator

CustomValidator

RangeValidator

RegularExpressionValidator

RequiredFieldValidator

TableCell

TableRow

TextBox

TableHeaderCell

OOP: .NET Frameworks

WINDEV Fall 2002, Boston MA 04/18/23 28

Is OOP enough?

• Some code must cut across class hierarchies• Interface-based programming helps on definition

– Consider ICloneable, IDisposable in FCL– Offers no assistance on the implementation

• What happens if you need to retrofit cross-cutting code against existing client applications?– Can't do it without modifying those apps!

WINDEV Fall 2002, Boston MA 04/18/23 29

AOP: Identifying cross-cuts

WINDEV Fall 2002, Boston MA 04/18/23 30

AOP: Defining aspects

WINDEV Fall 2002, Boston MA 04/18/23 31

AOP: Weaving aspects

WINDEV Fall 2002, Boston MA 04/18/23 32

Aspect-Oriented Programming

• Identify concerns that cut across class / object boundaries

• Write code (an aspect) that encapsulates that concern• Define a weave that specifies how the aspect will be

weaved into existing code

WINDEV Fall 2002, Boston MA 04/18/23 33

The view from 50 feet

WINDEV Fall 2002, Boston MA 04/18/23 34

The Good: AOP solves problems

Public Function ReadEmployeeSalary( id as Integer ) as Single

Trace.WriteLine( String.Format( "Reading employee # {0}'s salary", id ) )

If System.Threading.Thread.CurrentPrincipal.IsInRole( "manager" ) Then Try

' Code that reads employee's salary

Catch e as FatalException Logging.LogFatalException( e, "ReadEmployeeSalary" ) End Try End If

End Sub

WINDEV Fall 2002, Boston MA 04/18/23 35

Policies and software

• Method implements three policies in addition to its code!– Tracing policy: all public methods must be traceable– Security policy: employee salary only readable by managers– Exception policy: all FatalExceptions must be logged

• Should not mix policies and code– Developers need to know to put policy code in there– Policies obscure the method's implementation

WINDEV Fall 2002, Boston MA 04/18/23 36

Aspects can implement policies

Public Function ReadEmployeeSalary( id as Integer ) as Single

Trace.WriteLine( String.Format( "Reading employee # {0}'s salary", id ) )

If System.Threading.Thread.CurrentPrincipal.IsInRole( "manager" ) Then Try

' Code that reads employee's salary

Catch e as FatalException Logging.LogFatalException( e, "ReadEmployeeSalary" ) End Try End If

End Sub

1

2

3

WINDEV Fall 2002, Boston MA 04/18/23 37

Aspects can implement policies

public class SecurityPolicy{ public bool AccessCheck() { return System.Threading.Thread.CurrentPrincipal.IsInRole( "manager" ); }}

public class TracingPolicy{ public void Before( CallContext c ) { Trace.WriteLine( String.Format( "Called: {0}", c.MethodName ) ); }}

public class ExceptionPolicy{ public void Thrown( FatalException e ) { Logger.LogFatalException( e ); }}

1

2

3

WINDEV Fall 2002, Boston MA 04/18/23 38

Weaving aspects before methods

public class TracingPolicy{ public void Before( CallContext c ) { Trace.WriteLine( String.Format( "Called: {0}", c.MethodName ) ); }}

<weave> <aspect target="public *.*::*( * )" type="Before" method="TracingPolicy.Before( CallContext )"/></weave>

WINDEV Fall 2002, Boston MA 04/18/23 39

Weaving aspects around methods

public class SecurityPolicy{ public bool AccessCheck() { return System.Threading.Thread.CurrentPrincipal.IsInRole( "manager" ); }}

<weave> <aspect target="[ interface:ManagerOnly == true ] public *.*::*( * )" type="Around" method="SecurityPolicy.AccessCheck()"/></weave>

[ ManagerOnly ]public interface ISensitiveEmployeeData{ float ReadEmployeeSalary( int id ); ...}

WINDEV Fall 2002, Boston MA 04/18/23 40

Weaving aspects around methods

public class ExceptionPolicy{ public void Thrown( FatalException e ) { Logger.LogFatalException( e ); }}

<weave> <aspect target="public *.*::*( * )" type="Thrown( FatalException )" method="ExceptionPolicy.Thrown( FatalException )"/></weave>

WINDEV Fall 2002, Boston MA 04/18/23 41

The Bad: Stateful aspects

• Can be called from any join point at any time– Analogous to HTTP server code

• Calling protocol has no notion of causality• Aspect must explicitly manage state itself

WINDEV Fall 2002, Boston MA 04/18/23 42

The Ugly: Aspect side-effects

• Several aspects may be stacked at a join point• Several unintended interactions are possible:

– Aspect 1 is unaware of the side effects of Aspect 2– Code at the join point is unaware of side effects of any aspect

WINDEV Fall 2002, Boston MA 04/18/23 43

One Hope

• AOP development requires a heavy investment in visualization tools

WINDEV Fall 2002, Boston MA 04/18/23 44

Another Hope: Knowledge capture

• How do you learn a new technology?– Just do it!

• Discover best practices – Hang out on newsgroups / mailing lists– Read a book– Take a class– Requires self discipline!

• Enforce best practices

WINDEV Fall 2002, Boston MA 04/18/23 45

Why should you use aspects?

• Aspects can be applied as diagnostic probes– Detecting incorrect usage (e.g. leaked DB connections)– Detecting abusive usage (e.g. holding DB connections too long)

• Aspects can be used to enforce best practices• Aspects capture knowledge

– Write aspects as best practices are discovered– Share with the community

WINDEV Fall 2002, Boston MA 04/18/23 46

Who can use aspects?

• There will be different groups of users– Developers– Testers– Operations – Library developers– Systems administrators– Systems engineers / consultants

WINDEV Fall 2002, Boston MA 04/18/23 47

Types of aspect weavers

• Source-code aspect weavers– AspectJ (V1.0+)

• Link-time aspect weavers– Hyper/J (Alphaworks)

• Run-time aspect weavers– CLAW (prototype)

WINDEV Fall 2002, Boston MA 04/18/23 48

Where to go for more information

• Aspect-oriented programming– http://www.aosd.net– http://www.aspectj.org

• Hyper/J– http://alphaworks.ibm.com

• CLAW– http://www.iunknown.com