Evaluating software design patterns the gang of four patterns implemented in java 6
Sponsored Links
This presentation is the property of its rightful owner.
1 / 43

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

  • Uploaded on
  • Presentation posted in: General

Evaluating Software Design Patterns — the ”Gang of Four” patterns implemented in Java 6. Department of Computer Science Faculty of Science University of Copenhagen Denmark. A Master’s Thesis By Gunni Rode. Agenda Page. Welcome 01 Thesis Goals 05

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

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

Department of Computer Science

Faculty of Science

University of Copenhagen


A Master’s Thesis By

Gunni Rode

Agenda Page

  • Welcome01

  • Thesis Goals05

  • Contributions06

  • Object—Oriented (OO) Development08

  • Software Design Patterns09

  • Evaluation Approach15

  • Implementation16

  • Evaluation 17

  • High—Lights23

  • Evaluation Conclusions26

  • Perspectives29

  • Summary31

  • Final Remarks32

  • Questions?33

Agenda - Intro & Theoretical Part Page

  • Welcome01

  • Thesis Goals05

  • Contributions06

  • Object—Oriented (OO) Development08

  • Software Design Patterns09

  • Evaluation Approach15

  • Implementation16

  • Evaluation 17

  • High—Lights23

  • Evaluation Conclusions26

  • Perspectives29

  • Summary31

  • Final Remarks32

  • Questions?33

Life has been so much easier

since Science invented Magic.

–– Marge Simpson

Goals & Contributions

Thesis Goals

  • Theory and Background

    • Patterns, especially the “Gang of Four” design patterns

    • Object—Oriented (OO) Development

    • Analysis of selected articles describing related work

  • Evaluation Approach

    • Define a simple and reasonably structured approach

    • Verifiable

    • Choice of language act as the catalyst for the evaluation

  • Implementation

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

  • Evaluation

    • Detailed, individual evaluation per pattern

    • Comparative evaluation by juxtaposing detailed evaluations

    • Evaluation approach


  • 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

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


Object—Oriented (OO) Development

  • OO Programming Paradigm: abstraction and encapsulation

    • Abstraction of real—world knowledge

    • Encapsulatedwithin softwareobjects with state and behaviour

    • “Think Lego”: different blocks (objects) fit together to form a greater whole (object(s))

  • Determining/designing individual objects is paramount

But this is not easy…

And design patterns make it easier!





(Requirements and conceptual model)



(Programming language (Java 6))


Architectural patterns

Analysis patterns

Design patterns

(“Gang of Four” patterns)



(Computational model (software objects))

  • OO and Design Patterns

    • Design patterns offer solutions in form of descriptions of interacting objects

Software Design Patterns

  • Design pattern notion is two—fold: abstraction and description

    • An abstraction of practical experience and basic knowledge

    • Recorded in literary formfor 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 notout—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” person

    • Acquire Iterator object that will deliver persons from the underlying representation

    • Has the Iterator object more persons?

    • Yes: fetch and use the next person (e.g. print name), thengo to step 2

    • No: we are done (e.g. all names printed)!

  • // ordered collection

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

  • ordered

  • // unordered collection

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

  • unordered

  • 8

  • 8

  • 01 // collection of persons to traverse

  • 02Collection<Person> collection =

  • 03 // get iterator ("view")

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

  • 05 // loop while more persons

  • 06while (i.hasNext()) {

  • 07// get next person...

  • 08Person person = i.next();

  • 09// and print the name!

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

  • 11}

  • 12 // done!

  • 13 ..

  • Iterator Design Pattern


  • 7

  • 7

  • 6

  • 6

  • 5

  • 5

  • 4

  • 4

  • 3

  • 3

  • 2

  • 2

  • 1

  • 1

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

Theory Summary

  • OO Programming Paradigm: abstraction and encapsulation

    • Abstraction of real—world knowledge

    • Encapsulatedwithin softwareobjects 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

  • Welcome01

  • Thesis Goals05

  • Contributions06

  • Object—Oriented (OO) Development08

  • Software Design Patterns09

  • Evaluation Approach15

  • Implementation16

  • Evaluation 17

  • High—Lights23

  • Evaluation Conclusions26

  • Perspectives29

  • Summary31

  • Final Remarks32

  • Questions?33

Whenever anyone says, ”theoretically”,

they really mean, ”not really”.

–– Dave Parnas

Evaluation Approach & Implementation

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.


  • 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 solutionsmatching 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)

High thoughts must have a high language.

–– Aristophanes


Detailed Evaluation

  • Describes implementations: per pattern

    • Primary work: implement ”Implementation” and ”Sample Code” functionality

  • Resultsreported 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

Detailed Evaluation – Iterator Example

  • Implementation – Source Code

  • Implementation – JavaDoc

  • Participants

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

  • Introduction

  • Iterator 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].”

  • Implementation

  • Java 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

  • Structure

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

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

Comparative Evaluation – Enumeration analysis example


←Source code example…

← More analysis…

← Even more analysis…

← Even, even more




X: used directly in a pattern participant

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

Dark—blue squares: high—lights

Core static features:

Make solutions possible

Promote OO principles

(Static &) dynamic features:

Make solutions very flexible!

Additional static features:

Make solutions robust and possibly reusable

Clarify intent

Patterns widely applicable

Reasonable choice of features

A language that does not affect the way

you think about programming, is not worth knowing.

–– Alan J. Perlis



  • 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

Program testing can be used to show the presence of bugs,

but never to show their absence!

–– Edsger W. Dijkstra

Evaluation Conclusions

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

  • Welcome01

  • Thesis Goals05

  • Contributions06

  • Object—Oriented (OO) Development08

  • Software Design Patterns09

  • Evaluation Approach15

  • Implementation16

  • Evaluation 17

  • High—Lights23

  • Evaluation Conclusions26

  • Perspectives29

  • Summary31

  • Final Remarks32

  • Questions?33

A question that sometimes drive me hazy:

am I or the others crazy?

–– Albert Einstein



  • “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

When the only tool you have is a hammer,

everything looks like a nail.

–– Abraham Maslow


Life is what happens to you while

you’re busy making other plans.

–– John Lennon

Final Remarks

  • In memory of my dad, Henning Rode

  • 21.02.1936 — 27.10.2007

Agenda - The End Page

  • Welcome01

  • Thesis Goals05

  • Contributions06

  • Object—Oriented (OO) Development08

  • Software Design Patterns09

  • Evaluation Approach15

  • Implementation16

  • Evaluation 17

  • High—Lights23

  • Evaluation Conclusions26

  • Perspectives29

  • Summary31

  • Final Remarks32

  • Questions?33


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


  • Login