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

Page 2 Gunni Rode — Agenda Page Welcome0101 Thesis Goals0505 Contributions0606 Object—Oriented (OO) Development0808 Software Design Patterns0909 Evaluation Approach1515 Implementation1616 Evaluation 1717 High—Lights2323 Evaluation Conclusions2626 Perspectives2929 Summary3131 Final Remarks3232 Questions?3333

Page 3 Gunni Rode — Agenda - Intro & Theoretical Part Page Welcome0101 Thesis Goals0505 Contributions0606 Object—Oriented (OO) Development0808 Software Design Patterns0909 Evaluation Approach1515 Implementation1616 Evaluation 1717 High—Lights2323 Evaluation Conclusions2626 Perspectives2929 Summary3131 Final Remarks3232 Questions?3333

Page 4 Gunni Rode — Goals & Contributions Life has been so much easier since Science invented Magic. –– Marge Simpson

Page 5 Gunni Rode — 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

Page 6 Gunni Rode — 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 7 Gunni Rode — 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

Page 8 Gunni Rode — OO and Design Patterns Design patterns offer solutions in form of descriptions of interacting objects Design Implementation 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 patterns Idioms Analysis patterns Analysis Analysis Testing (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…

Page 9 Gunni Rode — 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???

Page 10 Gunni Rode — 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 1.Acquire Iterator object that will deliver persons from the underlying representation 2.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)!

Page 11 Gunni Rode — 01 // collection of persons to traverse 02 Collection collection = 03 // get iterator ("view") 04 Iterator i = collection.iterator(); 05 // loop while more persons 06 while (i.hasNext()) { 07 // get next person 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 ordered = new TreeSet (..);.. // unordered collection Collection unordered = new HashSet (); ordered unordered Iterator usage makes code robust, recognisable, and easier to maintain!

Page 12 Gunni Rode — 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!

Page 13 Gunni Rode — Agenda - Practical Part Page Welcome0101 Thesis Goals0505 Contributions0606 Object—Oriented (OO) Development0808 Software Design Patterns0909 Evaluation Approach1515 Implementation1616 Evaluation 1717 High—Lights2323 Evaluation Conclusions2626 Perspectives2929 Summary3131 Final Remarks3232 Questions?3333

Page 14 Gunni Rode — Evaluation Approach & Implementation Whenever anyone says, ”theoretically”, they really mean, ”not really”. –– Dave Parnas

Page 15 Gunni Rode — 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.

Page 16 Gunni Rode — 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 – different compilers) Documentation: JavaDoc + UML + annotations (intent & possible tool support)

Page 17 Gunni Rode — Evaluation High thoughts must have a high language. –– Aristophanes

Page 18 Gunni Rode — 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

Page 19 Gunni Rode — 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 class represents an external iterator, while the ProcessableSequence 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 defines a factory method to return a java.util.Iterator instance and the usage is illustrated in the IterableSequence class. Iterators may have privileged access –– Illustrated in the meta.reflect.CallerClass.CallerIterator 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 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. 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. Detailed Evaluation – Iterator Example Implementation – Source CodeImplementation – JavaDoc

Page 20 Gunni Rode — 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

Page 21 Gunni Rode — blah—blah… analysis… ← Even, even more Comparative Evaluation – Enumeration analysis example ← Analysis… ← More analysis… ← Even more analysis… ← Source code example…

Page 22 Gunni Rode — 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! Legends: X: used directly in a pattern participant Other: used, but not directly by a local pattern participant Dark—blue squares: high—lights Reasonable choice of features Patterns widely applicable

Page 23 Gunni Rode — High—Lights A language that does not affect the way you think about programming, is not worth knowing. –– Alan J. Perlis

Page 24 Gunni Rode — 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

Page 25 Gunni Rode — 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 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 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 26 Gunni Rode — Evaluation Conclusions Program testing can be used to show the presence of bugs, but never to show their absence! –– Edsger W. Dijkstra

Page 27 Gunni Rode — 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?

Page 28 Gunni Rode — Agenda - Postscript Page Welcome0101 Thesis Goals0505 Contributions0606 Object—Oriented (OO) Development0808 Software Design Patterns0909 Evaluation Approach1515 Implementation1616 Evaluation 1717 High—Lights2323 Evaluation Conclusions2626 Perspectives2929 Summary3131 Final Remarks3232 Questions?3333

Page 29 Gunni Rode — Perspectives A question that sometimes drive me hazy: am I or the others crazy? –– Albert Einstein

Page 30 Gunni Rode — 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 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

Page 31 Gunni Rode — Summary When the only tool you have is a hammer, everything looks like a nail. –– Abraham Maslow

Page 32 Gunni Rode — Final Remarks Life is what happens to you while you’re busy making other plans. –– John Lennon In memory of my dad, Henning Rode —

Page 33 Gunni Rode — Agenda - The End Page Welcome0101 Thesis Goals0505 Contributions0606 Object—Oriented (OO) Development0808 Software Design Patterns0909 Evaluation Approach1515 Implementation1616 Evaluation 1717 High—Lights2323 Evaluation Conclusions2626 Perspectives2929 Summary3131 Final Remarks3232 Questions?3333

Page 34 Gunni Rode —

Page 35 Gunni Rode — “Extras”

Page 36 Gunni Rode — Design Patterns

Page 37 Gunni Rode — 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

Page 38 Gunni Rode — Feature Observations

Page 39 Gunni Rode — 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

Page 40 Gunni Rode — Implementation Level

Page 41 Gunni Rode —

Page 42 Gunni Rode — Model

Page 43 Gunni Rode —