Expressing the Crosscutting Concerns of Design Patterns: Compose and AspectJ Experience

1
Expressing the Crosscutting Concerns of Design
Patterns Compose and AspectJ Experience

• Stephan Huttenhuis

2
Contents

• Project Description
• Patterns some properties definitions
• Patterns in AspectJ
• Reusable Pattern Library
• Patterns in Compose
• Conclusions

3
Project Description

• GoF pattern implementations in AspectJ.
• GoF pattern implementations in Compose
• Comparing AspectJ and Compose implementations
• Compose patterns (like Multiple Views)
• Compose extensions

4
Patterns some properties definitions

• Pattern and Pattern Instances
• Pattern Roles define the functionality of the
  participants in the pattern context
• Defining Role (e.g. ConcreteFactory in
  AbstractFactory)
• Superimposed Role (e.g. Subject in Observer)
• Crosscutting exists in (some) patterns caused by
  roles or relation between roles.
• Implementation language affects pattern
  implementation

5
GoF pattern in AspectJ

• Every pattern is first implemented in Java and
  then in AspectJ
• Small scale implementations
• Studies
• Qualitative Study 1
• Based on (implicit) quality factors
• Grouping based on common features
• Quantitative Study 2
• Based on verifiable metrics
• Upscaled examples
• Grouping based on measurement results

1 Jan Hannemann Gregor Kiczales (2002)
2 Alessandro Garcia et al. (2005)
6
Study 1 Modularity Improvements

• Modularity improvements in 17 of 23 cases1
• Locality all dependencies between patterns and
  participants are localized in the pattern code.
  As well as pattern code.
• Reusability core pattern code is reusable.
• Composition Transparancy each instance of the
  pattern can be reasoned about independently.
• (un)pluggability switch between using a pattern
  and not.

1 Jan Hannemann Gregor Kiczales (2002)
7
Study 1 Grouping on common features

• Roles only used within pattern aspect
• Composite, Command, Mediator, CoR
• Aspects as object factories
• Singleton, Prototype, Memento, Iterator,
  Flyweight
• Language constructs causes pattern to disappear
  (from OO code)
• Adapter, Decorator, Strategy, Visitor, Proxy
• Multiple inheritance (based on interfaces)
• Abstract Factory, Factory Method, Template,
  Method, Builder, Bridge

8
Study 1 Reusable AspectJ Pattern Library

• A design pattern is reusable, its implementations
  usually are not.
• Abstract aspects contain code invariant in all
  pattern instances.
• Concrete aspects extend abstract aspects with
  variant pattern instance behavior.

9
Study 2

• Metrics for
• Separation of Concerns
• Cohesion
• Coupling
• Size
• Applied metrics to all code including the
  reusable aspect code.
• How about reusable code applied to several
  pattern instances.

10
Study 2 Separation of Concerns

• Group 1 Increased Separation
• Decorator, Adapter, Prototype, Visitor, Proxy,
  Singleton, Mediator, Composite, Observer,
  Command, Iterator, CoR, Strategy, and Memento.
• Group 2 Decreased Separation
• Template Method, Abstract Factory, Factory
  Method, Bridge, Builder, and Flyweight.
• Group 3 No Effect
• Façade, Interpreter, and State.

11
Study 2 Coupling, Cohesion and Size

• Group 1 Better Results for AO
• Composite, Observer, Adapter, Mediator, and
  Visitor
• Group 2 Better Results for AO in Most Measures
  (except 1)
• Decorator, Proxy, Singleton and State
• Group 3 Better Results for OO in Most Measures
• CoR, Command, Prototype and Strategy
• Group 4 Better Results for OO
• Template Method, Abstract Factory, Bridge,
  Interpreter, Factory Method, Builder, Memento,
  and Flyweight.
• Group 5 No Effect
• Iterator and Façade

12
Differences study 1 and 2

• Improved modularization (separation of concerns)
  in 17 implementations vs. 14.
• 12 solutions reusable vs. 4 (significant).
• Presence of abstract aspect (invariant behavior)
  doesnt immediately imply reusability
• 14 transparent composition of pattern instances
  vs. ???

13
Study 1 and 2 Predictive Model

• Predictive Model When to use AOP to implement
  patterns?
• With superimposed roles (separation of concerns)
  1
• What to do if a combination of superimposed and
  defining roles remains unclear
• Also include coupling and cohesion 2

1 Jan Hannemann Gregor Kiczales (2002)
2 Alessandro Garcia et al. (2005)
14
Reusable Pattern Library (General)

• Invariant code of a pattern
• Can this be expressed in the programming
  language?
• Variant code of a pattern
• Can we move pieces to invariant code by
  introducing new constructs or generics?
• Code in reusable library must be as general as
  possible. Making code generally applicable can
  result in more lines then with specific code
• Probably not all patterns can be made reusable.

15
Problems with reuse

• Often only reuse of structure and not of exact
  implementation possible.
• Maybe a template or something
• Composing multiple patterns can have extra
  consequences

16
Concern Granularity

• Is a pattern a concern, is a pattern role a
  concern, or is something else a concern?
• Depends on the level of abstraction
• Levels of Concerns
• Composition Filters have more then two levels of
  concerns
• AspectJ has abstract and concrete aspect levels

17
Improve AOP to increase reuse of patterns

• Patterns implemented in less modules then with
  OOP but still more then one per concern.
• More invariant code could be written if code can
  use some generic properties
• Type
• Names
• Arguments

18
Patterns in CF What we want

• Pattern instance implementations in Compose
• Multiple patterns that have shared participants
• Identification of a reusable pattern library
• A predictive model
• Comparison to AspectJ

19
Implementations in Compose

• Currently implemented Bridge, Strategy, State,
  Chain of Responsibility, Facade
• In a non-reusable way

20
Bridge pattern
21
Strategy pattern
22
Bridge / Strategy

• Both have a nice OO solution
• Bridge Abstractions and Implementators in
  different class hierarchies
• Strategy Strategies in a class hierarchy
• Both depend on a choice
• Bridge Select which Implementor to use with
  which Abstraction (based on some criteria)
• Strategy Select which Strategy object to use
  (based on some criteria)

23
Bridge concern

• filtermodule BridgeModule
• inputfilters
• ignore_constructors Dispatch
  .DefaultImplementation
• use_impl1 Dispatch use1 gt . impl1.
  
• use_impl2 Dispatch . impl2.
• superimposition
• selectors
• classes Class isClassWithName(Class,'
  Bridge.DefaultImplementation')

24
Strategy concern

• filtermodule Strategies
• inputfilters
• use_linear Dispatch m gt .sort
  linear.sort
• use_bubble Dispatch .sort bubble.sort
  
• superimposition
• selectors
• standard Class isClassWithName(Class,
  'Strategy.StandardSort')

25
Bridge / Strategy pattern instance in CF

• Cumbersome because of dummy initial object
  which prevents circular calls.
• Ignore constructors.
• Little improvement, if any, compared to
  OO-version.
• Meta filter is alternative to using conditions in
  combination with Dispatch filters.

26
Bridge / Strategy reusable?

• You could define choice at a predifined location
  that is automatically called
• The where, how and when is determined.
• Still the programmer needs to identify the what
  (exact decision).
• Choice made at that location fixed thus less
  flexible then letting the programmer make the
  choice.

27
State pattern

• State transition (informally)
• Based on
• Currentstate
• executed selector
• Information from instance variables
• determine the new state.

28
State Pattern
29
State Concern

• filtermodule emptyTransitions
• inputfilters
• empty_Insert_Normal Meta .insert
  transitions.empty_Insert_Normal
• superimposition
• selectors
• empty Class isClassWithName(Class,
  State.QueueEmpty' )

30
Work to be done

• Implement other instances of patterns
• Determine the degree of reuse possible
• Create a reusable library (if possible)
• Compare results to AspectJ studies

31
Conclusion

• AOP probably possitive effect on pattern
  instances.
• Creating a large reusable pattern library
  probably difficult with AspectJ and Compose.