2 Design Patterns

7/31/2019 2 Design Patterns

1/24

Design Patterns

1


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


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


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


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


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/24

Abstract Factory

7


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


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


10/24

Factory Method

10


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


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


13/24

Singleton

13


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


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


16/24

Adapter

16


17/24

Decorator

17


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


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


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


21/24

Observer

21


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


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


24/24

24

Documents

2 Design Patterns