Evaluating Software Design Patterns — the ”Gang of Four” patterns implemented in Java 6

Evaluating Software Design Patterns— the ”Gang of Four” patterns implemented in Java 6

Department of Computer Science Faculty of ScienceUniversity of CopenhagenDenmark

A Master’s Thesis By

Gunni Rode

Gunni Rode — http://www.rode.dk/thesis

Agenda Page

• Welcome 01• Thesis Goals 05• Contributions 06

• Object—Oriented (OO) Development 08• Software Design Patterns 09

• Evaluation Approach 15• Implementation 16• Evaluation 17

• High—Lights 23• Evaluation Conclusions 26

• Perspectives 29• Summary 31• Final Remarks 32• Questions? 33


Agenda - Intro & Theoretical Part Page

Welcome 01• Thesis Goals 05• Contributions 06

• Object—Oriented (OO) Development 08• Software Design Patterns 09





Goals & Contributions

Life has been so much easiersince Science invented Magic.

–– Marge Simpson


Thesis Goals

I. Theory and Background • Patterns, especially the “Gang of Four” design patterns • Object—Oriented (OO) Development• Analysis of selected articles describing related work

II. Evaluation Approach• Define a simple and reasonably structured approach• Verifiable• Choice of language act as the catalyst for the evaluation

III. Implementation• Implement the “Gang of Four” design patterns using Java 6

IV. Evaluation• Detailed, individual evaluation per pattern• Comparative evaluation by juxtaposing detailed evaluations• Evaluation approach


Contributions

Practical evaluation approach: address all functionality in the “Implementation” and “Sample Code” elements• Subjective, not a methodology• Practical, thorough, verifiable, and comparable (language catalysts)• No definitive conclusions

Evaluation approach applied: practically all examined pattern functionality can be implemented or simulated in Java 6• Java’s mixture of static and dynamic features (reflection) very well suited

“Non—trivial knowledge—base”: provides experience, solutions, and inspiration• Implementation catalogue for Java 6• High—lights: novel and/or alternative implementations, e.g. Abstract Factory• Will be made public

General design pattern and OO theory described with focus on practical application of “Gang of Four” patterns and Java 6


Theory

A pattern foreshadows the product:it is the rule for making the thing, but it is also,

in many respects, the thing itself.–– Jim Coplien


• OO and Design Patterns• Design patterns offer solutions in form of descriptions of interacting objects

Design

ImplementationImplementation

Design

Object—Oriented (OO) Development

• OO Programming Paradigm: abstraction and encapsulation• Abstraction of real—world knowledge• Encapsulated within software objects with state and behaviour• “Think Lego”: different blocks (objects) fit together to form a greater whole

(object(s))

• Determining/designing individual objects is paramount―

Design patterns

Architectural patternsIdioms

Analysis patterns

AnalysisAnalysis

TestingTesting

(Requirements and conceptual model)

(Computational model (software objects))

(Programming language (Java 6))

(“Gang of Four” patterns)

And design patterns make it easier!But this is not easy…


Software Design Patterns

• Design pattern notion is two—fold: abstraction and description• An abstraction of practical experience and basic knowledge• Recorded in literary form for reuse (pattern description)• No need to reinvent the wheel → produce and maintain programs more

efficiently

• Abstraction: represents a design problem and solution to it• Balanced forces (e.g. trade—offs such as speed vs. flexibility)• Qualities (e.g. abstraction, composibility, etc) → reminiscent of similar OO concepts

• Literary form: non—mathematical, natural language, figures, and code• Describes both problem and solution in consistent format(s), e.g. “GoF Format”• Various elements, e.g. “Name”, “Intent”, “Implementation”, “Sample Code” etc• Named, part of vocabulary

• Design pattern format requires interpretation• Need for human interaction → practical tool in the design process• Generally not out—of—the—box reusable software components • Separates the principles from the implementation → thinking IS required• Adaptation to different applicable contexts and languages → but how well???


Software Design Patterns — Iterator Example

• Example: inquiries about members in “The Simpsons” family• Family members represented as “Person” objects (“Homer”, “Marge”, etc)• Determine family relations: ordered tree structure• Determine existence: unordered set with no duplicates• Task at hand: print all names → either representation will suffice

• Problem: exposing specific representation fixates design/code• Hard to maintain, non—localised, alternative representations?

• Iterator abstraction: “Provide a way to access the persons in the family without exposing the underlying representation”• Indirection between representation and access to persons• Changing the representation does not affect program code where Iterator is

used

• Iterator solution: provide uniform access to the “next” person1. Acquire Iterator object that will deliver persons from the underlying

representation2. Has the Iterator object more persons?3. Yes: fetch and use the next person (e.g. print name), then go to step 2 4. No: we are done (e.g. all names printed)!


01 // collection of persons to traverse

02 Collection<Person> collection =

03 // get iterator ("view")

04 Iterator<Person> i = collection.iterator();

05 // loop while more persons

06 while (i.hasNext()) {

07 // get next person...

08 Person person = i.next();

09 // and print the name!

10 System.out.println(person.getName());

11 }12 // done!

13 ..

Iterator Design Pattern

// ordered collection

Collection<Person> ordered = new TreeSet<Person>(..);

..

// unordered collection

Collection<Person> unordered = new HashSet<Person>();

8

7

6

5

4

3

2

1

8

7

6

5

4

3

2

1

ordered

unordered

Iterator usage makes code robust, recognisable, and easier to maintain!


Theory Summary

• OO Programming Paradigm: abstraction and encapsulation• Abstraction of real—world knowledge• Encapsulated within software objects with state and behaviour• Software objects communicate and interact to deliver functionality

• Design pattern: an abstraction and a description• Practical “tool” addressing known design problems and proven

solutions• Requires human interaction to be applied• Separates the principles from the implementation • Solution described in terms of objects• Augments OO systems → different contexts

• Bottom line: No need to reinvent the wheel, but ok to make it better• Use principles and knowledge, but adapt to the context and language at hand• Produce and maintain programs more efficiently!


Agenda - Practical Part Page

Welcome 01 Thesis Goals 05 Contributions 06

Object—Oriented (OO) Development 08 Software Design Patterns 09





Evaluation Approach & Implementation

Whenever anyone says, ”theoretically”,they really mean, ”not really”.

–– Dave Parnas


Evaluation Approach

• Premise: investigate if all pattern functionality described in the “Implementation” and “Sample Code” elements can be implemented in a given language• Primary elements focusing on practical application, e.g. implementation• Elements contain much information besides canonical examples• Focus on usage of language features, not how they internally are

implemented

• Evaluation Focus: practical and experimental• Subjective results → documented → verifiable• No definitive conclusions → illustrates how features can be used to

implement and augment pattern functionality in the given language

• Evaluations required: detailed (per pattern) and comparative (all)• Form: detailed → rigid, comparative → loose (subjective)

• Evaluation approach applied: Java 6 & realistic features• Core language features: types, inheritance, generics, closures,

enumerations, etc.• Reflection: class literals, dynamic proxies, annotations, etc.• Special language mechanisms: synchronisation, serialization, cloning,

etc.


Implementation

• Idea and context: ”simulate” a large and complex application• All patterns relate to a common set of model and Meta classes• More realistic than isolated or non—overlapping implementations → non—trivial!

• Meta classes: core model classes and reusable components• Model and examples revolve around sequences → e.g. a sequence generating primes• Patterns also applied as part of “normal design” where warranted

• Pattern implementations: in separate packages• Package expresses result of detailed evaluation → runnable and testable• Several different solutions matching evaluating approach• Solutions make frequent use of Meta classes• Solutions use other patterns in their own design, e.g. Abstract Factory using

Prototype

• Gamma et al. themes/concepts and Bloch’s “Java Best Practices”

• Software:• Java 6 (300 Java source files developed)• Eclipse 3.3 (and NetBeans 5.5.1 – different compilers)• Documentation: JavaDoc + UML + annotations (intent & possible tool support)


Evaluation

High thoughts must have a high language.–– Aristophanes


Detailed Evaluation

• Describes implementations: per pattern• Primary work: implement ”Implementation” and ”Sample Code” functionality

• Results reported in fixed structure using ”Gang of Four” elements• Intent: pattern purpose• Structure: detailed UML Class diagram, including pattern participants• Participants: mapping between pattern and implementation entities• Implementation: references to source code illustrating how functionality

from “Implementation” and “Sample Code” is addressed

• Source code and JavaDoc browsing expected by the reader!• Descriptions in thesis “short” → see source code and documentation for additional

info

• Results: Java 6 is very good to express functionality overall• Adheres to ”Gang of Four” themes/concepts and Bloch’s ”Java Best Practices”• Adapter with Class scope fails: targeted at multiple inheritance (e.g. C++ idiom)• Some problems with dynamic proxies used to simulate other (dynamic) features


Iterator UML Class diagram

Iterator participants

Participant

Description

Implementation

Iterator Defines an interface for accessing and traversing elements.

java.util.Iterator<E> (external), ProcessableSequence<E>, ValueProcessor<E> (internal)

ConcreteIterator Implements the Iterator interface.

Keeps track of the current position in the traversal of the aggregate.

SequenceIterator<E> (external), LoggingValueProcessor<E> (internal)

Aggregate Defines an interface for creating an Iterator object.

java.lang.Iterable<T> (external)

ConcreteAggregate Implements the Iterator creation interface (Aggregate) to return an instance of the proper ConcreteIterator.

IterableSequence<E> (external)

IntroductionIterator is a Behavioural pattern with Object scope. The dk.rode.thesis.iterator package contains the implementation.

Intent”Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation [Gamma95, p.257].”

ImplementationJava has built—in API and language support for the Iterator pattern. Who controls the

iteration? –– The SequenceIterator<E> class represents an external iterator, while the

ProcessableSequence<E> represents an internal iterator. Who defines the traversal

algorithm? –– The composite.CompositeStrategy utilises package private access to ensure

encapsulation and information hiding is not violated when the traversal algorithm is external.

How robust is the iterator? –– Design choice. Standard iterators in Java are fail—fast, and

fail immediately in case of concurrent modification. Additional Iterator operations ––

Design choice. Using polymorphic iterators in C++ –– java.lang.Iterable<T> defines a

factory method to return a java.util.Iterator<E> instance and the usage is illustrated in

the IterableSequence<E> class. Iterators may have privileged access –– Illustrated in

the meta.reflect.CallerClass.CallerIterator<C> inner class. Iterators for

composites –– The composite.CompositeStrategy determines how the composite

structure should be traversed. Null iterators –– Trivial, though note that making a null

iterator for the meta.model.Sequence<E> type is not possible, because sequence semantics

require that a sequence always have at least a single value.

Bold faced sentences: sub—paragraphs by Gamma et al. addressing specific functionality

StructureThe figure illustrates the Iterator implementation as an UML Class diagram, where the pattern participants can also be identified. The pattern participants are described in the next section.

ParticipantsThe table describes the Iterator participants in the words of Gamma et al. [Gamma95, p.259] and lists the corresponding implementations developed in the evaluation.

Detailed Evaluation – Iterator Example

Implementation – Source CodeImplementation – JavaDoc


Comparative Evaluation

• Describes collective traits: for all pattern implementations• Primary work: identify common/alternative functionality for patterns and features

• Results reported as a technical analysis/discussion• Overview: schematic presentation of VITAL (pattern feature) usage• Feature usage: analysis in natural language and real code per feature• Language support: casual classification on the level of pattern support in Java 6• Pattern usage: identification of pattern relationships (language and/or design?)

• Source code and JavaDoc browsing still expected by the reader!• You might want to brush up on your Java skills before continuing…

• Results: Java’s mixture of static and dynamic features well suited• Disclose which features caused the (fine) results of the detailed evaluation• Static features: augment robustness, pattern intent, and reusability • Dynamic features: augment flexibility and reusability → e.g. Factory Method• High—Lights: new and/or alternative approaches• Language support: Adapter, Iterator, Proxy, and Singleton + various components


blah—blah…

analysis… ← Even, even more

Comparative Evaluation – Enumeration analysis example

object identity, etc. The singleton.DanishAlphabetSequence is a Singleton implementation using

enumerations as illustrated in listing 7.9 below. The singleton instance is created and/ or acquired using the

single enumeration constant DanishAlphabetSequence.Instance. The instance is not loaded until the

constant is first referenced. The actual sequence functionality is represented by a final private

meta.model.Sequence<java.lang.String> aggregate member that stores the letters in the Danish

alphabet. However, Singleton implementations using enumerations cannot be sub—classed, nor be generic.

Listing 7.9 — Singleton—as—Single—Constant idiom used to implement Singleton

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

public enum DanishAlphabetSequence implements Sequence<String> { // extends java.lang.Enum<DanishAlphabetSequence> Instance; // single constant private final Sequence<String> sequence = new ArraySequence<String>( // aggregatee (adapter) "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "æ", "ø", "å") { public Sequence<String> copy() {..} }; private DanishAlphabetSequence() {..} // private enumeration constructor required by Java public String next() { return this.sequence.next(); // forward call to aggregatee } .. }

The use of enumerations in the evaluation is for all pattern implementations associated with interface

implementation except for the Interpreter pattern as well as usage in Meta classes. The enumeration

constants are mainly used for implementation expediency, not to define a separate type, save the Singleton

and State patterns. Their usage is not paramount for any pattern implementation. This indicates that normal

classes could have been used instead, but perhaps requiring more work. The reverse is not true:

enumerations cannot be used if inheritance must be used, and each constant has to have the same type. The

Adapter implementation therefore has to use anonymous inner classes in the adapter.AdapterStrategy

class, because each strategy has a different (generic) type. Examples of regular usage of enumerations are

the meta.util.Primitives.Type Meta enumeration and the annotations used to describe the “Gang of

Four” participants, for example the meta.Scope enumeration. These enumerations are used to define both

a type and a fixed set of constants.

Conclusion –– Enumerations proved surprisingly useful in the specialised cases where a few instances of a

given type are required because of their unique behaviour guaranteed by the compiler. Patterns having a

static structure will benefit most from their usage. They were used continually to represent Strategy

implementations, but are also limited in conjunction with generic types. Most significantly, enumerations

illustrated that J ava has built—in support for Singleton pattern.

7.1.1.5. Exception Handling

The evaluation shows that exceptions and try—catch—finally blocks in J ava can be used in the “Gang of

Four” implementations in a number of ways. The features have a very versatile use and are embedded in

several different pattern implementations for different purposes as summarised below.

← Analysis…

← More analysis…

← Even more analysis…

← Source code example…


Additional static features:

Make solutions robust and possibly reusable

Clarify intent

Core static features:

Make solutions possible

Promote OO principles

(Static &) dynamic features:

Make solutions very flexible!

Use of J ava 6 features in the “Gang of Four” pattern implementations

Pattern

Feature A

bst

ract

Fac

tory

Adap

ter

Bri

dge

Builde

r

Chai

n o

f Res

pon

sibi

lity

Com

man

d

Com

posi

te

Deco

rato

r

Faca

de

Fact

ory

Met

hod

Flyw

eigh

t

Inte

rpre

ter

Itera

tor

Med

iato

r (n

ot im

plem

ente

d)

Mem

ento

Obs

erve

r

Pro

toty

pe

Pro

xy

Singl

eton

Stat

e

Stra

tegy

Tem

plat

e M

ethod

Vis

itor

Met

a c

lass

es

Core Language Features

Inheritance

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Abstract classes

X

X

X

X

X

X

X

X

X

X

X

X

Interfaces

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

E

X

X

X

X

Generics

X

D

D

D

X

D

D

D

X

D

D

X

D

X

X

X

E

D

X

D

X

X

Generics (bounded)

X

D

D

D

D

D

X

X

E

X

X

Packages

X

X

X

Nested classes

M

M

X

M

X

X

X

P

X

X

Anonymous classes

X

X

X

X

X

X

P

X

X

Enumerations

X

X

X

X

X

X

X

Exception handling

X

M

X

X

X

M

X

X

X

Generic methods

X

D

E

X

X

D

X

X

X

X

E

X

X

Covariant return

X

X

X

X

X

X

X

X

X

Varargs

X

X

X

X

X

X

X

X

Reflection

Class literals

X

D

X

X

X

X

X

X

X

X

X

X

X

Type literals

X

X

D

D

E

D

X

Constructors

X

X

X

X

X

Methods

X

X

X

X

X

X

Dynamic proxies

M

X

X

X

X

Annotations

X

X

X

X

X

X

X

X

X

X

Special Language Mechanisms

Synchronisation

X

E

X

M

X

X

X

X

X

X

Serialization

X

X

D

D

Cloning

X

X

Class loader

X

X

E

X

Weak references

E

X

X

Meta classes

X

X

X

X

X

X

X

X

Legends:

X: used directly in a pattern participant

Other: used, but not directly by a local pattern participant

Dark—blue squares: high—lights

Use of J ava 6 features in the “Gang of Four” pattern implementations

Pattern

Feature A

bst

ract

Fac

tory

Adap

ter

Bri

dge

Builde

r

Chai

n o

f Res

pon

sibi

lity

Com

man

d

Com

posi

te

Deco

rato

r

Faca

de

Fact

ory

Met

hod

Flyw

eigh

t

Inte

rpre

ter

Itera

tor

Med

iato

r (n

ot im

plem

ente

d)

Mem

ento

Obs

erve

r

Pro

toty

pe

Pro

xy

Singl

eton

Stat

e

Stra

tegy

Tem

plat

e M

ethod

Vis

itor

Met

a c

lass

es

Core Language Features

Inheritance

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Abstract classes

X

X

X

X

X

X

X

X

X

X

X

X

Interfaces

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

E

X

X

X

X

Generics

X

D

D

D

X

D

D

D

X

D

D

X

D

X

X

X

E

D

X

D

X

X

Generics (bounded)

X

D

D

D

D

D

X

X

E

X

X

Packages

X

X

X

Nested classes

M

M

X

M

X

X

X

P

X

X

Anonymous classes

X

X

X

X

X

X

P

X

X

Enumerations

X

X

X

X

X

X

X

Exception handling

X

M

X

X

X

M

X

X

X

Generic methods

X

D

E

X

X

D

X

X

X

X

E

X

X

Covariant return

X

X

X

X

X

X

X

X

X

Varargs

X

X

X

X

X

X

X

X

Reflection

Class literals

X

D

X

X

X

X

X

X

X

X

X

X

X

Type literals

X

X

D

D

E

D

X

Constructors

X

X

X

X

X

Methods

X

X

X

X

X

X

Dynamic proxies

M

X

X

X

X

Annotations

X

X

X

X

X

X

X

X

X

X

Special Language Mechanisms

Synchronisation

X

E

X

M

X

X

X

X

X

X

Serialization

X

X

D

D

Cloning

X

X

Class loader

X

X

E

X

Weak references

E

X

X

Meta classes

X

X

X

X

X

X

X

X

Reasonable choice of features

Patterns widely applicable


High—Lights

A language that does not affect the wayyou think about programming, is not worth knowing.

–– Alan J. Perlis


High—Lights

• Abstract Factory/Factory Method: generic factories/methods capable of creating parameterised types in a type—safe manner• Features: class and type literals (reflection), generics, inheritance,

anonymous classes

• Memento: runtime access control of interface methods (guarded types)• Features: exception handling (stack trace), class literals

• Observer: flexible, reusable components• Features: runtime retained annotations, methods

• Proxy/State: built—in support and dynamic inheritance• Features: dynamic proxies, methods, constructors

• Singleton: Singleton—as—Single—Constant idiom, inheritance• Features: enumerations, inheritance, exception handling (stack trace), class

literals, runtime retained annotations


Abstract Factory & Factory Method

• Problem: Factory Method description suggests using class literals to create objects reflectively [Gamma95, p.112], but class literals cannot describe parameterised types in a type—safe manner in Java 6.

• Solution: introduce type literal component as alternative to class literals → used by abstract Factory<T> class to create the (generic) type T → force static binding of T to compile—time known type through abstract class.

• Features: class and type literals (reflection), generics, abstract classes and inheritance, anonymous classes

• Generic, reusable, but also extendable → only need to specify (generic) type and constructor• Declarative pattern intent → “wysiwyg”, e.g. guess what Factory<SequenceValueRange> does!?• Type—safe, hides verbose reflection code → runtime errors can still occur, e.g. illegal arguments• Static & dynamic interaction: static inheritance and type—safety, but dynamic creation

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

// Factory creating non-generic type (implementation): SequenceValueRange // Declare and create factory to use constructor: SequenceValueRange(int) Factory<SequenceValueRange> fsvr = new Factory<SequenceValueRange>(Integer.class){}; // inheritance -> anonymous class // Factory creating generic type (abstraction): SequenceAbstraction<Integer> // Declare and create factory to use constructor: SequenceAbstraction<Integer>() Factory<SequenceAbstraction<Integer>> fsa = new Factory<SequenceAbstraction<Integer>>(){}; // inheritance -> anonymous class // Bridge pattern: use factory to create implementation to deliver values [0,100] SequenceValueRange svr = fsvr.newInstance(100); // no unsafe type cast! // Bridge pattern: use factory to create abstraction SequenceAbstraction<Integer> sa = fsa.newInstance(); // generic, but no unsafe type cast! // Assemble to create operational sequence to deliver Integer values [0,100] sa.setGenerator(svr);


Evaluation Conclusions

Program testing can be used to show the presence of bugs,but never to show their absence!

–– Edsger W. Dijkstra


Evaluation Conclusions

• Implementation compliance: all functionality addressed as required• Very consequent and meticulous work performed• High quality: ”Gang of Four” concepts and Bloch’s ”Java Best Practices” • All patterns evaluated, all but Mediator implemented → other solutions

possible• Only Adapter with Class scope fails because of pattern abstraction (e.g. C++

idiom)• Some (minor) problems with dynamic proxies

• Language Features: Java 6 (and 5) very good to express functionality• Static & dynamic features combo: intent, robustness, reusability, and

flexibility• High—lights: flexible, alternative, reusable ideas/components

• Evaluation approach: requires much work• Overall idea is good, but format requires more work → not a

methodology

• ”Sample Code” did not provide new info, ”Applicability” and ”Consequences” do

• Distinction between detailed and comparative evaluations fuzzy → ”iterative process”

• Investigation of the “Gang of Four” patterns using a given language, or vice versa?


Agenda - Postscript Page



Evaluation Approach 15 Implementation 16 Evaluation 17

High—Lights 23 Evaluation Conclusions 26



Perspectives

A question that sometimes drive me hazy:am I or the others crazy?

–– Albert Einstein


Perspectives

• “Non—trivial knowledge—base”: experience, solutions, inspiration• Well—suited for a website (“wiki”): fast look—up based on pattern and/or

feature, cross referencing, smaller parts (as opposed to large document), open—source

• Extendable: new patterns, new implementations, new languages

• Componentization: overall quite possible results considering• Creational, and especially Behavioural patterns well suited• High—lights: target componentization directly• Interesting Meta—classes: ditto

• Tooling support: patterns in IDE’s, e.g. Eclipse templates• Example: Singleton—as—Single—Constant idiom, generic Factory<T>

usage, etc

• Tooling support: annotations and Annotation Processing Tool (APT)• Generate code: structural Meta data available at runtime → “pattern

framework”?• Generate documentation: identify usage of different patterns and

participants

• Patterns vs. Dependency Injection and Inversion of Control• Outside thesis scope, but: Creational patterns obsolete? Different focus?• Used by many new frameworks → e.g. Google Guice changes factory usage


Summary

When the only tool you have is a hammer,everything looks like a nail.

–– Abraham Maslow


Final Remarks

Life is what happens to you whileyou’re busy making other plans.

–– John Lennon

In memory of my dad, Henning Rode 21.02.1936 — 27.10.2007


Agenda - The End Page



Evaluation Approach 15 Implementation 16 Evaluation 17

High—Lights 23 Evaluation Conclusions 26

Perspectives 29 Summary 31 Final Remarks 32• Questions? 33


“Extras”


Design Patterns


Design Patterns

• Architecture: Christopher Alexander• Sounds easy, but theory is actually quite complex and philosophical

• Purpose: build “living” and coherent environments (“neighbourhoods”)• Wants to improve design methods and practices• Emphasis on human interaction in the design and end process

• “Recorded solution to known design problem”• Example: build a house using patterns as solutions to problems

• Computer Science: made popular by the ”Gang of Four” patterns• Builds on Alexander’s ideas, but more pragmatic• Similar concepts, such as abstraction, encapsulation, composibility, etc.• System of 23 patterns that are interrelated (alternatives, cooperation)

• Purpose: produce (OO) programs efficiently (“toolbox”)• No need to reinvent the wheel• Familiarity, Reusability, Maintainability, etc


Feature Observations


Feature Observations: C++ → Java 6• Static vs. Runtime Protection

• Two levels of static protection, e.g. public (narrow) and private (wide) → multiple interface implementation and caller identification at runtime

• Multiple Inheritance vs. Interfaces and Composition• Private (functional) inheritance → composition, where public interface can be

guarded• Public multiple inheritance → interfaces with direct implementation or

composition. • Classes inherited in C++ → interfaces fixed at compile—time, final aggregates

• Templates vs. Generics• All canonical C++ template functionality → generics using upper bounds• Matching types in C++ → upper bounds• Type safety, but more work

• Templates vs. Annotations• C++ templates to identify function pointers (signatures) → annotations, without

the need for bounded generics• Flexible, but loss of compile—time safety

• Overloaded Operators vs. Dynamic Proxies• Normal methods cannot express semantics like the C++ -> operator (Proxy)• Use dynamic proxies → requires factory creation


Implementation Level


Implementation level of the “Gang of Four” patterns in J ava 6

Name

Level

Type

Description

Creational Patterns

Abstract Factory Formal Evaluation component, Language support

Reflection, using prototypes and/ or, factorymethod.Factory<T>.

Builder Informal Problem specific, Language support

Could use reflection and/ or meta.reflect.InstantiableTypeLiteral<T>.

Factory Method Formal Evaluation component, Language support

Reflection, using InstantiableTypeLiteral<T>, and/ or Factory<T>.

Prototype Formal API, Language support java.lang.Cloneable with specific language support.

Singleton Invisible Evaluation component, Language support

Singleton registries reusable. Enumerations support creational semantics.

Structural Patterns

Adapter Invisible Problem specific, Language support

Anonymous inner classes (closures), dynamic proxies.

Bridge Informal Problem specific

Composite Informal Possible component instanceof operator can help differentiate between Composites and Leafs.

Decorator Informal Problem specific

Facade Informal Problem specific, Language support

Packages and access modifiers.

Flyweight Informal Problem specific, Language support

Synchronisation to ensure proper creation of flyweights.

Proxy Formal Evaluation component, API, Language support

java.lang.reflect.Proxy with specific language support, and meta.reflect.proxy package.

Behavioural Patterns

Chain of Responsibility

Formal Evaluation component HandlerChain<R>, Handler<R>, and HandlerLink<R> in the chainofresponsibility package (including implementations).

Command Informal Possible component Candidates are command.Command<E> and command.CommandProcessor.

Interpreter Informal Problem specific, Possible component

Candidates are Expression<E> (sub—)types, Context, and Interpreter<T> in the interpreter package.

Iterator Invisible API, Language support J ava for—each loop, java.util.Iterator<E> and java.lang.Iterable<T> with standard implementations.

Mediator Informal Problem specific

Memento Informal Problem specific java.io.Serializable targets different problem.

Observer Formal API, Evaluation component java.util.Observer and java.util.Observable, rarely used. observer.ObserverManager and meta.reflect.@Executor are reusable.

State Informal Problem specific, Language support

Can be implemented using enumerations. Dynamic proxies can alter behaviour at runtime.

Strategy Invisible Problem specific, Language support

Anonymous inner classes (closures).

Template Method Informal Problem specific, Language support

Abstract classes, abstract methods, varargs, and covariant return types.

Visitor Informal Problem specific Only single—dispatch, but can use reflection.

Meta Classes

Formal

Evaluation Components

meta.reflect, meta.reflect.proxy, and most of meta.util packages reusable.


Model

Evaluating Software Design Patterns — the ”Gang of Four” patterns implemented in Java 6

Documents

Transcript of Evaluating Software Design Patterns — the ”Gang of Four” patterns implemented in Java 6