Universityof Twente

Meta PatternsMeta Patterns

Common Principles behind Common Principles behind

Design Patterns & OO Frameworks Design Patterns & OO Frameworks

Lodewijk M.J. BergmansLodewijk M.J. Bergmans

Universityof Twente

IntroductionIntroduction

This presentation is based on the work of Wolfgang Pree:"Design Patterns for OO Software Development" (book)

"Meta Patterns - A Means for Capturing the Essentials of

Reusable Object-Oriented Design" (ECOOP '94)

Meta patterns describe a few generic structures and

techniques that are repeatedly found in design patterns

Relation to (GoF) design pattern catalog:

These are solutions to design problems when attempting to

construct flexible & adaptable frameworks

Pree calls these: 'framework example design patterns'

Universityof Twente

Hot spotsHot spots

a framework consists of two parts: a fixed, generic architecture of domain-knowledge

independent of specific applications

flexible, application-specific parts (hot spots)ready as a library, or defined by the application programmer

frameworkarchitecture:

fixed part,(application-independent)

hot spots: flexible parts,(application-tailorable)

Universityof Twente

Template & Hook methodsTemplate & Hook methods

Template method:

defines the fixed part

calls the hook methods

implements generic domain knowledge

Hook method:

the flexible part; to be (re-)defined

implements application-specifics

can be abstract method

A (non-abstract) hook method can be

again a template method itself

mt mh1mh2

C1::mt

C1::mh1

C1::mh2

C1

Universityof Twente

Applying Templates & Hooks –1Applying Templates & Hooks –1

Through subclassing:Through subclassing: introduce a subclass C2 that (re-)defines method mh1

other hot spots (e.g. mh2) can be redefined as well

adaptation without modifying the class

C1::mtC1::mh2

mt mh1mh2

C1

C2C2::mh1

Universityof Twente

Applying Templates & Hooks –2Applying Templates & Hooks –2

By invocation on another classBy invocation on another class classes interact through a fixed protocol ('contract')

template method calls hook methods on another object

different objects are possible through polymorphism

this also allows for dynamic adaptation

mt mh1mh2

C1 C3

C4

ref

...ref mh1....ref mh2.

Universityof TwenteNarrow Inheritance-Interface PrincipleNarrow Inheritance-Interface Principle

We want a framework to be as flexible as possible:

But the 'narrow inheritance-interface principle' (NIIP) says:

make the adaptation interface as simple as possible

Universityof TwenteNarrow Inheritance Interface Principle -2Narrow Inheritance Interface Principle -2

NIIP attempts to:

avoid problems of white-box reuse

reduce effort in instantiating and adapting framework

When invoking hook methods on another object:

'Narrow Calling Interface Principle' applies;

minimize coupling by keeping protocols simple

but because this is black box reuse (of the template class),

this is less severe

Universityof Twente

Composition Meta Patterns: OverviewComposition Meta Patterns: Overview

T Hhook

1:1 Connection Pattern

T Hhooks

1:N Connection Pattern

T

H

hook

1:1 Recursive Connection Pattern

T

H

hooks

1:N Recursive Connection Pattern

THhook

1:1 Recursive Unification Pattern

THhook

1:N Recursive Unification Pattern

TH

Unification Pattern

Universityof Twente

Exercise -1Exercise -1Exercise -1Exercise -1

Find the meta-patterns in the Bridge PatternFind the meta-patterns in the Bridge Pattern

RefinedAbstr

operation...

Abstraction

ConcrImpl1

operation Impl...

Implementor

ConcrImpl2

operationImpl...

...

RefinedAbstr

...

implimpl operationImpl....

bridge

operationImpl...

Universityof Twente

Exercise-2Exercise-2Exercise-2Exercise-2

Find the meta-patterns in the Composite Find the meta-patterns in the Composite

Pattern:Pattern:Component{abstract}operationaddComponent:removeComponent:getComponent:

CompositeoperationaddComponent:removeComponent:getComponent:

components

components do: [c | c operation. ]

Client

Leafoperation

Universityof Twente

ConclusionsConclusions

a framework should...

include a layer/part of domain knowledge that always applies. this part is fixed and requires no hooks!

define hook methods and hook components for extending this

layer with application-specific behavior the hot spots...

add domain knowledge by enforcing constraints on the

(substituted) hooksby explicit checks & subtyping

through interaction protocols

only a few (OO) techniques for Template-Hook composition