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

1. 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

2. Agenda Page • Welcome 01 • Thesis Goals 05 • Contributions 06 • Object—Oriented (OO) Development 08 • Software Design Patterns 09 • Evaluation Approach 15 • Implementation 16 • Evaluation 17 • High—Lights 23 • Evaluation Conclusions 26 • Perspectives 29 • Summary 31 • Final Remarks 32 • Questions? 33

3. Agenda - Intro & Theoretical Part Page • Welcome01 • Thesis Goals 05 • Contributions 06 • Object—Oriented (OO) Development 08 • Software Design Patterns 09 • Evaluation Approach 15 • Implementation 16 • Evaluation 17 • High—Lights 23 • Evaluation Conclusions 26 • Perspectives 29 • Summary 31 • Final Remarks 32 • Questions? 33

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

5. 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    

6. 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

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

8. 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! Testing Testing Analysis Analysis (Requirements and conceptual model) Implementation Implementation (Programming language (Java 6)) Idioms Architectural patterns Analysis patterns Design patterns (“Gang of Four” patterns) Design Design (Computational model (software objects)) • OO and Design Patterns • Design patterns offer solutions in form of descriptions of interacting objects

9. 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???

10. 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)!

11. // 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!

12. 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!

13. Agenda - Practical Part Page • Welcome01 • Thesis Goals 05 • Contributions 06 • Object—Oriented (OO) Development 08 • Software Design Patterns09 • Evaluation Approach 15 • Implementation 16 • Evaluation 17 • High—Lights 23 • Evaluation Conclusions 26 • Perspectives 29 • Summary 31 • Final Remarks 32 • Questions? 33

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

15. 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.

16. 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 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)

17. High thoughts must have a high language. –– Aristophanes Evaluation

18. 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

19. 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.

20. 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

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

22. 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: 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

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

24. 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

25. 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

26. Program testing can be used to show the presence of bugs, but never to show their absence! –– Edsger W. Dijkstra Evaluation Conclusions

27. 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?

28. Agenda - Postscript Page • Welcome01 • Thesis Goals 05 • Contributions 06 • Object—Oriented (OO) Development 08 • Software Design Patterns09 • Evaluation Approach 15 • Implementation 16 • Evaluation 17 • High—Lights 23 • Evaluation Conclusions 26 • Perspectives 29 • Summary 31 • Final Remarks 32 • Questions? 33

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

30. Perspectives • “Non—trivial knowledge—base”: experience, solutions, inspiration • Well—suited for a website (“wiki”): fast look—up based on pattern and/or feature, cross referencing, smaller parts (as opposed to large document), open—source • Extendable: new patterns, new implementations, new languages • Componentization: overall quite possible results considering • Creational, and especially Behavioural patterns well suited • High—lights: target componentization directly • Interesting Meta—classes: ditto • Tooling support: patterns in IDE’s, e.g. Eclipse templates • Example: Singleton—as—Single—Constant idiom, generic Factory<T> usage, etc • Tooling support: annotations and Annotation Processing Tool (APT) • Generate code: structural Meta data available at runtime → “pattern framework”? • Generate documentation: identify usage of different patterns and participants • Patterns vs.Dependency Injection and Inversion of Control • Outside thesis scope, but: Creational patterns obsolete? Different focus? • Used by many new frameworks→e.g. Google Guice changes factory usage

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

32. 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

33. Agenda - The End Page • Welcome01 • Thesis Goals 05 • Contributions 06 • Object—Oriented (OO) Development 08 • Software Design Patterns09 • Evaluation Approach 15 • Implementation 16 • Evaluation 17 • High—Lights 23 • Evaluation Conclusions 26 • Perspectives 29 • Summary 31 • Final Remarks 32 • Questions? 33

35. “Extras”

36. Design Patterns

37. 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

38. Feature Observations

39. 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

40. Implementation Level

42. Model