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

DESIGN PATTERNS
Redesigning Applications
And
Design Patterns in Object Oriented Designs.
Presented by
Anita Patankar
Keith Wright
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
Design Patterns
For
Design dé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.
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.
Classification of Patterns
Scope
Purpose
Creational
(Object creation)
Structural
(Classes &
Object
Composition)
Behavioural
Static
(Ways in which
classes/ objects
interact)
(Applies
to class)
Dynamic
(Applies to
object)
Classification of Design Patterns
Purpose
Creational
Scope
Structural
Behavioral
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
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.
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.
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
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 objectsReceiving object and delegate object.
Window
Area()
Return Rectangle->area()
Rectangle
Width, Height
Area()
Eg of Design Pattern:Strategy
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.
3. 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.
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.
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 applicationspecific 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.
Problem:
Document
Open()
Close()
Save()
Application
CreateDocument()
NewDocument()
OpenDocument()
MyDocument
Document
Open()
Close()
Save()
Drawing
Document
Open()
Close()
Save()
Solution Without Using
Pattern:
Application
CreateDocument()
NewDocument()
OpenDocument()
Drawing
Application
CreateDocument()
NewDocument()
OpenDocument()
Problem:
Document
Open()
Close()
Save()
Application
CreateDocument()
NewDocument()
OpenDocument()
MyDocument
Document
Open()
Close()
Save()
MyDocument
Solution Using
a Pattern:
Application
CreateDocument()
NewDocument()
OpenDocument()
MyApplication
CreateDocument()
Document*doc=CreateDocument();
docs.Add(doc);
doc->open()
return new MyDocument
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.
Points for discussion
1. What are the conditions/ circumstances to use patterns?
2. How do patterns relate to design requirements
3. Are patterns same as components?
4. How design Patterns are created?
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.
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