Evaluating Software Design Patterns the Gang of Four

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. “Go. F 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 Hash. Set<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 Tree. Set<Person>(. . ); // collection of persons to traverse Collection<Person> collection =. . // get iterator ("view") Iterator<Person> i = collection. iterator(); // loop while more persons while (i. has. Next()) { // get next person. . . Person person = i. next(); // and print the name! System. out. println(person. get. Name()); } // 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 Net. Beans 5. 5. 1 – different compilers) Documentation: Java. Doc + 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 Java. Doc 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 – Java. Doc 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 [Gamma 95, p. 259] and lists The figure the Iterator implementation an UML Class diagram, where the iteration? pattern participants Java hasisbuilt—in APIthe and language support the Iterator Who –– Thethe corresponding implementations developed in theare evaluation. the implementation. can also be identified. The pattern participants described in the next section. Sequence. Iterator<E> class represents an external iterator, while the Processable. Sequence<E> represents an internal iterator. Who defines the traversal algorithm? –– The Intent composite. Composite. Strategy utilises package private access to ensure encapsulation and ”Provide a way to access the elements antraversal aggregate object sequentially without exposing underlying information hiding is not violated when of the algorithm is external. How robust is theits iterator? representation [Gamma 95, p. 257]. ” –– 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 Iterable. Sequence<E> class. Iterators may have privileged access –– Illustrated in the meta. reflect. Caller. Class. Caller. Iterator <C> inner class. Iterators for composites –– The composite. Composite. Strategy 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 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 Java. Doc 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 ← Analysis… ← Source code example… ← More analysis… ← Even more analysis… ← Even, even more analysis… blah—blah… Page 21 Gunni Rode — http: //www. rode. dk/thesis

Legends: 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: (Static &) dynamic Additional static features: Make solutions possible Make solutions very flexible! robust and Promote OO principles possibly reusable Clarify intent Patterns widely applicable Page 22 Gunni Rode — http: //www. rode. dk/thesis 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 • • Problem: Factory Method description suggests using class literals to create objects reflectively [Gamma 95, 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<Sequence. Value. Range> 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 • • Page 39 Normal methods cannot express semantics like the C++ -> operator (Proxy) Use dynamic proxies → requires factory creation Gunni Rode — http: //www. rode. dk/thesis

Implementation Level Page 40 Gunni Rode — http: //www. rode. dk/thesis

Page 41 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