Parametric Aspects. A way to design-pattern implementation (...and others)?

1. Parametric Aspects.A way to design-pattern implementation (...and others)? Jordi Alvarez Open University of Catalonia Barcelona - Spain jalvarezc@uoc.edu

2. Motivation • 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.

3. 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!

4. Program Design patterns Problem domain pattern code domain code Alternatives a) Automatic code-generation b) Reusable pattern implementation Example domain 1: Design Patterns. OO solution

5. Pattern application abstract patterns concrete aspects domain code pattern code domain code Reusable pattern implementation (Hannemann&Kiczales) Pattern library Design patterns problem domain

6. Reusable implementation of design patterns: advantatges pattern code pattern implementation domain code • Code reuse: design patterns are implemented only once • Pattern-code isolated from domain code (untangling) • Pattern code unscattered OO development AOP development

7. 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.

8. Problematic patterns • Creational • Low level • Too abstract 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. Goal: provide (aspect) language extensions that allow us to board some of these patterns.

9. Parametric Aspects Proposal: add parametric-type ideas to AOP • Detailed specification of patterns. Patterns -Sets of classes (new role type) • Name composition. • Parameterized/template classes -Class generation from roles -Allowing also multiple class generation Parametric aspects • Parameterized/template methods -Method generation from roles -Allowing also multiple role generation • Parameterized/template expressions -Compile-time evaluable -Should allow class hierarchy traversal

10. Abstract Factory Pattern

11. Abstract Factory applied to GUI components

12. Abstract Factory applied to GUI components : detailed role specification AbstractProduct AbstractFactory ConcreteFactory ConcreteProduct ProductSet

13. Parameterized/template classes Class generation from roles class <AbstractFactory> { … } aspect ComponentFactoryPattern extends FactoryPattern { class ComponentFactory plays AbstractFactory; ... } abstract class ComponentFactory { … }

14. ProductSet=A ProductSet=B class AFactory extends ComponentFactory { … } class BFactory extends ComponentFactory { … } Parameterized/template classes Multiple generation of classes class <ProductSet>Factory extends <AbstractFactory> { … } aspect ComponentFactoryP ext. FP { ... class-set A plays ProductSet { ... } class-set B plays ProductSet {... } }

15. abstract class CompFact { public abstract Window createWindow(); public abstract ScrollBar createScrollBar(); public abstract Button createButton(); } Parameterized/template methods Method generation from roles / Multiple generation of roles class <AbstractFactory> { public abstract <AbstractProduct> create<AbstractProduct>(); } aspect ComponentFactoryPattern extends FactoryPattern { class ComponentFactory plays AbstractFactory; class Window plays AbstractProduct; class ScrollBar plays AbstractProduct; class Button plays AbstractProduct; ... }

16. class AFactory … { … return new AWindow(); … return new AScrollBar(); … return new AButton(); } class BFactory … { … return new AWindow(); … return new AScrollBar(); … return new AButton(); } Parameterized/template expressions Evaluable at compile-time Should allow class hierarchy traversal class <ProductSet>Factory extends <AbstractFactory> { public … create<AbstractProduct>() { return new <subclasses(AbstractProduct) & members(ProductSet)>(); } } 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 { ... } }

17. Parameterized/template expressions class AFactory … { … return new AWindow(); … return new AScrollBar(); … return new AButton(); } Class BFactory … { … return new AWindow(); … return new AScrollBar(); … return new AButton(); } Window <subclasses(AbstractProduct) & members(ProductSet)> A

18. Aspect Oriented (AOP) Injects/intercepts code modifying the structure AOP + “parametric aspects” Generates code based on the structure Injects/intercepts code modifying the structure What are we conceptually doing? Object Oriented (OO) hierarchical definition of behavior