The document discusses several design patterns including composite, strategy, decorator, abstract factory, bridge, and singleton. It provides examples of when and how each pattern can be used, such as using composite to group graphical elements uniformly, strategy to allow interchangeable algorithms, and decorator to add responsibilities dynamically without subclassing. Code snippets are referenced but not included.

1. Design Patterns Sisimon E S

2. Concepts Initiated in construction industry “ A Pattern Language: Towns, Buildings, Construction ” by Christopher Alexander. Patten concepts came to Software Industry from this book. Not specific to a programming language, but most software design patterns based on OOP.

3. Gang Of Four (GoF) “ Design Patterns: Elements of Reusable Object-Oriented Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. First book about Design Patterns in Software Engineering. All diagrams and samples in coming slides taken from this book. The Design Pattern concepts started in Software Engineering from this book.

4. Definition by Christopher Alexander “ Each pattern describes a problem that occur over and over again in our environment, and describes the core solution to that problem, in such a way we can use it millions of times, with out doing the same way twice.”

5. How Design Patterns help? Set of solutions for a set of known problems. You just match your problem with one in the set. Patterns help to decompose the module into small objects which is the toughest part in object oriented design. Easy to maintain. Read from a Slashdot discussion about the advantage of Design Patterns – “A mechanic who knows very well about how cars work can repair all cars, even TATA’s NANO also  ”

7. Categories of Design Patterns Creational Patters – Concerned about how objects are created. Structural Patterns – How objects are composed or structured. Behavioral Patters – How objects communicate each other to implement a logic or algorithm.

8. Some patterns Most of these solutions/patterns, you may feel, Oh I already know this solution. Yes that’s true, but this is a documented/standard solution or pattern and has this name. Composite (Structural) Strategy (Behavioral) Decorator (Structural) Abstract Factory (Creational) Bridge (Structural) Singleton (Creational)

9. Composite Pattern The Document editor support tables which is created using lines and texts. Then the editor support graphical diagrams that contains tables, graphs. (Again more complex pictures can form using these graphic diagrams) It is too complex to consider each primitive graphic elements (like line, circle, text,..) individually. Here the developer should consider diagrams as a unit rather than as a collection of individual graphic primitives. User should consider table as a whole instead of unstructured mass of text and lines.

10. Composite Pattern Example (a+b) – Object 1 (a+b)*c – Object 2 = Ob1 * c (a+b)*c/d – Object 2 / d (a+b) * x = Object 1 * x Option 1 – Calculate each expression independently, which is very complex and tough to maintain. Option 2 - Group multiple objects and consider groups and individual objects uniformly. Simple and easy to maintain.

11. Composite Pattern Example 2 Graphic Draw() Add(Graphic) Remove(Graphic) Table Draw() Add(Graphic) Remove(Graphic) Line Draw() 0..* Rect Draw()

12. Graphic Draw() Add(Graphic) Remove(Graphic) Picture Draw() Add(Graphic) Remove(Graphic) Graph Draw() 0..* Table Draw()

13. Strategy Need to support multiple formatting algorithms in the document editor. Client cannot implement all algorithms. Algorithm implement in an object. The object accepts data/context object as parameter. Make algorithms interchangeable. Makes algorithms independent of the clients that use it. Choice of algorithm implementation at run-time.

14. Strategy(2) Format DoFormat()=0; FormatAlgo2 DoFormat() Editor FormatAlgo1 DoFormat()

15. Decorator Some of the windows need to have border. Some of the windows need scroll bar. Can have ScrollableWindow, BorderedWindow, BordedWithScrollableWindow classes. Having separate class for each specialized windows is more complex.

16. Decorator(2) A Decorator, also known as a Wrapper A Decorator is an object that has an interface identical to an object that it contains. Any calls that the decorator gets, it forward to the object that it contains, and adds its own functionality along the way, either before or after the call. Attach additional responsibilities to a object (not class) dynamically. Decorator provide flexible alternative to subclassing for extending functionality.

17. Decorator(3) class BorderWindows: public Window { public: BorderDecorator(Window *p): virtual void Draw() { m_pWindow>Draw(); //Call the original implementation DrawBorder();// add extra functionality } }; TextWindow *pTextWnd = new TextWindow;// TextWindow derived from Window BorderWindow *pBorderedWindow = new BorderWindow(pTextWnd); pBorderedWindow->Draw();// Draw the text windows first, then draw the border above it. ButtonWindow *pBtnWnd = new ButtonWindow;// ButtonWindow derived from Window BorderWindows *pBorderedWindow2 = new BorderWindows(pBtnWnd); pBorderedWindow->Draw();// Draw the button windows first, then draw the border above it.

18. Abstract Factory Factories create product objects. Provide interface for creating families of related objects. A UI toolkit support Windows and Mac look-and-feel and planning to add Linux type windows in future. The toolkit should be independent of UI look-and-feel.

19. Abstract Factory(2) Note:- Here client got a pointer to GUIFactory interface which can be Mac or Windows. Client don’t know which type Window and where the GUIFactory pointer came from. MacWinFactory CreateScrollBar() CreateWindows() GUIFactory CreateScrollBar() = 0; CreateWindows()=0; WindowsWinFactory CreateScrollBar() CreateWindows() Client

20. Bridge Take the above toolkit example. We have multiple existing window standard. But unfortunately these libraries interfaces are not compatible each other (like one library support API to draw rectangle, but other library support API to draw line only, not rectangle). Then we cannot use Factory Pattern here. Decouple the interfaces from its implementation. No need to change client code to incorporate changes in implementation.

21. Switch Example..

22. Bridge(2) MacWindowImp DeviceDrawText() DeviceDrawRect() WindowsImp DeviceDrawText()=0; DeviceDrawRect()=0; XWindowsImp DeviceDrawText() DeviceDrawRect() Window DrawText() DrawRect() DialogBox DrawBorder() FrameWnd … .. Window::DrawRect() m_pWndImpl->DevDrawRect() MACWin->Line() MacWin->Line() MacWin->Line() MacWin->Line() XWin->Rect()

23. Sorry I don’t have code. Refer GoF’s book for a nice example,

24. Singleton Only one object instance, provide global access to it. Many printers in a system, but only one printer spooler.

25. Singleton(2) See code Singleton.cpp