Intro To AOP

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 [email protected]


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


The view from 35,000 feet


Monolithic programs


Modular programming


Object-oriented programming


AOP: Identifying cross-cuts


AOP: Defining aspects


AOP: Weaving aspects


The view from 5,000 feet


Monolithic programs


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


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


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"


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"


Language support for elegance

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

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


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


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


Modular programming


Modularization

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


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


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


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



• 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


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


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!


AOP: Identifying cross-cuts


AOP: Defining aspects


AOP: Weaving aspects


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


The view from 50 feet


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


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


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


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


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>


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


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>


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


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


One Hope

• AOP development requires a heavy investment in visualization tools


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


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


Who can use aspects?

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


Types of aspect weavers

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

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

• Run-time aspect weavers– CLAW (prototype)


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

Intro To AOP

Technology

Transcript of Intro To AOP