2 Design Patterns
Transcript of 2 Design Patterns
-
7/31/2019 2 Design Patterns
1/24
Design Patterns
1
-
7/31/2019 2 Design Patterns
2/24
Design Patterns
Design patterns are solutions to problems thatarise when developing software within a
particular context
Patterns capture the static and dynamicstructure and collaboration among key
participants in software designs
Patterns facilitate reuse of successful softwarearchitectures and designs
2
-
7/31/2019 2 Design Patterns
3/24
Design Pattern Descriptions
Name and intent
Problem and context What is the problem and the context where we would use this
pattern?
Under what specific conditions should this pattern be used?
Solution A description of the elements that make up the design pattern
Emphasizes their relationships, responsibilities, andcollaborations
Not a concrete design or implementation; rather an abstract
description Positive and negative consequences of use
The pros and cons of using the pattern
Includes impacts on reusability, portability, and extensibility
3
-
7/31/2019 2 Design Patterns
4/24
Organizing Patterns
Purpose: What a pattern does Creational: creating, initializing and configuring classes and
objects
Structural patterns: composition of classes and objects
Behavioral patterns: dynamic interactions among classes
and objects Scope: what the pattern applies to
Class patterns: Focus on the relationships between classes and their subclasses
Involve inheritance reuse
Object patterns: Focus on relationships between objects
Involve composition reuse
4
-
7/31/2019 2 Design Patterns
5/24
A Pattern Must
Solve a problem
I.e., it must be useful
Have a context
It must describe wherethe solution can be used
Recur
It must be relevant in
other situations
Teach
It must provide sufficient
understanding to tailor
the solution
Have a name
It must be referred to
consistently
5
-
7/31/2019 2 Design Patterns
6/24
Patterns and Language
Most design patterns focus on OO Assume inheritance, polymorphism,
encapsulation, etc.
In procedural languages, might add OOfeatures as patterns
Some languages provide or make it easier to
implement some patterns Covering generic OO patterns not
concurrency, domain specific, UI, etc.
6
-
7/31/2019 2 Design Patterns
7/24
Abstract Factory
7
-
7/31/2019 2 Design Patterns
8/24
Abstract Factory
Use the Abstract Factory pattern when a system should be independent of how its products
are created, composed, and represented.
a system should be configured with one of multiple
families of products.
a family of related product objects is designed to be
used together, and you need to enforce this
constraint.
you want to provide a class library of products, and
you want to reveal just their interfaces, not their
implementations.
8
-
7/31/2019 2 Design Patterns
9/24
Abstract Factory
AbstractFactory (WidgetFactory)
declares an interface for operations that create abstract productobjects.
ConcreteFactory (MacintoshWidgetFactory, LinuxWidgetFactory)
implements the operations to create concrete product objects.
AbstractProduct (Window, ScrollBar)
declares an interface for a type of product object.
ConcreteProduct (MacintoshWindow, MacintoshScrollBar)
defines a product object to be created by the corresponding concretefactory.
implements the AbstractProduct interface.
Client uses only interfaces declared by AbstractFactory and AbstractProduct
classes.
9
-
7/31/2019 2 Design Patterns
10/24
Factory Method
10
-
7/31/2019 2 Design Patterns
11/24
Factory Method
Use the Factory Method pattern when a class can't anticipate the class of objects it must
create.
a class wants its subclasses to specify the objects
it creates.
classes delegate responsibility to one of several
helper subclasses, and you want to localize the
knowledge of which helper subclass is thedelegate.
11
-
7/31/2019 2 Design Patterns
12/24
Factory Method
Participants Product (Document)
defines the interface of objects the factory method creates.
ConcreteProduct (MyDocument) implements the Product interface.
Creator (Application) declares the factory method, which returns an object of type
Product. Creator may also define a default implementationof the factory method that returns a defaultConcreteProduct object.
may call the factory method to create a Product object. ConcreteCreator (MyApplication)
overrides the factory method to return an instance of aConcreteProduct.
12
-
7/31/2019 2 Design Patterns
13/24
Singleton
13
-
7/31/2019 2 Design Patterns
14/24
Singleton
Use the Singleton pattern when there must be exactly one instance of a class, and
it must be accessible to clients from a well-known
access point.
when the sole instance should be extensible by
subclassing, and clients should be able to use an
extended instance without modifying their code.
14
-
7/31/2019 2 Design Patterns
15/24
Adapter
As a software developer, you write classeswhose methods are called by clients, i.e.implement predefined interfaces
When you need to implement an expected
interface, you may find that an existing classperforms the services a client needs but withdifferent method names.
The intent of ADAPTER is to provide theinterface a client expects, using the services ofa class with a different interface
15
-
7/31/2019 2 Design Patterns
16/24
Adapter
16
-
7/31/2019 2 Design Patterns
17/24
Decorator
17
-
7/31/2019 2 Design Patterns
18/24
Decorator
Use Decorator to add responsibilities to individual objects
dynamically and transparently, that is, without
affecting other objects.
for responsibilities that can be withdrawn.
when extension by subclassing is impractical.
18
-
7/31/2019 2 Design Patterns
19/24
Decorator
Participants Component (VisualComponent)
defines the interface for objects that can haveresponsibilities added to them dynamically.
ConcreteComponent (TextView)
defines an object to which additional responsibilities can beattached.
Decorator maintains a reference to a Component object and defines an
interface that conforms to Component's interface.
ConcreteDecorator (BorderDecorator,ScrollDecorator) adds responsibilities to the component.
19
-
7/31/2019 2 Design Patterns
20/24
Facade
Toolkit vs. application
A facade is a class with a level of functionality
that lies between a toolkit and a complete
application The intent of the facade pattern is to provide
an interface that makes a subsystem easy to
use
20
-
7/31/2019 2 Design Patterns
21/24
Observer
21
-
7/31/2019 2 Design Patterns
22/24
Observer
Use the Observer pattern in any of thefollowing situations:
When a change to one object requires changing
others, and you don't know how many objects
need to be changed.
When an object should be able to notify other
objects without making assumptions about who
these objects are. In other words, you don't wantthese objects tightly coupled.
22
-
7/31/2019 2 Design Patterns
23/24
Observer
Participants
Subject knows its observers. Any number of Observer objects may observe a
subject.
provides an interface for attaching and detaching Observer objects.
Observer
defines an updating interface for objects that should be notified ofchanges in a subject.
ConcreteSubject stores state of interest to ConcreteObserver objects.
sends a notification to its observers when its state changes.
ConcreteObserver maintains a reference to a ConcreteSubject object.
stores state that should stay consistent with the subject's.
implements the Observer updating interface to keep its stateconsistent with the subject's.
23
-
7/31/2019 2 Design Patterns
24/24
24