DESIGN PATTERNS Redesigning Applications And Design Patterns in Object Oriented Designs.

1. DESIGN PATTERNS Redesigning Applications And Design Patterns in Object Oriented Designs. Presented by Anita PatankarKeith Wright

2. Design Patterns • What are Design Patterns? • Overview of Design Patterns • Design Problems and Use of Patterns • Causes of Redesign and Use of Patterns • Factory Method Pattern • Illustration

3. Design Patterns For Designdéjàvu What is a Design Pattern? “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” says Christopher Alexander.

4. Overview • These are the design solutions in the form of classes, objects and interfaces. • Patterns are descriptions of communicating objects and classes that are customized to solve a particular object oriented design problem. • It is a way to record good experience in object oriented design • Using patterns also helps in documentation and maintenance as it gives explicit classification of classes and objects • It can also be said that design pattern of one person can be a building block of the design of other person.

5. Classification of Patterns Scope Purpose Creational Structural Behavioural Static Dynamic (Applies to object) (Classes & Object Composition) (Ways in which classes/ objects interact) (Applies to class) (Object creation)

6. Classification of Design Patterns

7. Design Problems and Use of Patterns 1. Finding Appropriate Objects: -Decomposing a system into OBJECTS due to factors such as: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability etc.. - Design methodologies help create classes that often lack the abstraction. Design Patterns help to identify less obvious abstractions and objects to capture them.Eg: State Pattern – Represents each state of entity as object. 2. Determining Object Granularity: - Objects vary in size and number, representing everything form hardware to the entire application. - How do we decide what should be an object. Design patterns help to identify objects and their structure.Eg: Façade Pattern shows how to represent complete subsystems as objects.

8. 3. Specifying Object Interfaces:- Signature is the method declaration with its name, parameters and return data type.- Interface or type defines a set of signatures defined by an object’s operations and object is known through these interfaces Design Patterns help to define interfaces, to identify their key elements and how the data is sent across an interface. Eg: Momento Pattern – Encapsulates internal state of object so that object can be restored to that state. 4. Specifying Object Implementations:- The class defines the object’s internal data, data representations and the operations the object can perform- Object is an instance of a class so the storage allocates memory for internal data. Design Patterns like Abstract Factory, Builder etc facilitate Abstraction, object Creation and Interface Association.

9. 5. Class Vs Interface Inheritance:- An objects class defines its implementation, internal state and operations in contrast to its type which only refers to its interfaces (set of requests it can respond to). - Class inheritance defines an object's implementation in terms of another object's implementation while interface inheritance describes when an object can be used in place of another. Many design Patterns depend on this distinction. Eg: COMPOSITE pattern: Defines a common type (interface) with class implementation.Whereas COMMAND, OBSERVER, STATE, STRATEGY patterns: Implemented using abstract classes with pure interfaces 6. Programming to an interface not an implementation:- Clients know only the interfaces and the abstract classes but are unaware of the other classes.Design Patterns ensure that system is in terms of interfaces and not implementation. Eg: Abstract Factory: helps to instantiate by abstraction of object creation

10. 7. Putting reuse mechanisms to work:- WHITE-BOX reuse: refers to visibility when implementing one class in terms of another using inheritance where the internals of the parent class are visible. • BLACK-BOX reuse: refers to composition (assembling objects with well defined interfaces) to get added functionality while the hiding the internal details of the objects.- Object composition is dynamic and has fewer implementation dependencies.- Composition keeps classes encapsulated and task oriented, focusing on interfaces and relationships and thus reduce the hierarchy levels. • 8. Delegation:Makes Composition as reusable as inheritance by involving 2 objects- Receiving object and delegate object. RectangleWidth, HeightArea() WindowArea() Eg of Design Pattern:Strategy Return Rectangle->area()

11. Causes of Redesign and Use of Patterns • 1. Creating an object by specifying a class explicitly: Commits you to an implementation instead of an interface. • Solution: its better to create objects directly. • - Design patterns: Abstract Factory, Factory Method, Prototype. • 2. Dependence on specific operations: Specifying an operation commits you to only one way of satisfying a request. • Solution: Avoid hardcoded requests and make it easy to change the way request gets satisfied at compile time and run time. • - Design patterns: Chain Of Responsibility, Command. • Dependence on hardware and software platform: Operating systems and API's differ between platforms and software depending on a specific system needs to consider this aspect while redesigning. • Solution: Design the system to limit its platform dependencies. • - Design patterns: Abstract Factory, Bridge. • 4. Dependence on object representations or implementations: Clients knowing how objects are represented will probably need modification if the object changes. Solution: Hide information from clients. • - Design patterns: Abstract Factory, Bridge, Memento, Proxy.

12. Causes of Redesign and Use of Patterns (cont.):: 5. Algorithmic dependencies: Algorithms change and objects that are made dependent on the algorithms will require change. Solutions: Isolate the algorithms that are likely to change.- Design patterns: Builder, Iterator, Strategy, Template Method, Visitor. 6. Tight coupling: Classes tightly coupled are hard to reuse in isolation due to dependence. Solution: Loosely coupled systems.- Design patterns: Abstract Factory, Bridge, Chain Of Responsibility, Command, Façade, Mediator, Observer. 7. Extending functionality by subclassing:Subclassing requires in-depth understanding of parent classes and overriding operations may require an unmanageable number of subclasses. Solution: Using composition.- Design patterns: Bridge, Chain Of Responsibility, Composite, Decorator, Observer, Strategy. 8. Inability to alter classes conveniently: Altering classes may affect many subclasses or may be difficult if the source code is lost.- Design patterns: Adapter, Decorator, Visitor.

13. Illustration using Factoy Method Pattern • Factory Method: (Also known as visual constructor) • - In this method, an interface for creating an object, is defined and the subclasses decide which class to instantiate. • Thus factory method lets the class defer instantiation to subclasses. • Frameworks: Use abstract classes to define and maintain relationships between objects. They are also responsible for creating these objects. • Example: Framework for applications that can present multiple documents to the user. • 2 key abstractions for this framework are 2 classes: Application Class- Responsible for managing and creating documents Document Class-useful To manage a specific document • Both are abstract so the clients need to subclass them for their application-specific implementation.To Create a Drawing Application for example: We need 2 subclasses DrawingApplication DrawingDocumentProblems: - When a subclass of document (which is application specific), when created, Application class can not know what it contains or can not relate to it.- Framework has to instantiate classes but has only abstract classes which can not be instantiated.

14. Problem: ApplicationCreateDocument()NewDocument() OpenDocument() DocumentOpen()Close() Save() MyDocument DocumentOpen()Close() Save() ApplicationCreateDocument()NewDocument() OpenDocument() DrawingDocumentOpen()Close() Save() DrawingApplicationCreateDocument()NewDocument() OpenDocument() Solution Without Using Pattern:

15. Problem: ApplicationCreateDocument()NewDocument() OpenDocument() DocumentOpen()Close() Save() MyDocument ApplicationCreateDocument()NewDocument() OpenDocument() Document*doc=CreateDocument();docs.Add(doc);doc->open() DocumentOpen()Close() Save() MyApplicationCreateDocument() MyDocument return new MyDocument Solution Using a Pattern:

16. How factory method helps to solve the problem • Factory Method encapsulates the knowledge of which document subclass to create and moves the knowledge of it, out of framework. • Application subclasses redefine an abstract CreateDocument operation on application and returns appropriate document subclass. • Once an application specific class is instantiated, it can instantiate application specific documents without knowing the class. • CreateDocument() method is called Factory method as it manufactures the object of Subclass of document. • It also illustrates the principle of delegation, already discussed. • - This method is used when a class can’t anticipate the class of object, it must create and wants a subclass to specify objects it creates.

17. Points for discussion • What are the conditions/ circumstances to use patterns? • How do patterns relate to design requirements • Are patterns same as components? • How design Patterns are created?

18. How to select a design pattern • Consider how design pattern solves a problem. • Scan intent sections from all patterns • Study how patterns interrelate • Study patterns of like purpose • Examine cause of redesign and look for a suitable pattern • Consider what should be variable in design. ( that can be changed without redesign)- Define a variable for encapsulation.

19. How to use a design pattern • Read the pattern for an overview • Study the structure, participants and collaborations • See the sample code in the examples • Choose names for pattern participants that are meaningful in application. • Define classes, interfaces and their relationships • Define operations in the system • Implementation of the pattern