Design Patterns #1 Reid Holmes Lecture 11 - Tuesday October 19 - - PowerPoint PPT Presentation

▶
design patterns 1
SMART_READER_LITE
LIVE PREVIEW

Design Patterns #1 Reid Holmes Lecture 11 - Tuesday October 19 - - PowerPoint PPT Presentation

Feb 19, 2024 333 likes •601 views

Material and some slide content from: - GoF Design Patterns Book Design Patterns #1 Reid Holmes Lecture 11 - Tuesday October 19 2010. GoF design patterns !"#$%&'()*$+,--&.*' /.&,-("*,0 1-.23-2.,0 4&5,6(".,0

slide-1
SLIDE 1

Lecture 11 - Tuesday October 19 2010. Material and some slide content from:

  • GoF Design Patterns Book

Design Patterns #1

Reid Holmes

slide-2
SLIDE 2

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

GoF design patterns

!"#$%&'()*$+,--&.*' /.&,-("*,0 1-.23-2.,0 4&5,6(".,0

#,3-".7$8&-5"9 :;'-.,3-$#,3-".7 42(09&. +."-"-7<&

1(*)0&-"*

:9,<-".$=$30,'' 4.(9)& /"><"'(-& %&3".,-".

#,3,9&

:9,<-".=";?&3-

#07@&()5- +."A7

B*-&.<.&-&. /5,(*$"C$.&'<"*'(;(0(-7 /">>,*9 B-&.,-".

8&9(,-".

D&><0,-&$8&-5"9

8&>&*-" E;'&.6&. 1-,-& 1-.,-&)7 F('(-". 30,'' ";?&3-

slide-3
SLIDE 3

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Singleton

  • Intent: “Ensure a class has only one instance”
  • Motivation: ?
  • Applicability:
  • Situations when there must be only one copy of

a class.

slide-4
SLIDE 4

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Singleton

  • Structure:
  • Participants:
  • an instance operation that retrieves the instance.
  • may be responsible for creating instance.
slide-5
SLIDE 5

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Singleton

  • Collaborations
  • All collaboration via instance operation.
  • Consequences:
  • Controlled access to instance.
  • Reduced name space.
  • Permits variable number of instances.
  • More flexible than class operations.
slide-6
SLIDE 6

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Singleton

  • Implementation:

1.? 2.?

  • Related to:
  • Can be used to create Abstract Factory, Builder,

and Prototype.

slide-7
SLIDE 7

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Abstract factory

  • Intent: “Provide an interface for creating families of

related objects without specifying their concrete classes”

  • Motivation: Consider a multi-platform UI toolkit. A

WidgetFactory can provide an interface to make sure the right widget is instantiated for each platform.

  • Applicability:
  • When a system should be independent of how its

products are created and represented.

  • A system contains multiple families of products.
  • ?
slide-8
SLIDE 8

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Abstract factory

  • Structure
  • Participants:
  • Abstract/Concrete Factory
  • Abstract/Concrete Product
  • Client
slide-9
SLIDE 9

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Abstract factory

  • Collaborations
  • Usually only one Abstract Factory (singleton).
  • Objects are created by concrete factories.
  • Consequences:
  • Isolates concrete classes from clients.
  • ?
  • Makes exchanging families easy.
  • ?
  • Makes adding products hard.
  • ?
slide-10
SLIDE 10

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Abstract factory

  • Implementation:
  • Create abstract factory interface.
  • Use factory method to create descriptive names.
  • Create concrete products/factories.
  • ?
  • Known uses: Frequently used in widget toolkits.
  • Related to: Often implemented with Factory Method
  • r Prototypes. Concrete factories are often

Singletons.

slide-11
SLIDE 11

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Builder

  • Intent: “Separate the construction of complex
  • bjects from its representation.”
  • Motivation: Consider a text reader that must

convert back and forth between RTF , ASCII, and

  • TeX. The ordering / combinations are unbounded

requiring a flexible composition mechanism.

  • Applicability:
  • ?
  • When the construction process must allow for

different representation.

slide-12
SLIDE 12

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Builder

  • Structure
  • Participants:
  • Builder / Concrete Builder
  • Director
  • Product
slide-13
SLIDE 13

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Builder

  • Collaborations:
  • Client creates director with desired builder.
  • Director tells builder to build parts.
  • Client retrieves parts from builder.
  • Consequences:
  • Vary internal representation.
  • Isolates code from construction / representation.
  • ?
slide-14
SLIDE 14

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Builder

  • Implementation:
  • 1) Create flexible construction interface. Allow

new parts to be appended to the existing whole.

  • 2) Don’t bother with abstract products, they

usually vary enough that it doesn’t help much.

  • 3) Don’t use interface for Builder; empty

methods allow ConcreteBuilders to choose what methods to implement.

  • Known uses: Smalltalk parser & ClassBuilder.
  • Related to: Similar to Abstract Factory. Frequently

builds Composite objects.

slide-15
SLIDE 15

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Builder Example

slide-16
SLIDE 16

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Proxy

  • Intent: “Provide a placeholder to control access to

another object.”

  • Motivation: One reason to control access is cost:

consider an object that is expensive to populate entirely but cheap to partially populate. (e.g., remote object, large file from disk, etc.)

  • Applicability: (When a more versatile reference is needed.)
  • Remote: ?
  • Virtual: ?
  • Protection: Protect access to objects.
  • Smart reference: Performs additional actions.
slide-17
SLIDE 17

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Proxy

  • Structure
  • Participants:
  • Proxy
  • Subject / RealSubject
slide-18
SLIDE 18

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Proxy

  • Collaborations:
  • Client interacts with proxy.
  • Proxy forwards req. to RealSubject as required.
  • Consequences:
  • Remote: ?
  • Virtual: ?
  • Protection: Housekeeping / auth can occur.
slide-19
SLIDE 19

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Proxy

  • Implementation:
  • 1) Create common interface for Proxy/

RealSubject.

  • 2) Reference Proxy in Client.
  • 3) Proxy forwards requests as necessary.
  • Known uses: Image manipulation / RPC.
  • Related to: Similar to Adapter and Decorator.

Decorators add responsibilities while proxies serve as mediators.

slide-20
SLIDE 20

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Proxy wrt Project

slide-21
SLIDE 21

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Facade

  • Intent: “Provide a unified, higher-level, interface to

a whole module making it easier to use.”

  • Motivation: ?
  • Applicability:
  • When you want a simple interface to a complex

subsystem.

  • ?
  • You want to layer your subsystems.
slide-22
SLIDE 22

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Facade

slide-23
SLIDE 23

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Facade

  • Participants:
  • Facade
  • Subsystem classes
  • Collaborations:
  • Clients interact subsystem via Facade.
  • Consequences:
  • ?
  • Promotes ?
  • Doesn’t prevent access to subsystem classes.
slide-24
SLIDE 24

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Facade

  • Implementation:
  • 1) Analyze client / subsystem tangling.
  • 2) Create interface. Abstract factories can also

be used to add further decoupling.

  • Known uses: Varied.
  • Related to: Abstract Factory can be used with

Facade to create subsystem objects. Facades are frequently Singletons. Abstracts functionality similar to Mediator but does not concentrate on communication.

slide-25
SLIDE 25

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Facade wrt Project

slide-26
SLIDE 26

REID HOLMES - SE2: SOFTWARE DESIGN & ARCHITECTURE

Activity

  • 5 mins:
  • Right side: Develop a use for a facade pattern

for your system.

  • Left side: Develop a usage of a proxy pattern for

your system.

  • 10 mins (5 / group):
  • Match up with team from other side of room.

Explain your pattern and how it improves your system’s design.