Design Patterns

Sisimon E S

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.

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.

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

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 ”

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.

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)

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.

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.

Composite Pattern Example 2

GraphicDraw()Add(Graphic)Remove(Graphic)

TableDraw()Add(Graphic)Remove(Graphic)

LineDraw()

0..*

RectDraw()

GraphicDraw()Add(Graphic)Remove(Graphic)

PictureDraw()Add(Graphic)Remove(Graphic)

GraphDraw()

0..*

TableDraw()

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.

Strategy(2)

FormatDoFormat()=0;

FormatAlgo2DoFormat()

Editor

FormatAlgo1DoFormat()

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.

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.

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.

•

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.

Abstract Factory(2)

MacWinFactory

CreateScrollBar()CreateWindows()

GUIFactoryCreateScrollBar() = 0;CreateWindows()=0;

WindowsWinFactory

CreateScrollBar()CreateWindows()

Client

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

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.

Switch Example..

Bridge(2)

MacWindowImp

DeviceDrawText()DeviceDrawRect()

WindowsImpDeviceDrawText()=0;DeviceDrawRect()=0;

XWindowsImp

DeviceDrawText()DeviceDrawRect()

WindowDrawText()DrawRect()

DialogBox

DrawBorder()

FrameWnd

…..

Window::DrawRect()m_pWndImpl->DevDrawRect()

MACWin->Line()

MacWin->Line()

MacWin->Line()

MacWin->Line()

XWin->Rect()

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

Singleton

• Only one object instance, provide global access to it.

• Many printers in a system, but only one printer spooler.

Singleton(2)

• See code Singleton.cpp