Motivation and Concept

1. Motivation and Concept • OOD methods emphasize design notations • Fine for specification, documentation • But OOD is more than just drawing diagrams • Good draftsmen are good designers • Good OO designers rely on lots of experience • At least as important as syntax • Most powerful reuse is design reuse • Match problem to design experience

2. Motivation and Concept • OO systems exploit recurring design structures that promote • abstraction • flexibility • modularity • elegance • Therein lies valuable design knowledge • Problem: capturing, communicating, and applying this knowledge

3. Design Patterns • Patterns for software development are one of the latest "hot topics" to emerge from the object-oriented community. They are a literary form of software engineering problem-solving discipline that has its roots in a design movement of the same name in contemporary architecture, literate programming and the documentation of best practices and lessons learned in all vocations.

4. Pattern Origins • Software patterns first became popular with the wide acceptance of the book Dessign Patterns: Elements of Reusable Object Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (frequently referred to as the Gang of Four or just GoF). Patterns have been used for many different domains ranging from organizations and processes to teaching and architecture. At present, the software community is using patterns largely for software architecture and design, and (more recently) software development processes and organizations.

5. What is a Pattern? • abstracts a recurring design structure • comprises class and/or object • dependencies • structures • interactions • conventions • names & species the design structure explicitly • distills design experience

6. What is a Patterns? • A Design Pattern has 4 basic parts: • 1. Name • 2. Problem • 3. Solution • 4. Consequences and trade-offs of application • Language- and implementation-independent • A micro-architecture • Adjunct to existing methodologies (UML/P, Fusion, etc.)

7. Goals • Codify good design • Distill and disseminate experience • Aids to experts and novices alike • Abstract how to think about design • Give design structures explicit names • Common vocabulary • Reduce complexity • Greater expressiveness • Capture and preserve design information • Articulates design decisions succinctly • Improve documentation • Facilitates restructuring/defactoring • Patterns are interrelated • Additional flexibility

8. Design Pattern Template • Name scope purpose • Intent • short description of pattern and its purpose • Also Known As • other names that people have for the pattern • Motivation • motivating scenario demonstrating pattern's use • Applicability • circumstances in which pattern applies • Structure • graphical representation of the pattern • Participants • participating classes and/or objects and their responsibilities

9. Design Pattern Template • Collaborations • how participants cooperate to carry out their responsibilities • Consequences • the results of application, benets, liabilities • Implementation • implementation pitfalls, hints, or techniques, plus any language-dependent issues • Sample Code • sample implementations in C++ or Smalltalk • Known Uses • examples drawn from existing systems • Related Patterns • discussion of other patterns that relate to this one

10. Generative Patterns • These patterns in our minds are, more or less, mental images of the patterns in the world: they are abstract representations of the very morphological rules which define the patterns in the world. However, in one respect they are very different. The patterns in the world merely exist. But the same patterns in our minds are dynamic. They have force. They are generative. They tell us what to do; they tell us how we shall, or may, generate them; and they tell us too, that under certain circumstances, we must create them. Each pattern is a rule which describes what you have to do to generate the entity which it defines.

11. Patterns are Useful, Useable and Used • A pattern is where theory and practice meet to reinforce and complement one another, by showing that the structure it describes is useful, useable, and used! • A pattern must be useful because this shows how having the pattern in our minds may be transformed into an instance of the pattern in the real world, as something thing that adds value to our lives as developers and practitioners. A pattern must also be useable because this shows how a pattern described in literary form may be transformed into a pattern that we have in our minds. And a pattern must be used because this is how patterns that exist in the real world first became documented as patterns in literary form.

12. Kinds of Patterns • Much of the initial patterns focus in the software community has been on design patterns. The patterns in the [GoF] book are object-oriented design patterns. There are many other kinds of software patterns besides design patterns. • Martin Fowler has written a book of Analysis Patterns. • There is also a website and mailing list for Organizational patterns. These patterns encompasse all aspects of software engineering including: development organization, software process, project planning, requirements engineering, and software configuration management (just to name a few). Presently however, design patterns still seem to be the mostpopular

13. Kinds of Design Patterns • Architectural Patterns: An architectural pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. • Design Patterns: A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes commonly recurring structure of communicating components that solves a general design problem within a particular context. • Idioms: An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

14. Quality of Patterns • Encapsulation and Abstraction • Each pattern encapsulates a well-defined problem and its solution in a particular domain. Patterns should provide crisp, clear boundaries that help crystallize the problem space and the solution space by parceling them into a lattice of distinct, interconnected fragments. They also serve as abstractions which embody domain knowledge and experience, and may occur at varying hierarchical levels of conceptual granularity within the domain. • Openness and Variability • Each pattern should be open for extension or parametrization by other patterns so that they may work together to solve a larger problem. A pattern solution should be also capable of being realized by an infinite variety of implementations (in isolation, as well as in conjunction with other patterns).

15. Quality of Patterns • Generativity and Composability • Each pattern, once applied, generates a resulting context which matches the initial context of one or more other patterns in a pattern language. These subsequent patterns may then be applied to progress further toward the final goal of generating a "whole" or complete overall solution. • Equilibrium • Each pattern must realize some kind of balance among its forces and constraints. This may be due to one or more invariants or heuristics that are used to minimize conflict within the solution space. The invariants often typify an underlying problem solving principle or philosophy for the particular domain, and provide a rationale for each step/rule in the pattern.

16. Patterns and Algorithms • Algorithms and data structures are usually concerned almost exclusively with optimizing space or time or some other aspect of computational complexity and resource consumption. They are about finding the most compact and efficient means to perform some important computation or store and recall its results. Such algorithms and data structures are rarely concerned with compromises and tradeoffs regarding other concerns that other concerns that have little to do with things like performance or memory, and more to do with things like maintainability and adaptability and (re)usability of the architecture.

17. Patterns and Frameworks • Patterns support reuse of software architecture and design • Patterns capture the static and dynamic structures and collaborations of successful solutions to problems that arise when building applications in a particular domain • Frameworks support reuse of detailed design and code • A framework is an integrated set of components that collaborate to provide a reusable architecture for a family of related applications

18. Patterns and Frameworks • Together, design patterns and frameworks help to improve software quality and reduce development time • e.g., reuse, extensibility, modularity, performance

19. Patterns of Learning • Successful solutions to many areas of human endeavor are deeply rooted in patterns • In fact, an important goal of education is transmitting patterns of learning from generation to generation • In a moment, we’ll explore how patterns are used to learn chess • Learning to develop good software is similar to learning to play good chess • Though the consequences of failure are often far less dramatic!

20. Becoming a Chess Master • First learn the rules • e.g., names of pieces, legal movements, chess board geometry and orientation, etc. • Then learn the principles • e.g., relative value of certain pieces, strategic value of center squares, power of a threat, etc. • However, to become a master of chess, one must study the games of other masters • These games contain patterns that must be understood, memorized, and applied repeatedly • There are hundreds of these patterns

21. Becoming a Software Design Master • First learn the rules • e.g., the algorithms, data structures and languages of software • Then learn the principles • e.g., structured programming, modular programming, object oriented programming, generic programming, etc. • However, to become a master of software design, one must study the designs of other masters • These designs contain patterns that must be understood, memorized, and applied repeatedly • There are hundreds of these patterns

22. Design Patterns • Design patterns represent solutions to problems that arise when developing software within a particular context • i.e., “Pattern == problem/solution pair in a context” • Patterns capture the static and dynamic structure and collaboration among key participants in software designs • They are particularly useful for articulating how and why to resolve non-functional forces • Patterns facilitate reuse of successful software architectures and designs

23. Design Pattern Descriptions • Main parts • 1. Name and intent • 2. Problem and context • 3. Force(s) addressed • 4. Abstract description of structure and collaborations in solution • 5. Positive and negative consequence(s) of use • 6. Implementation guidelines and sample code • 7. Known uses and related patterns • Pattern descriptions are often independent of programming language or implementation details • Contrast with frameworks

24. Frameworks • 1. Frameworks are semi-complete applications • Complete applications are developed by inheriting from, and instantiating parameterized framework components • 2. Frameworks provide domain-specific functionality • e.g., business applications, telecommunication applications, window systems, databases, distributed applications, OS kernels • 3. Frameworks exhibit inversion of control at run-time • i.e., the framework determines which objects and methods to invoke in response to events

25. Class Libraries vs. Frameworks vs. Patterns Definition • Class libraries • Self-contained, “pluggable” ADTs • Frameworks – Reusable, “semi-complete” applications • Patterns – Problem, solution, context

26. Component Integration in Frameworks • Framework components are loosely coupled via callbacks • Callbacks allow independently developed software components to be connected together • Callbacks provide a connection-point where generic framework objects can communicate with application objects • The framework provides the common template methods and the application provides the variant hook methods

27. Comparing Patterns and Frameworks • Patterns and frameworks are highly synergistic • i.e., neither is subordinate • Patterns can be characterized as more abstract descriptions of frameworks, which are implemented in a particular language • In general, sophisticated frameworks embody dozens of patterns and patterns are often used to document frameworks

28. Design Pattern Space • Creational patterns • Deal with initializing and configuring classes and objects • Structural patterns • Deal with decoupling interface and implementation of classes and objects • Behavioral patterns • Deal with dynamic interactions among societies of classes and objects

29. Creational Patterns • Factory Method • Method in a derived class creates associates • Abstract Factory • Factory for building related objects • Builder • Factory for building complex objects incrementally • Prototype • Factory for cloning new instances from a prototype • Singleton • Factory for a singular (sole) instance

30. Structural Patterns • Adapter • Translator adapts a server interface for a client • Bridge • Abstraction for binding one of many implementations • Composite • Structure for building recursive aggregations • Decorator • Decorator extends an object transparently

31. Structural Patterns • Facade • Facade simplifies the interface for a subsystem • Flyweight • Many fine-grained objects shared efficiently • Proxy • One object approximates another

32. Behavioral Patterns • Chain of Responsibility • Request delegated to the responsible service provider • Command • Request as first-class object • Interpreter • Language interpreter for a small grammar • Iterator • Aggregate elements are accessed sequentially

33. Behavioral Patterns • Mediator • Mediator coordinates interactions between its associates • Memento • Snapshot captures and restores object states privately • Observer • Dependents update automatically when a subject changes • State • Object whose behavior depends on its state

34. Behavioral Patterns • Strategy • Abstraction for selecting one of many algorithms • Template Method • Algorithm with some steps supplied by a derived class • Visitor • Operations applied to elements of an heterogeneous object structure

35. When to Use Patterns • 1. Solutions to problems that recur with variations • No need for reuse if the problem only arises in one context • 2. Solutions that require several steps • Not all problems need all steps • Patterns can be overkill if solution is simple linear set of instructions • 3. Solutions where the solver is more interested in the existence of the solution than its complete derivation • Patterns leave out too much to be useful to someone who really wants to understand • They can be a temporary bridge, however

36. What Makes a Pattern a Pattern? A pattern must: • Solve a problem, • i.e., it must be useful! • Have a context, • It must describe where the solution can be used • Recur, • It must be relevant in other situations • Teach • It must provide sufficient understanding to tailor the solution • Have a name • It must be referred to consistently

37. Benefits of Design Patterns • Design patterns enable large-scale reuse of software architectures • They also help document systems to enhance understanding • Patterns explicitly capture expert knowledge and design tradeoffs, and make this expertise more widely available • Patterns help improve developer communication • Pattern names form a vocabulary • Patterns help ease the transition to object- oriented technology

38. Drawbacks to Design Patterns • Patterns do not lead to direct code reuse • Patterns are deceptively simple • Teams may suffer from pattern overload • Patterns are validated by experience and discussion rather than by automated testing • Integrating patterns into a software development process is a human-intensive activity

39. Tips for Using Patterns Effectively • Do not recast everything as a pattern. • Instead, develop strategic domain patterns and reuse existing tactical patterns • Institutionalize rewards for developing patterns • Directly involve pattern authors with application developers and domain experts • Clearly document when patterns apply and do not apply • Manage expectations carefully

40. Lessons Learned using OO Frameworks • Benefits of frameworks • Enable direct reuse of code • Facilitate larger amounts of reuse than stand-alone functions or individual classes • Drawbacks of frameworks • High initial learning curve • Many classes, many levels of abstraction • The flow of control for reactive dispatching is non-intuitive • Verification and validation of generic components is hard

41. Patterns and Framework Literature Books • Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software AW, ’94 • Pattern Languages of Program Design series by AW, ’95-’99.