Overview of Design Patterns Vijayan Sugumaran Department of DIS Oakland University

Purpose A design pattern captures design expertise –patterns are not created from thin air, but abstracted from existing design examples Using design patterns is reuse of design expertise Studying design patterns is a way of studying how the “experts” do design Design patterns provide a vocabulary for talking about design

Background Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the “Gang of Four”) – “Design Patterns: Elements of Reusable Object-Oriented Software” published in 1995, by Addison-Wesley This book solidified thinking about patterns and became the seminal Design Patterns text Software design patterns are based (somewhat) on work by the architect Christopher Alexander – work on pattern language

Design Patterns Design pattern - a common solution to a give problem in a given context, which supports reuse of proven approaches and techniques. Advantages Allow us to design with the experiences of those who came before rather than having to "reinvent the wheel." Provide designers a short-hand notation for discussing design issues. Teaching Notes You can think of design patterns as an FAQ, a "rule of thumb" or helpful advice for design issues.

Why design patterns in SA? If you’re a software engineer, you should know about them anyway There are many architectural patterns published, and the GoF Design Patterns is a prerequisite to understanding these: Mowbray and Malveau – CORBA Design Patterns Schmidt et al – Pattern-Oriented Software Architecture Design Patterns help you break out of first-generation OO thought patterns

The seven layers of architecture* ORB OO architecture Global architecture Enterprise architecture Subsystem System architecture Application architecture Frameworks Macro-architecture Design patterns Micro-architecture Objects OO programming * Mowbray and Malveau

How patterns arise Benefits Related Patterns Consequences Forces Problem Context Solution

Structure of a pattern Name Intent Motivation Applicability Structure Consequences Implementation Known Uses Related Patterns

Key patterns The following patterns are considered to be a good “basic” set of design patterns Competence in recognizing and applying these patterns will improve your low-level design skills

Gang-of-Four Patterns Creational Abstract factor Builder Factory method Prototype Singleton Structural Adapter Bridge Composite Decorator Façade Proxy Behavioral Chain of responsibility Command Flyweight Interpreter Iterator Mediator Memento Observer State Strategy Template method Visitor Teaching Notes There are many other patterns beside the GOF patterns (as the Martin Fowler pattern shown on the previous slide).

Adapter Pattern Pattern: Adapter Category: Structural Problem: How to provide a stable interface to similar classes with different interfaces? Solution: Add a class that acts as an adapter to convert the interface of a class into another interface that the client classes expect. Teaching Notes Sales Tax Adapter class provides an unchanging interface to Member Order class (and others). Brand X Adapter translates interfaces of Sales Tax Adapter to interface of Brand X Sales Tax Calculator If ever change from Brand X, have only to write a new adapter subtype.

Composite Pattern Client Component Leaf Composite Construct part-whole hierarchy Simplify client interface to leaves/composites Easier to add new kinds of components 0..* Client Component Operation() Add(Component) Remove(Component) children Leaf Composite Operation() Operation() Add(Component) Remove(Component) For all c in children c.Operation();

Composite Pattern Example Example: figures in a structured graphics toolkit Controller 0..* 0..* View Figure children paint() translate() getBounds() LabelFigure BasicFigure CompositeFigure parent paint() paint() paint() addFigure(Figure)) removeFigure(Figure)) For all c in children c.paint();

Strategy Pattern Context Strategy ConcreteStrategy1 ConcreteStrategy2 Make algorithms interchangeable---”changing the guts” Alternative to subclassing Choice of implementation at run-time Increases run-time complexity Context Strategy ContextInterface() Operation() ConcreteStrategy1 ConcreteStrategy2 Operation() Operation()

Strategy Pattern Example Example: drawing different connector styles shape=router.recalculate(start,end); redraw(shape); Connector ConnectorRouter route() Shape recalculate(Pt, Pt) StraightRouter ArcRouter ManhattanRouter Shape recalculate(Pt, Pt) Shape recalculate(Pt, Pt) Shape recalculate(Pt, Pt)

Chain of Responsibility Pattern Decouple sender of a request from receiver Give more than one object a chance to handle Flexibility in assigning responsibility Often applied with Composite successor Client Handler ContextInterface() handleRequest() ConcreteHandler1 ConcreteHandler2 handleRequest() handleRequest()

Chain of Responsibility Pattern Example Example: handling events in a graphical hierarchy If interactor != null interactor.handle(event,this) else parent.handleEvent(event) 0..1 0..* 0..* Interactor Figure children handle(Event,Figure) handleEvent(Event) CompositeFigure parent

Abstract Factory Pattern Problem Context: 1. Consider a user interface toolkit to support multiple look-and-feel standards. 2. For portability an application must not hard code its widgets for one look and feel. How to design the application so that incorporating new look and feel requirements will be easy?

Abstract Factory Pattern Example Define an abstract WidgetFactory class This class declares an interface to create different kinds of widgets There is one abstract class for each kind of widget and concrete subclasses implement widgets for different standards WidgetFactory offers an operation to return a new widget object for each abstract widget class. Clients call these operations to obtain instances of widgets without being aware of the concrete classes they use

Abstract Factory Pattern Example WidgetFactory CreateScrollbar() CreateWindow() Client Window WWindow MacWindow WWidgetFactory MacWidgetFactory ScrollBar MacScrollBar WScrollBar One for each standard.

Abstract Factory Pattern Example CreateScrollbar() CreateWindow() Client ProductA1 ProductA2 AbstractProductA ProductB2 ProductB1 AbstractProductB ConcreteFactory1 ConcreteFactory2 CreateProductA() CreateProductB()

Abstract Factory Pattern: Participants and Communication AbstractFactory: Declares the interface for operations to create abstract product objects ConcreteFactory: Implements the operations to create concrete product objects. AbstractProduct: Declares an interface for a type of product object. ConcreteProduct: Defines a product object to be created by the corresponding factory. Client: Uses only the interface declared by the abstractFactory and AbstractProduct classes.

Abstract Factory Pattern Code class MazeFactory { // Creates components of mazes. // Builds rooms, walls, and doors. public: MazeFactory(); virtual Maze* MakeMaze() const { return new Maze;} // This factory is a collection of // factory methods. Also, this class // acts both as Abstract and Concrete // Factory virtual Wall* MakeWall() const { return new Wall;} virtual Wall* MakeRoom(int n) const { return new Room;} // more methods. }

Abstract Factory Pattern Code Maze* MazeGame:: CreateMaze (MazeFactory& factory) // Builds a maze. Maze* aMaze = factory.MakeMaze(); Room* myroom = factory.MakeRoom(1); Room* herroom = factory.MakeRoom(2); Door* aDoor = factory.MakeDoor(myRoom,herRoom) aMaze AddRoom(myRoom) // One can also create a // BombedMazeFactory with // different types of Rooms // and Walls. aMaze AddRoom(herRoom) // More code to add walls. }

Patterns vs “Design” Patterns are design But: patterns transcend the “identify classes and associations” approach to design Instead: learn to recognize patterns in the problem space and translate to the solution Patterns can capture OO design principles within a specific domain Patterns provide structure to “design”

Patterns vs Frameworks Patterns are lower-level than frameworks Frameworks typically employ many patterns: Factory Strategy Composite Observer Done well, patterns are the “plumbing” of a framework

Patterns vs Architecture Design Patterns (GoF) represent a lower level of system structure than “architecture” (cf: seven levels of A) Patterns can be applied to architecture: Mowbray and Malveau Buschmann et al Schmidt et al Architectural patterns tend to be focussed on middleware. They are good at capturing: Concurrency Distribution Synchronization

Summary Design Patterns (GoF) provide a foundation for further understanding of: Object-Oriented design Software Architecture Understanding patterns can take some time Re-reading them over time helps As does applying them in your own designs!