Presentation is loading. Please wait.

Presentation is loading. Please wait.

Overview of Design Patterns Vijayan Sugumaran Department of DIS Oakland University.

Similar presentations


Presentation on theme: "Overview of Design Patterns Vijayan Sugumaran Department of DIS Oakland University."— Presentation transcript:

1 Overview of Design Patterns Vijayan Sugumaran Department of DIS Oakland University

2 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

3 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

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

5 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

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

7 How patterns arise Benefits Related Patterns Consequences Forces Problem Context Solution

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

9 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

10 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

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

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

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

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

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

16 Chain of Responsibility Pattern Handler handleRequest() ConcreteHandler2 handleRequest() Client ContextInterface() ConcreteHandler1 handleRequest()  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

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

18 Abstract Factory Pattern 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? Problem Context:

19 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

20 Abstract Factory Pattern Example WidgetFactory CreateScrollbar() CreateWindow() WindowScrollBar WWidgetFactory MacWidgetFactory Client WWindowMacWindow MacScrollBarWScrollBar One for each standard.

21 Abstract Factory Pattern Example AbstractFactory CreateScrollbar() CreateWindow() ConcreteFactory1 Client ProductA1ProductA2 AbstractProductA ProductB2ProductB1 AbstractProductB ConcreteFactory2 CreateProductA() CreateProductB()

22 Abstract Factory Pattern: Participants and Communication  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.  AbstractFactory: Declares the interface for operations to create abstract product objects  Client: Uses only the interface declared by the abstractFactory and AbstractProduct classes.

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

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

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

26 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

27 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

28 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!


Download ppt "Overview of Design Patterns Vijayan Sugumaran Department of DIS Oakland University."

Similar presentations


Ads by Google