CS/CE 2336 Computer Science II UT D Session 20 Design Patterns An Overview 2
History Architect Christopher Alexander coined the term "pattern" circa 1977-1979 Kent Beck and Ward Cunningham, OOPSLA'87 used Alexander's "pattern" ideas for Smalltalk GUI design Gamma, Helm, Johnson, Vlissides ("Gang of Four - GoF) book Design Patterns: Elements of Reusable Object-Oriented Software, 1994 PLoP conferences, 1994 - Buschmann, Meunier, Rohnert, Sommerland, Stal, Pattern - Oriented Software Architecture: A System of Patterns ( POSA book ) 3 What is a Pattern? Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander, circa 1977 Dictionary: a fully realized form, original, or model accepted or proposed for imitation 4
What is a Design Pattern? A tool for capturing and communicating the wisdom and experience of expert designers Facilitate reuse at high level Gamma et al. Each design pattern systematically names, explains, and evaluates an important and recurring design in object-oriented systems. The goal is to capture design experience in a form that people can use effectively. 5 What Patterns Are Not? Algorithms Algorithms: merge-sort Design patterns: divide and conquer Software components Components: software ICs Design patterns: design used by a software component 6
Patterns Essential Elements Name Pattern identification Problem describes the problem and context applicable to the pattern Solution elements that make up the design their relationships, responsibilities and collaborations Consequences results and trade-offs of applying the pattern 7 Why Patterns Provide higher level of reuse Reuse of solutions and designs Provide a common vocabulary for documenting complex problems and their solutions Provide shorthand for effective communication of complex principles Help document software architectures Capture essential parts of a design in compact form Can be used to describe software abstractions 8
Patterns in Software Engineering Design patterns architectural design (micro-architectures) idioms Analysis patterns reusable analysis models Organization patterns Process patterns 9 Design Pattern Description Canonical Form Name meaningful name Problem the statement of the problem Context a situation giving rise to a problem Forces a description of relevant forces and constraints Solution proven solution to the problem 10
Design Pattern Description Canonical Form Examples sample applications of the pattern Resulting context (consequences) the state of the system after pattern has been applied Rationale explanation of steps or rules in the pattern Related patterns static and dynamic relationship Known use occurrence of the pattern and its application within existing system 11 Design Pattern Description GoF Format Pattern name and classification Intent what does pattern do / when the solution works Also known as other known names of pattern (if any) Motivation the design problem / how class and object structures solve the problem 12
Design Pattern Description GoF Format Applicability situations where pattern can be applied Structure a graphical representation of classes in the pattern Participants the classes/objects participating and their responsibilities Collaborations of the participants to carry out responsibilities 13 Design Pattern Description GoF Format Consequences trade-offs, concerns Implementation hints, techniques Sample code a code fragment showing possible implementation Known uses patterns found in real systems Related patterns closely related patterns 14
Design Patterns Taxonomy Purposes Creational how an object is created often involves isolating the details of object creation so your code isn t dependent on what types of objects there are Structural designing objects to satisfy particular project constraints dealing with the way objects are connected with other objects to ensure that changes in the system don t require changes to those connections Behavioral handle particular types of actions encapsulate processes that you want to perform, e.g. fulfilling a request, moving through a sequence, changing states 15 Design Patterns A Catalog (GoF) Scope Class Object Factory Method Abstract Factory Builder Prototype Singleton Purpose Creational Structural Behavioral Adapter Adapter Bridge Composite Decorator Façade Flyweight Proxy Interpreter Template Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 16
Design Pattern Example State Pattern Intent Allow an object to change its behavior when its state changes. The object will appear to belong to another class When to use An object can be in multiple states, and it must change its behavior at run-time depending on its current state Operations have large, multipart conditional statements that depend on state of the object Usually represented by constants Some times the same conditional structure is repeated 17 Design Pattern Example State Pattern if (mymood= happy) then { smileandsing();. } else if (mymood= sad) then { gotopub();. } else if (mymood = ) then {. 18
Class Diagram Design Pattern Example State Pattern request() Context state <<abstract>> State handle() ConcreteStateA ConcreteStateB handle() handle() state.handle(); 19 State Pattern Example water state variable StateOfWater decreasetemp() decreasetemp() WaterVapor LiquidWater Ice Client decreasetemp() decreasetemp() decreasetemp() 20