parametric aspects. a way to design-pattern implementation (...and others)? jordi alvarez open...
TRANSCRIPT
Parametric Aspects.Parametric Aspects.A way to design-pattern implementation A way to design-pattern implementation
(...and others)?(...and others)?
Jordi AlvarezJordi AlvarezOpen University of CataloniaOpen University of Catalonia
Barcelona - SpainBarcelona - [email protected]@uoc.edu
Certain problems cannot be adequately solved with OO+AOP
•Example 1: Some design patterns in GoF can be implemented in an abstract way using AOP, but others not.
•Example 2: For some problems (like EJB development) we still need to provide a lot of redundant code.
Motivation
Goal: provide aspect language extensions that allow to provide reusable implementations with no redundant code for a broader range of problems than that provided nowadays by OO+AOP.
(Our) Solution
•Adapt parametric-type ideas to separation of concerns.
•This should be done in a very flexible way and allow powerful results!
Example domain 1: Design Patterns. OO solution
Alternatives
a) Automatic code-generation
b) Reusable pattern implementation
Design patterns
Problem domain
Program
patterncode
domaincode
Designpatterns
problemdomain
patterncode
domaincode
Pattern application
domain code
Pattern library
abstractpatterns
concreteaspects
Reusable pattern implementation (Hannemann&Kiczales)
•Code reuse: design patterns are implemented only once
•Pattern-code isolated from domain code (untangling)
•Pattern code unscattered
Reusable implementation of design patterns: advantatges
OO development AOP development
pattern implementation
patterncode
domaincode
Works on design pattern implementation
•Hannemann & Kickzales
•Hachani & Bardou
•Noda & Kishi
- Study from 23 GoF patterns.- Remove dependencies between participants and patterns.- Implements 12 of them in a completely reusable way.
- Implement Visitor and Strategy [GoF].- Implement directly as an application.
- Implement Observer, Composite and Adapter.- Code reuse.
Problematic patterns
•Creational
•Low level
•Too abstract
Goal: provide (aspect) language extensions that allow us to board some of these patterns.
Creation is related to the nature of the created entity.
Correctly implemented without aspects.
- Describe design structure.- It is complex to provide an implementation for them without taking into account the concrete application domain.
Parametric Aspects
Proposal: add parametric-type ideas to AOP
•Detailed specification of patterns.
•Parameterized/template classes
Patterns
Parametric aspects
•Parameterized/template methods
•Parameterized/template expressions
-Sets of classes (new role type)
-Class generation from roles-Allowing also multiple class generation
-Method generation from roles-Allowing also multiple role generation
-Compile-time evaluable-Should allow class hierarchy traversal
•Name composition.
Abstract Factory Pattern
Abstract Factory applied to GUI components
Abstract Factory applied to GUI components :detailed role specification
AbstractFactory
ConcreteFactory
AbstractProduct
ConcreteProduct
ProductSet
class <AbstractFactory> { …}
Class generation from roles
abstract class ComponentFactory { …}
aspect ComponentFactoryPattern extends FactoryPattern {
class ComponentFactory plays AbstractFactory; ...}
Parameterized/template classes
class <ProductSet>Factory extends<AbstractFactory> {
…}
Parameterized/template classes
Multiple generation of classes
aspect ComponentFactoryP ext. FP { ... class-set A plays ProductSet { ... } class-set B plays ProductSet {... }}
class AFactory extends ComponentFactory { …}
class BFactory extends ComponentFactory { …}
ProductSet=BProductSet=A
Method generation from roles / Multiple generation of roles
class <AbstractFactory> {
public abstract <AbstractProduct> create<AbstractProduct>();}
abstract class CompFact {
public abstract Window createWindow();
public abstract ScrollBar createScrollBar();
public abstract Button createButton();}
aspect ComponentFactoryPattern extends FactoryPattern { class ComponentFactory plays AbstractFactory; class Window plays AbstractProduct; class ScrollBar plays AbstractProduct; class Button plays AbstractProduct; ...}
Parameterized/template methods
Evaluable at compile-timeShould allow class hierarchy traversal
class <ProductSet>Factory extends<AbstractFactory> {
public … create<AbstractProduct>() { return new <subclasses(AbstractProduct) & members(ProductSet)>(); }
}
class AFactory … { … return new AWindow(); … return new AScrollBar(); … return new AButton();}
class BFactory … { … return new AWindow(); … return new AScrollBar(); … return new AButton();}
aspect ComponentFactoryPattern extends FP { class Window plays AbstractProduct; class ScrollBar plays AbstractProduct; class Button plays AbstractProduct; class-set A plays ProductSet { AWindow, AScrollBar, AButton; } class-set B plays ProductSet { ... } }
Parameterized/template expressions
<subclasses(AbstractProduct) & members(ProductSet)>
class AFactory … { … return new AWindow(); … return new AScrollBar(); … return new AButton();}
Class BFactory … { … return new AWindow(); … return new AScrollBar(); … return new AButton();}
Window
A
Parameterized/template expressions
What are we conceptually doing?
Object Oriented (OO)
hierarchical definitionof behavior
Aspect Oriented (AOP)
Injects/intercepts codemodifying the structure
AOP + “parametric aspects”
Injects/intercepts codemodifying the structure
Generates codebased on thestructure