COSC 340: Software Engineering Design Patterns Michael Jantz Recommended text: Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides COSC 340: Software Engineering 1 Why Design Patterns? • Designing object-oriented software is hard ‒ Designing reusable object-oriented software is even harder • Good designers do not solve every problem from first principles ‒ When a good solution is found, reuse it over and over again • Patterns make it easier to reuse successful designs and architectures ‒ Pattern vocabulary makes systems more accessible to new developers ‒ Help you choose reusable designs ‒ Improve the documentation and maintainability of existing systems ‒ Help you get the design 'right' faster COSC 340: Software Engineering 2 Elements of Design Patterns • Pattern name ‒ A one or two word handle for describing the pattern • Problem ‒ When to apply the pattern (the problem and its context) • Solution ‒ Elements of the design, their relationships, responsibilities and collaborations • Consequences ‒ Results and trade-offs of applying the pattern COSC 340: Software Engineering 3 What is a Design Pattern? • Depends on your point of view • Useful to concentrate on a certain level of abstraction ‒ Do not consider objects that can be encoded and reused as is (e.g. linked lists and hash tables) ‒ Do not consider complex, domain-specific designs for an entire system • GoF Definition: ‒ Design patterns are "descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context" COSC 340: Software Engineering 4 Classifying Design Patterns • Purpose (what does the pattern do?) ‒ Creational (object creation) ‒ Structural (composition of classes or objects) ‒ Behavioral (characterize object interaction) • Scope (where does it apply – classes or objects?) ‒ Class patterns • Deal with relationships b/w classes and their subclasses • Static – fixed at compile time ‒ Object patterns • Deal with object relationships • More dynamic – can be changed at runtime COSC 340: Software Engineering 5 Organizing the Catalog Purpose Creational Structural Behavioral Class Factory Method Adapter Interpreter Template Method Abstract Factory Adapter Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Scope Singleton Decorator Mediator Object Façade Memento Proxy Flyweight Observer State Strategy Visitor 6 OMT Notation • Three diagrammatic notations ‒ Class diagram • depicts classes, their structure, and the static relationships between them ‒ Object diagram • depicts a particular object structure at run-time ‒ Interaction diagram • shows the flow of requests between objects COSC 340: Software Engineering 7 Class Diagrams 8 Class Diagrams 9 Object Diagrams COSC 340: Software Engineering 10 Interaction Diagram COSC 340: Software Engineering 11 Creational Patterns • Abstract away the instantiation process • Two recurring themes in creational patterns ‒ Encapsulate knowledge about which concrete classes the system uses ‒ Hide how instances of these classes are created and put together COSC 340: Software Engineering 12 Driving Example: Maze for a Computer Game • Focus only on how the maze is created ‒ Ignore players, operations for displaying and wandering around the maze, etc. • Maze definition ‒ Maze is a set of rooms ‒ Each room knows its neighbors ‒ Possible neighbors are another room, a wall, or a door to another room • Maze classes ‒ Room, Door, and Wall COSC 340: Software Engineering 13 Maze Class Diagram COSC 340: Software Engineering 14 MazeGame::CreateMaze COSC 340: Software Engineering 15 MazeGame::CreateMaze • Problem: CreateMaze is inflexible • Classes that get instantiated are hard-coded into this design • Creational patterns make this design more flexible • Allows you to remove explicit references to concrete classes COSC 340: Software Engineering 16 Factory Method Pattern • Intent ‒ Define an interface for creating an object, but let subclasses decide which class to instantiate • Motivation ‒ Frameworks with abstract classes often need to create objects when it is not known what kind of object to create ‒ The framework must instantiate classes, but it only knows about abstract classes, which it cannot instantiate • Solution ‒ Encapsulate the knowledge of the subclass to create and move this knowledge out of the framework COSC 340: Software Engineering 17 Factory Method Pattern: Structure COSC 340: Software Engineering 18 Factory Method Pattern: Implementation Two Major Variations • Creator is an abstract class ‒ Requires subclasses to define a factory method implementation • Creator is a concrete class with a default factory method implementation ‒ Factory method can be overridden for flexibility ‒ Follows the rule "create objects in a separate operation so that subclasses can override the way they're created." COSC 340: Software Engineering 19 Factory Method Pattern: MazeGame Example MazeGame Class and Maze Creation Code 20 Factory Method Pattern: MazeGame Example Potential Subclasses for MazeGame COSC 340: Software Engineering 21 Factory Method Pattern: Applicability • Use the Factory Method pattern when ‒ A class can't anticipate the class of objects it must create ‒ A class wants its subclasses to specify the objects it creates ‒ Classes delegate responsibility to one of several helper subclasses COSC 340: Software Engineering 22 Factory Method Pattern: Consequences Advantages and Disadvantages • Advantages ‒ Eliminate the need to bind concrete classes into your abstract code ‒ Provides hooks for subclasses ‒ Allows you to connect parallel class hierarchies (see next slide) • Disadvantage ‒ Might have to subclass the Creator just to create a particular type of object COSC 340: Software Engineering 23 Factory Method Pattern: Consequences Connecting Parallel Class Hierarchies • Consider a graphical program that manipulates figures interactively • Use a Manipulator class to implement interactions and keep of track of state • Factory Method enables the client code to create the Manipulator objects COSC 340: Software Engineering 24 Abstract Factory Pattern • Intent ‒ Provide an interface for creating families of related objects without specifying their concrete classes • Motivation ‒ It is often useful to define a portable interface for creating objects that can be reused in different environments or situations ‒ Example: creating widgets with different look-and-feel standards • Solution ‒ Use an abstract class to define an interface for creating each kind of object as well as abstract classes for each kind of object ‒ Define concrete subclasses to implement functionality specific to a particular situation or environment COSC 340: Software Engineering 25 Abstract Factory Pattern: Motivation Look-and-Feel Example • Desktop environment defines multiple look-and-feel standards ‒ Different look-and-feels change the way user-interface widgets (scroll bars, windows, buttons, etc.) are displayed ‒ Application code should not hard code widgets for a single look-and-feel • Abstract Factory design ‒ Application code interacts with abstract classes ‒ Use concrete subclasses to define the different look-and-feel standards COSC 340: Software Engineering 26 Abstract Factory Pattern: Motivation Look-and-Feel Example COSC 340: Software Engineering 27 Abstract Factory Pattern: Structure COSC 340: Software Engineering 28 Abstract Factory Pattern: Participants • AbstractFactory (WidgetFactory) ‒ Declares an interface for operations that create abstract product objects • ConcreteFactory (MotifWidgetFactory, PMWidgetFactory) ‒ Implements the operations to create concrete product objects • AbstractProduct (Window, ScrollBar) ‒ Declares an interface for a type of product object • ConcreteProduct (MotifWindow, MotifScrollBar) ‒ Defines a product object to be created by the corresponding concrete factory ‒ Implements the AbstractProduct interface • Client ‒ Uses only interfaces declared by AbstractFactory and AbstractProduct classes COSC 340: Software Engineering 29 Abstract Factory Pattern: Maze Example MazeFactory Implementation • Maze building programs take an instance of MazeFactory as an argument COSC 340: Software Engineering 30 Abstract Factory Pattern: Maze Example Parameterizing CreateMaze COSC 340: Software Engineering 31 Abstract Factory Pattern: Maze Example ConcreteFactory Implementations • Subclass of MazeFactory • Overrides member functions and returns different instances of rooms and doors COSC 340: Software Engineering 32 Abstract Factory Pattern: Maze Example ConcreteFactory Implementations • BombedMazeFactory ensures: • Walls are of class BombedWall • Rooms are of class RoomWithABomb • To build a simple maze with bombs, call CreateMaze with BombedMazeFactory COSC 340: Software Engineering 33 Abstract Factory Pattern: Maze Example MazeFactory Implementation • MazeFactory is a collection of factory methods • MazeFactory acts as both the AbstractFactory and a ConcreteFactory COSC 340: Software Engineering 34 Prototype Pattern • Intent ‒ Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype • Motivation ‒ Useful for when a system needs to be independent of how its objects are created, composed, and represented ‒ Enables you to avoid building a class hierarchy of factories that parallels the class hierarchy of products ‒ Example: graphical application for editing musical scores • Solution ‒ Parameterize object creation methods with prototype