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

2. 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 Design déjà vu What is a Design Pattern? For
“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
Purpose
Creational
Structural
Behavioral
Scope
Class
Factory Method
Adapter (class)
Interpreter
Template Method
Object
Abstract Factory
Builder
Prototype
Singleton
Adapter(Object)
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

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.
Rectangle Width, Height Area()
Window Area()
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 DrawingDocument Problems: - 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. Solution Without Using Pattern:
Problem:
Application CreateDocument() NewDocument()
OpenDocument()
Document Open() Close()
Save()
MyDocument
Document Open() Close()
Save()
Application CreateDocument() NewDocument()
OpenDocument()
Drawing Document Open() Close()
Save()
Drawing Application CreateDocument() NewDocument()
OpenDocument()
Solution Without Using Pattern:

15. Solution Using a Pattern:
Problem:
Application CreateDocument() NewDocument()
OpenDocument()
Document Open() Close()
Save()
MyDocument
Application CreateDocument() NewDocument()
OpenDocument()
Document*doc=CreateDocument(); docs.Add(doc); doc->open()
Document Open() Close()
Save()
MyApplication CreateDocument()
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