Design Patterns Satya Puvvada Objectives Gain an understanding

Design Patterns Satya Puvvada

Objectives ¨ Gain an understanding of using design patterns to improve design and implementation ¨ Learn to develop robust, efficient and reusable C++ programs using design patterns Satya Puvvada

Contents – Day 1 ¨ Introduction to design patterns ¨ Introduction to UML notation ¨ Patterns – Singleton – Factory method – Abstract Factory – Observer – Strategy – Adapter – Visitor Satya Puvvada

Contents – Day 2 ¨ Patterns – Builder – Bridge – Facade – Proxy – Composite – Chain of responsibility – Command Satya Puvvada

Contents – Day 3 ¨ Patterns – Flyweight – Memento – State – Decorator – Prototype – Mediator ¨ Case Study ¨ References and conclusions Satya Puvvada

Satya Puvvada

Fly. Weight ¨ Use sharing to support large numbers of fine -grained objects efficiently. Satya Puvvada

Fly. Weight ¨ If each character is an object in a text editor, number of objects > 100000 for moderately sized documents ¨ Share objects to reduce the number of objects but gives the same flexibility ¨ Intrinsic v/s extrinsic state (value of the character v/s location to be drawn) ¨ Extrinsic state is always supplied by the client Satya Puvvada

Fly. Weight Satya Puvvada

Flyweight: Structure Satya Puvvada

Flyweight example Satya Puvvada

Flyweight: Instances Satya Puvvada

Flyweight - Consequences ¨ May introduce runtime costs due to transferring of book keeping of shared objects, computing intrinsic state etc – but this offset by the savings in space and flexiblility offered ¨ The more flyweights shared – more the space savings Satya Puvvada

Flyweight - Consequences ¨ Source code Satya Puvvada

Memento ¨ Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. Satya Puvvada

Memento Structure… Satya Puvvada

Memento n Source code Satya Puvvada

State ¨ Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. Satya Puvvada

Example Satya Puvvada

Structure Satya Puvvada

Consequences 1. It localizes state-specific behavior and partitions behavior for different states 2. It makes state transitions explicit 3. State objects can be shared Satya Puvvada

Decorator - Intent Attach additional responsibility to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Satya Puvvada

Synopsis ¨ Provides a dynamic and lightweight substitute for subclassing – Each object is only decorated with the functionality it needs – Takes full advantage of the class hierarchy and inheritance Satya Puvvada

Context ¨ Many possible uses – X windows uses Decorators to apply decorations to windows, hence the name – Generally used when the programmer wants many instances of the same parent class with many different behaviors, but without creating many subclasses. Satya Puvvada

Forces ¨ Suppose you have a user interface toolkit and you wish to make a border or scrolling feature available to clients without defining new subclasses of all existing classes. The client "attaches" the border or scrolling responsibility to only those objects requiring these capabilities. Widget* a. Widget = new Border. Decorator( new Hor. Scroll. Decorator( new Ver. Scroll. Decorator( new Text. Widget( 80, 24 )))); a. Widget->draw(); Satya Puvvada

Forces ¨ Allows transparent addition of functionality. ¨ Decorators are decoupled from base class and each other. ¨ Decorators can be added or removed dynamically and easily. Satya Puvvada

Solution ¨ Enclose the base class in a decorator class that maintains the same interface ¨ Totally transparent to program using the Decorators and to other decorators Satya Puvvada

Consequences ¨ Good Things – Allows the use of multiple decorators, including the same one multiple times – Totally decoupled. Each decorator is only aware of the thing it is decorating, and the base class is not aware that it has been decorated. ¨ Bad things – Can be difficult to Satya Puvvada remove specific decorators dynamically – Decorator has the same interface as base class, but is not the same object, which can lead to problems if, for example, the address of the base class is needed

Implementation ¨ If the object needs to call itself or pass itself, it may need to pass its decorators as well. If this is the case, it must be made aware of them. ¨ Changing the middle decorator of a pile can be like removing the middle layer of noodles from lasagna. It’s possible, but easier said than done and quite messy. Satya Puvvada

Related patterns ¨ Adapter changes interface ¨ Proxy duplicates interface ¨ Decorator enhances interface Satya Puvvada

PROTOTYPE (Object Creational) ¨ Intent: – Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. ¨ Motivation: – Framework implements Graphic class for graphical components and Graphic. Tool class for tools manipulating/creating those components – Actual graphical components are application-specific – How to parameterize instances of Graphic. Tool class with type of objects to create? – Solution: create new objects in Graphic. Tool by cloning a prototype object instance Satya Puvvada

PROTOTYPE Motivation Graphic Tool Draw(Position) Manipulate() Clone() prototype Staff Rotate Tool Manipulate() Graphic Tool Manipulate() Musical. Note Draw(Position) Clone() p = prototype >Clone() while(user drags mouse){ p >Draw(new position) Whole. Note Half. Note Draw(Position) Clone() } Insert p into drawing Return copy of self Satya Puvvada Return copy of self

Applicability ¨ Use the Prototype pattern when a system should be independent of how its products are created, composed, and represented; – when the classes to instantiate are specified at run-time, for example, by dynamic loading; or – to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or – when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state. Satya Puvvada

PROTOTYPE Structure client prototype Prototype Operation() Clone() p = prototype ->Clone() Concrete. Prototype 1 Concrete. Prototype 2 Clone() return copy of self Satya Puvvada return copy of self

Participants and Collaborations Participants: ¨ Prototype (Graphic) – Declares an interface for cloning itself ¨ Concrete. Prototype (Staff, Whole. Note, Half. Note) – Implements an interface for cloning itself ¨ Client (Graphic. Tool) – Creates a new object by asking a prototype to clone itself Collaborations: ¨ A client asks a prototype to clone Itself. Satya Puvvada

Mediator - Synopsis ¨ The mediator design pattern creates a class to mediate between a group of colleague objects ¨ The mediator handles all interaction between colleague objects ¨ All related colleague objects have the same mediator Satya Puvvada

Mediator Concrete. Mediator Colleague Concrete. Colleague 1 Satya Puvvada Concrete. Colleague 2

Context • Allows organization of relationships and interactions between objects • Used where complex protocols must be managed • Used when centralized access points are needed • Keeps objects in a group from referring to each other explicitly Satya Puvvada

Context ¨ Example: Chat room – Has multiple users – User joins chat room – Users send messages to other users – Users receive messages from other users Satya Puvvada

Forces ¨ It’s a complex task to manage communication between users • If user clients communicated directly, each client would need to understand every other type of client • Each client needs to know about every other client to send their messages ¨ Inherent coupling of objects that need to communicate Satya Puvvada

Solution ¨ Mediator • All users (colleagues) communicate with a common mediator • User logs in, mediator is notified • Message I/O – User sends messages to mediator – Mediator sends message to all user clients (colleagues) Satya Puvvada

Consequences ¨ Pros – Less chance of miscommunication – No need to “poll” for new colleagues – Promotes reusability ¨ Cons – Waste of effort for few colleagues – Mediator can become bloated Satya Puvvada

Consequences • Limits sub classing • Decouples colleagues • Simplifies object protocols • Makes object cooperation abstract • Centralizes control Satya Puvvada

Related Patterns ¨ Observer – Mediator class can be implemented using an observer ¨ Adapter – If mediator was allowed to change the data it’s mediating, it would be an adapter ¨ Façade – Similar – Façade only has one-way communication to its colleagues Satya Puvvada

Case Study Satya Puvvada

Designing a file system Satya Puvvada

Conclusions Satya Puvvada

Motivation for Design Patterns ¨ Most software systems contain certain common aspects that are frequently reinvented for each system ¨ Solutions to these common problems may vary in quality from system to system ¨ Design patterns seeks to communicate these classic solutions in an easy to understand manner Satya Puvvada

What are Design Patterns? ¨ Design Patterns communicate solutions to common programming problems ¨ The seminal book on design patterns, Design Patterns, Elements of Reusable Object-Oriented Software by Gamma et al, identifies three categories of design patterns – Creational – Structural – Behavioral Satya Puvvada

Creational Patterns ¨ Abstract factory – Facilitates the creation of related objects without concrete class reference ¨ Builder – If a class supports a number of different data representations, the builder encapsulates the details of the necessary conversions ¨ Factory method – Defers determination of specific class to create to a subclass Satya Puvvada

More Creational Patterns ¨ Prototype – Embodies information comprising prototypical instances ¨ Singleton – Ensures that the class has at most one instance and that other classes have global access to it Satya Puvvada

Structural Patterns ¨ Adapter – Translates between interacting objects for which the method signatures are incompatible ¨ Bridge – Creates a more flexible mechanism for multiple implementations of an abstract class than inheritance ¨ Composite – Facilitates a generic hierarchical grouping of objects where the class and number of objects may change ¨ Decorator – Allows dynamic addition of new behavior to objects by acting as an outer wrapper containing the added features Satya Puvvada

More Structural Patterns ¨ Facade – Provides a front end for a series of classes so that users of these classes only need to know of and use the standard set of methods implemented by the facade ¨ Flyweight – Describes a strategy for using an otherwise prohibitive number of very small-scale objects with minimal overhead ¨ Proxy – A means by which the instantiation of certain classes may be delayed until the proxied object is needed Satya Puvvada

Behavioral Patterns ¨ Chain of responsibility – A strategy that sets up a series of objects that may respond to a message depending on the context of the request ¨ Command – Allows methods to be encapsulated in objects and invoked by a standard means as determined by the interface of the common class ¨ Interpreter – If a set of problems are conducive to being represented as a simple grammar, a class may be defined for each rule Satya Puvvada

More Behavioral Patterns ¨ Iterator – Separates the class elements necessary for access and traversal from the aggregating class and encapsulates them in the iterator ¨ Mediator – Helps to avoid highly coupled class definitions by moving explicit object references to an intermediary object ¨ Memento – A means to store the otherwise encapsulated internal state of an object for the purpose of creating a checkpoint or undoing transactions Satya Puvvada

More Behavioral Patterns ¨ Observer – Allows multiple dependent instances of a class to be notified of relevant changes to the observed class ¨ State – A class hierarchy is defined around a set of states for an object, allowing the behavior of an object to vary depending on a state by substituting the state-specific subclass in its composition ¨ Strategy – Selects a set of related algorithms and encapsulates them in such a way that they may be interchangeable for solving certain problems Satya Puvvada

More Behavioral Patterns ¨ Template method – Structures a method in such a way that elements of the algorithm are deferred to subclasses ¨ Visitor – Allows the introduction of new operations on the objects that comprise the visited object Satya Puvvada

Conclusions n n n Individual Patterns are deceptively simple. Composition of different patterns can be very complex. Teams may suffer from pattern overload. Patterns are validated by experience and discussion rather than by automated testing. Integrating patterns into a software development process is a human intensive activity. Satya Puvvada

References ¨ Books – Design Patterns (Erich Gamma et al. ) – Design Patterns for OO Software Development (Wolfgang Pree) – Object Models: Strategies, Patterns and Applications (Peter Coad et al. ) – Pattern Languages of Program Design (James O. Coplien et al. eds. ) – Pattern Languages of Program Design 2 (John M. Vlissides et al. eds. ) – Pattern Languages of Program Design 3 (Robert C. Martin, Dirk Riehle, Frank Buschmann eds. ) – Pattern Languages of Program Design 4 (Brian Foote, Neil Harrison, Hans Rohnert eds. ) – Patterns of Software (Richard P. Gabriel) – Pattern-Oriented Software Architecture (F. Buschmann et al. ) Satya Puvvada

References ¨ Patterns on the web • • • Patterns Home Page: http: //hillside. net/patterns http: //st-www. cs. uiuc. edu/users/patterns. html http: //www. entract. com/~bradapp/docs/patterns-intro. html Wiki Web Portland Pattern Repository (Ward Cunningham) Anti. Patterns (Keith. Derrick) Best Pattern Threads History of Patterns People. Index (Ward Cunningham) Project. Index (Ward Cunningham) Satya Puvvada

Conclusions – Introduction to Design patterns – UML Notation – 20 patterns from the various categories discussed – Case study – All the best !!!!! Satya Puvvada