Transcript thesis-defence.pps

Evaluating Software Design Patterns
— the ”Gang of Four” patterns implemented in Java 6
A Master’s Thesis By
Gunni Rode
Department of Computer Science
Faculty of Science
University of Copenhagen
Denmark
Agenda
Page
• Welcome
• Thesis Goals
• Contributions
01
05
06
• Object—Oriented (OO) Development
• Software Design Patterns
08
09
•
•
•
•
•
Evaluation Approach
Implementation
Evaluation
High—Lights
Evaluation Conclusions
15
16
17
23
26
•
•
•
•
Perspectives
Summary
Final Remarks
Questions?
29
31
32
33
Page 2
Gunni Rode — http://www.rode.dk/thesis
Agenda - Intro & Theoretical Part
Page
 Welcome
• Thesis Goals
• Contributions
01
05
06
• Object—Oriented (OO) Development
• Software Design Patterns
08
09
•
•
•
•
•
Evaluation Approach
Implementation
Evaluation
High—Lights
Evaluation Conclusions
15
16
17
23
26
•
•
•
•
Perspectives
Summary
Final Remarks
Questions?
29
31
32
33
Page 3
Gunni Rode — http://www.rode.dk/thesis
Life has been so much easier
since Science invented Magic.
–– Marge Simpson
Goals & Contributions
Page 4
Gunni Rode — http://www.rode.dk/thesis
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 
•
•
•
Page 5
Detailed, individual evaluation per pattern
Comparative evaluation by juxtaposing detailed evaluations
Evaluation approach
Gunni Rode — http://www.rode.dk/thesis
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
Page 6
Gunni Rode — http://www.rode.dk/thesis
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
Theory
Page 7
Gunni Rode — http://www.rode.dk/thesis
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
―
But
Andthis
design
is not
patterns
easy… make it easier!
Testing
Analysis
(Programming language (Java 6))
(Requirements and conceptual model)
Implementation
Idioms
Architectural patterns
Analysis patterns
(“Gang of Four” patterns) Design patterns
•
OO and Design Patterns
•
Page 8
Design
(Computational model (software objects))
Design patterns offer solutions in form of descriptions of interacting objects
Gunni Rode — http://www.rode.dk/thesis
Software Design Patterns
•
Design pattern notion is two—fold: abstraction and description
•
•
•
•
Abstraction: represents a design problem and solution to it
•
•
•
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
•
•
•
•
Page 9
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
•
•
•
•
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
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???
Gunni Rode — http://www.rode.dk/thesis
Software Design Patterns — Iterator Example
•
Example: inquiries about members in “The Simpsons” family
•
•
•
•
•
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”
•
•
•
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
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
1.
2.
3.
4.
Page 10
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), then go to step 2
No: we are done (e.g. all names printed)!
Gunni Rode — http://www.rode.dk/thesis
// unordered collection
Collection<Person> unordered = new HashSet<Person>();
8
01
02
03
04
05
06
07
08
09
10
11
12
13
7
6
5
4
3
2
// ordered collection
Collection<Person> ordered = new TreeSet<Person>(..);
// collection of persons to traverse
Collection<Person> collection = ..
// get iterator ("view")
Iterator<Person> i = collection.iterator();
// loop while more persons
while (i.hasNext()) {
// get next person...
Person person = i.next();
// and print the name!
System.out.println(person.getName());
}
// done!
..
Iterator Design Pattern
1
8
7
6
5
4
3
2
1
Iterator usage makes code robust, recognisable, and easier to maintain!
Page 11
Gunni Rode — http://www.rode.dk/thesis
Theory Summary
•
OO Programming Paradigm: abstraction and encapsulation
•
•
•
•
Design pattern: an abstraction and a description
•
•
•
•
•
•
Abstraction of real—world knowledge
Encapsulated within software objects with state and behaviour
Software objects communicate and interact to deliver functionality
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
•
•
Page 12
Use principles and knowledge, but adapt to the context and language at hand
Produce and maintain programs more efficiently!
Gunni Rode — http://www.rode.dk/thesis
Agenda - Practical Part
Page
 Welcome
 Thesis Goals
 Contributions
01
05
06
 Object—Oriented (OO) Development
 Software Design Patterns
08
09
•
•
•
•
•
Evaluation Approach
Implementation
Evaluation
High—Lights
Evaluation Conclusions
15
16
17
23
26
•
•
•
•
Perspectives
Summary
Final Remarks
Questions?
29
31
32
33
Page 13
Gunni Rode — http://www.rode.dk/thesis
Whenever anyone says, ”theoretically”,
they really mean, ”not really”.
–– Dave Parnas
Evaluation Approach & Implementation
Page 14
Gunni Rode — http://www.rode.dk/thesis
Evaluation Approach
•
Premise: investigate if all pattern functionality described in the
“Implementation” and “Sample Code” elements can be implemented
in a given language
•
•
•
•
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)
•
•
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
Form: detailed → rigid, comparative → loose (subjective)
Evaluation approach applied: Java 6 & realistic features
•
•
•
Page 15
Core language features: types, inheritance, generics, closures, enumerations, etc.
Reflection: class literals, dynamic proxies, annotations, etc.
Special language mechanisms: synchronisation, serialization, cloning, etc.
Gunni Rode — http://www.rode.dk/thesis
Implementation
•
Idea and context: ”simulate” a large and complex application
•
•
•
Meta classes: core model classes and reusable components
•
•
•
All patterns relate to a common set of model and Meta classes
More realistic than isolated or non—overlapping implementations → non—trivial!
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:
•
•
•
Page 16
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)
Gunni Rode — http://www.rode.dk/thesis
High thoughts must have a high language.
–– Aristophanes
Evaluation
Page 17
Gunni Rode — http://www.rode.dk/thesis
Detailed Evaluation
•
Describes implementations: per pattern
•
•
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!
•
•
Primary work: implement ”Implementation” and ”Sample Code” functionality
Descriptions in thesis “short” → see source code and documentation for additional info
Results: Java 6 is very good to express functionality overall
•
•
•
Page 18
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
Gunni Rode — http://www.rode.dk/thesis
Detailed Evaluation – Iterator Example
– JavaDoc
Source Code
Participants
Introduction
Structure
Implementation
Iterator
aillustrates
Behavioural
pattern
with
Objectfor
scope.
The
dk.rode.thesis.iterator
package
contains
table
describes
Iterator
participants
in
theas
words
ofpattern.
Gamma
et al.controls
[Gamma95,
p.259]
and
lists
The
figure
the
Iterator
implementation
an UML
Class diagram,
where the pattern
participants
Java
hasisbuilt—in
APIthe
and
language
support
the
Iterator
Who
iteration?
––
Thethe
corresponding
implementations
developed
in theare
evaluation.
the implementation.
can
also be identified.
The pattern
participants
described in the next section.
SequenceIterator<E> class represents an external iterator, while the ProcessableSequence<E>
Iterator
UMLdefines
Class diagram
represents an internal iterator.
Who
theparticipants
traversal algorithm? –– The
Iterator
Intent
composite.CompositeStrategy
utilises package private access to ensure encapsulation and
Participant
Description
Implementationexposing its underlying
”Provide a way
to access
the elements
antraversal
aggregate
object sequentially
information
hiding
is not violated
whenof
the
algorithm
is external. without
How robust is the iterator?
java.util.Iterator<E> (external),
representation
[Gamma95,
p.257].”
Iterator

Defines
an
interface
for
accessing
and
–– Design choice. Standard iterators in Java are fail—fast, and failProcessableSequence<E>,
immediately in case of concurrent
traversing elements.
ValueProcessor<E>
(internal) in C++ ––
modification. Additional Iterator operations –– Design choice. Using
polymorphic iterators
java.lang.Iterable<T> defines a factory method to return a java.util.Iterator<E> instance
SequenceIterator<E> (external),
ConcreteIterator
 Implements the Iterator interface.
and the usage is illustrated in the IterableSequence<E> class. LoggingValueProcessor<E>
Iterators may have privileged
(internal)access

Keeps
track
of
the
current
position
in
the
–– Illustrated in the meta.reflect.CallerClass.CallerIterator<C> inner class. Iterators for
traversal of the aggregate.
composites –– The composite.CompositeStrategy determines how the composite structure should
java.lang.Iterable<T> (external)
Aggregate
 Defines an interface for creating an
be traversed. Null iterators –– Trivial, though note that making a null iterator for the
Iterator object.
meta.model.Sequence<E> type is not possible, because sequence semantics require that a sequence
IterableSequence<E> (external)
ConcreteAggregate  Implements the Iterator creation
always have at least a single
value.
interface (Aggregate) to return an
instance of the proper ConcreteIterator.
Bold faced sentences: sub—paragraphs by Gamma et al. addressing specific functionality
Page 19
Gunni Rode — http://www.rode.dk/thesis
Comparative Evaluation
•
Describes collective traits: for all pattern implementations
•
•
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!
•
•
Primary work: identify common/alternative functionality for patterns and features
You might want to brush up on your Java skills before continuing… 
Results: Java’s mixture of static and dynamic features well suited
•
•
•
•
•
Page 20
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
Gunni Rode — http://www.rode.dk/thesis
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
← Analysis…
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() {..}
← Source code example…
};
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:
← More analysis…
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
← Even more analysis…
implementations, but are also limited in conjunction with generic types. Most significantly, enumerations
illustrated that Java has built—in support for Singleton pattern.
7.1.1.5. Exception Handling
The evaluation shows that exceptions and try—catch—finally blocks in Java 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
← Even, even more analysis…
blah—blah…
several different pattern implementations for different purposes as summarised below.
Page 21
Gunni Rode — http://www.rode.dk/thesis
Meta classes
X
Visitor
X
Template Method
X
Strategy
X
State
X
Singleton
X
Proxy
X
Prototype
X
Observer
X
Memento
Decorator
X
Iterator
Composite
X
Interpreter
Command
X
Flyweight
Chain of Responsibility
X
Factory Method
Builder
X
Facade
Bridge
Adapter
Feature
Abstract Factory
Pattern
Mediator (not implemented)
Use of Java 6 features in the “Gang of Four” pattern implementations
X
X
X
X
X
X
X
X
X
X
Legends:
Core Language Features
Inheritance
X
Abstract classes
X
X
X
X
X
Interfaces
X
X
X
X
X
X
X
X
Generics
X
D
D
D
X
D
D
D
Generics (bounded)
X
D
D
D
X
X
Anonymous classes
X
X
X
X
X
X
E
X
X
X
D
D
X
D
X
X
X
E
D
X
D
X
X
Enumerations
X
X
Exception handling
X
X
D
E
Covariant return
X
X
X
X
X
X
D
X
X
Varargs
X
M
Generic methods
X
X
X
X
X
E
D
X
M
X
X
X
X
M
X
X
D
Packages
Nested classes
X
X
X
X
D
X
X
X
X
X
X
M
X
X
X
X
M
X
X
E
X
X
X
X
P
X
P
X
X
X
X
X
X
X
X
X
X
X
X
X
Reflection
Class literals
X
X
X
X
X
X
X
X
X
X
E
D
X
X
X
Type literals
X
X
D
D
Constructors
X
X
X
X
X
X
X
X
Methods
X
Dynamic proxies
Annotations
M
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Special Language Mechanisms
Synchronisation
X
Serialization
X
E
X
M
X
X
X
X
D
Cloning
X
Class loader
X
Weak references
Meta classes
Page 22
E
X
X
X
Core
static
features:
(Static
&) dynamic
Additional
static
features:
Make solutions possible
Make
solutions
very
flexible!
robust
and
Promote
OO principles
possibly reusable
Clarify intent
X
D
X
X
E
X
X
X
Dark—blue squares: high—lights
X
X
X
Other: used, but not directly by a
local pattern participant
X
X
X
X
X: used directly in a pattern
participant
X
X
X
X
Gunni Rode — http://www.rode.dk/thesis
X
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
High—Lights
Page 23
Gunni Rode — http://www.rode.dk/thesis
High—Lights
•
Abstract Factory/Factory Method: generic factories/methods capable
of creating parameterised types in a type—safe manner
•
•
Memento: runtime access control of interface methods (guarded types)
•
•
Features: runtime retained annotations, methods
Proxy/State: built—in support and dynamic inheritance
•
•
Features: exception handling (stack trace), class literals
Observer: flexible, reusable components
•
•
Features: class and type literals (reflection), generics, inheritance, anonymous classes
Features: dynamic proxies, methods, constructors
Singleton: Singleton—as—Single—Constant idiom, inheritance
•
Page 24
Features: enumerations, inheritance, exception handling (stack trace), class literals,
runtime retained annotations
Gunni Rode — http://www.rode.dk/thesis
Abstract Factory & Factory Method
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);
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
Page 25
Gunni Rode — http://www.rode.dk/thesis
Program testing can be used to show the presence of bugs,
but never to show their absence!
–– Edsger W. Dijkstra
Evaluation Conclusions
Page 26
Gunni Rode — http://www.rode.dk/thesis
Evaluation Conclusions
•
Implementation compliance: all functionality addressed as required
•
•
•
•
•
•
Language Features: Java 6 (and 5) very good to express functionality
•
•
•
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
Static & dynamic features combo: intent, robustness, reusability, and flexibility
High—lights: flexible, alternative, reusable ideas/components
Evaluation approach: requires much work
•
•
•
•
Page 27
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?
Gunni Rode — http://www.rode.dk/thesis
Agenda - Postscript
Page
 Welcome
 Thesis Goals
 Contributions
01
05
06
 Object—Oriented (OO) Development
 Software Design Patterns
08
09





Evaluation Approach
Implementation
Evaluation
High—Lights
Evaluation Conclusions
15
16
17
23
26
•
•
•
•
Perspectives
Summary
Final Remarks
Questions?
29
31
32
33
Page 28
Gunni Rode — http://www.rode.dk/thesis
A question that sometimes drive me hazy:
am I or the others crazy?
–– Albert Einstein
Perspectives
Page 29
Gunni Rode — http://www.rode.dk/thesis
Perspectives
•
“Non—trivial knowledge—base”: experience, solutions, inspiration
•
•
•
Componentization: overall quite possible results considering
•
•
•
•
Example: Singleton—as—Single—Constant idiom, generic Factory<T> usage, etc
Tooling support: annotations and Annotation Processing Tool (APT)
•
•
•
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
•
•
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
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
•
•
Page 30
Outside thesis scope, but: Creational patterns obsolete? Different focus?
Used by many new frameworks → e.g. Google Guice changes factory usage
Gunni Rode — http://www.rode.dk/thesis
When the only tool you have is a hammer,
everything looks like a nail.
–– Abraham Maslow
Summary
Page 31
Gunni Rode — http://www.rode.dk/thesis
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
Page 32
Gunni Rode — http://www.rode.dk/thesis
Agenda - The End
Page
 Welcome
 Thesis Goals
 Contributions
01
05
06
 Object—Oriented (OO) Development
 Software Design Patterns
08
09





Evaluation Approach
Implementation
Evaluation
High—Lights
Evaluation Conclusions
15
16
17
23
26



•
Perspectives
Summary
Final Remarks
Questions?
29
31
32
33
Page 33
Gunni Rode — http://www.rode.dk/thesis
Page 34
Gunni Rode — http://www.rode.dk/thesis
“Extras”
Page 35
Gunni Rode — http://www.rode.dk/thesis
Design Patterns
Page 36
Gunni Rode — http://www.rode.dk/thesis
Design Patterns
•
Architecture: Christopher Alexander
•
•
Purpose: build “living” and coherent environments (“neighbourhoods”)
•
•
•
Example: build a house using patterns as solutions to problems
Computer Science: made popular by the ”Gang of Four” patterns
•
•
•
•
Wants to improve design methods and practices
Emphasis on human interaction in the design and end process
“Recorded solution to known design problem”
•
•
Sounds easy, but theory is actually quite complex and philosophical
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”)
•
•
Page 37
No need to reinvent the wheel
Familiarity, Reusability, Maintainability, etc
Gunni Rode — http://www.rode.dk/thesis
Feature Observations
Page 38
Gunni Rode — http://www.rode.dk/thesis
Feature Observations: C++ → Java 6
•
Static vs. Runtime Protection
•
•
Multiple Inheritance vs. Interfaces and Composition
•
•
•
•
All canonical C++ template functionality → generics using upper bounds
Matching types in C++ → upper bounds
Type safety, but more work
Templates vs. Annotations
•
•
•
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
•
•
•
•
Two levels of static protection, e.g. public (narrow) and private (wide) → multiple
interface implementation and caller identification at runtime
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
Page 39
Gunni Rode — http://www.rode.dk/thesis
Implementation Level
Page 40
Gunni Rode — http://www.rode.dk/thesis
Implementation level of the “Gang of Four” patterns in Java 6
Name
Level
Type
Description
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.
Adapter
Invisible
Problem specific,
Language support
Anonymous inner classes (closures), dynamic proxies.
Bridge
Informal
Problem specific
Composite
Informal
Possible component
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.
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
Java for—each loop, java.util.Iterator<E> and
java.lang.Iterable<T> with standard implementations.
Mediator
Informal
Problem specific
Memento
Informal
Problem specific
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.
Creational Patterns
Structural Patterns
instanceof operator can help differentiate between Composites
and Leafs.
Behavioural Patterns
Page 41
java.io.Serializable targets different problem.
Gunni Rode — http://www.rode.dk/thesis
Model
Page 42
Gunni Rode — http://www.rode.dk/thesis
Page 43
Gunni Rode — http://www.rode.dk/thesis