Lecture Slides on Patterns for Decoupling | CSE 218, Study notes of Software Engineering

Download Lecture Slides on Patterns for Decoupling | CSE 218 and more Study notes Software Engineering in PDF only on Docsity!

California Institute for Telecommunications

and Information TechnologiesLa Jolla, CA 92093-0405, USA

Department of Computer Science & Engineering

University of California, San Diego

La Jolla, CA 92093-0114, USA

Patterns for Decoupling

Ingolf H. Krueger

[email protected]

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Overview

•^

Recap: Patterns for Architecture and Design

-^

Adapter

-^

Decorator

-^

Proxy

-^

Observer

-^

Model-View-Controller

-^

Recursive Control

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

What are Patterns?

A pattern for software architecture

describes a

particular recurring design problem that arises in

specific design contexts, and presents a well-proven

generic scheme for its solution. The solution scheme isspecified by describing its constituent components, theirresponsibilities and relationships, and the ways in which

they collaborate.

[POSA96]

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

What are Patterns?

adapted from [POSA96]

Pattern

Architectural Pattern

Design Pattern

Idiom

-^

Describes

one proven solution for a recurrent

design problem

-^

Defines the context for the solution’sapplicability

granularity

coarse

fine

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Design Patterns for Decoupling and Distribution

Key steps during the design of components and theirinterfaces:

• Decoupling of strongly interdependent components – Distribution of functions/data to other components

⇒

Application of design patterns

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Overview

•^

Recap: Patterns for Architecture and Design

-^

Adapter

-^

Decorator

-^

Proxy

-^

Observer

-^

Model-View-Controller

-^

Recursive Control

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Adapter

•^

Context & Problem

• A given component (

target) offers the desired functionality

• The target's environment expects a different interface -^

Solution:

• Define an adapter component that offers the required

interface

• Associate the environment with the adapter instead of with

the target

• Let the adapter relay calls from the environment to the

target; adjust the relayed calls towards the interface of thetarget

• Let the adapter provide functions missing in the target

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Adapter

•^

Structure:

«interface»^ Adapter DesiredInterface

Service() Service()

TargetComponent

TargetService()target

Environment

1

Service() {return target.TargetService();}

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Adapter

•^

Behavior:

:TargetComponent

:Adapter

:Environment

Service()

TargetService()

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Adapter

•^

Consequences:

• Enables reuse of target in different context – Extension of functionality via the adapter potentially reduces the

design’s transparency

• If target becomes subcomponent of adapter: adjusting of all

clients of target required to accommodate the adapter's interface

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Overview

•^

Recap: Patterns for Architecture and Design

-^

Adapter

-^

Decorator

-^

Proxy

-^

Observer

-^

Model-View-Controller

-^

Recursive Control

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Decorator

•^

Context & Problem

• Modification of a target component’s

behavior is required

• The component’s

interface has to remain unchanged

•^

Solution:

• Define a decorator component that has the target’s interface – Store a reference to the target in the decorator – Let the decorator relay calls to the target – Let the decorator adjust the result obtained from the target to

match the required modifications, and relay the adjusted resultto the original caller

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Decorator

•^

Structure:

«interface» ComponentInterface^ Service()

Environment

Decorator^ Service()

Component

Service()

Decorator A

Service()

Decorator Z

Service()

component ...

Service(){

component.Service();...additional behavior... }

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Decorator

•^

Behavior:

:Decorator B

:Decorator A

:Environment

Service()

Service()

:Component

Service()

additionalBehavior()

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Decorator

•^

Consequences:

• Flexible addition to/modification of component behavior – Alternative to overloaded class hierarchies – Communication overhead

(potential performance loss)

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Overview

•^

Recap: Patterns for Architecture and Design

-^

Adapter

-^

Decorator

-^

Proxy

-^

Observer

-^

Model-View-Controller

-^

Recursive Control

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Proxy

•^

Context & Problem

• Access to target component from several other components

required

• Direct access to the target is impossible due to security,

efficiency, or distribution requirements

•^

Solution:

• Define a placeholder (a proxy) that offers the same interface as

the target component

• Make only the proxy known to the environment – Let the proxy access the target, observing security, efficiency

and distribution requirements

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Proxy

•^

Structure:

«interface»^ ServiceInterface^ Service()

Environment

ServiceProvider

Service()

ServiceProxy

Service()

target

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Proxy

•^

Behavior:

:ServiceProvider

:ServiceProxy

:Environment

Service()

Service() pre() post()

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Proxy

•^

Consequences:

• Decoupling of service provider and service users – Location of service provider is transparent to service users
  • Proxy handles communication with service provider • Applicable for decoupling of address spaces
    • Increased communications overhead can reduce performance

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Overview

•^

Recap: Patterns for Architecture and Design

-^

Adapter

-^

Decorator

-^

Proxy

-^

Observer

-^

Model-View-Controller

-^

Recursive Control

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Observer

•^

Context & Problem

• Several components depend on a target component’s state – All dependent components shall be informed about state

changes of the target

• Loose coupling between dependent and target component

target required

•^

Solution:

• Let all dependent components attach/register with the

source

• Let components no longer interested in the target’s state

changes detach/unregister from the target

• In the event of a state change let the target send a

notification message to all registered components

• Let the registered components inquire about the new state

after they have been notified

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Observer

•^

Structure:

Source AbstractSource^ Attach(Observer)Detach(Observer)

Notify()^ stateGetState()SetState()

Observer AbstractObserver

Update() Update()

observers

1 subject

for all o in observers {o.Update();}

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Observer

•^

Behavior:

o2:Observer

o1:Observer

:Source

SetState()^ Update() GetState()

Update() GetState()

Notify()

© Ingolf H. Krueger

February 4, 2003

CSE/CAL·(IT)

2

Observer

•^

Consequences:

• Loose coupling between target and dependent components – Support for event-based systems (multithreading) – Design strategy for multicast-systems – Problematic: Containment of update frequency

Solution: apply multiple update strategies (strategy pattern)