Parametric Aspects. A way to design-pattern implementation (...and others)? Jordi Alvarez Open University of Catalonia Barcelona - Spain [email protected].

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