1

SOFTWARE SOFTWARE

DESIGN DESIGN

PATTERNSPATTERNS

“Descriptions of communicating objects and classes that are

customized to solve a general design problem”

-- Gamma, et. al.

2

The Pattern Name The Problem it solves The Solution it provides The Consequences (good and bad) of

using it

3

4

CHANGES…Patterns should be able to deal with changes.Changes can come from many different sources:

- New vendor

- New Technology

- New views

-New complexity of the application domain.

- Errors

There are 3 types of pattern …

Creational: address problems of creating an object in a flexible way. Separate creation, from operation/use.

Structural: address problems of using O-O constructs like inheritance to organize classes and objects

Behavioral: address problems of assigning responsibilities to classes. Suggest both static relationships and patterns of communication(use cases)

A modifiable design enables

• An iterative and incremental development cycle, which allows Concurrent (aka simultaneous)

development Risk management Flexibility to change

• The software developer to minimize the introduction of new problems when fixing old ones.

• The software developer to deliver more functionality after initial delivery. 6

Low coupling and high cohesion Clear dependencies between classes Explicit assumptions.

How do design patterns help? They are generalized from existing, i.e. proven,

systems.

They provide a shared vocabulary to designers.

They provide examples of modifiable designs.

They use, principally, Abstract classes Delegation & inheritance

7

8

Common architectural patterns

Façade Strategy

Proxy Abstract Factory

Bridge Command

Adapter Composite

9

Patterns Explained

SingletonFaçadeFactoryAdapterBridge

Name: SingletonProblem: How can we guarantee that one and only oneinstance of a class can be created?Context: In some applications it is importantto have exactly one instance of a class, e.g. sales

ofone company.

Forces: Can make an object globally accessible as aglobal variable, but this violates encapsulation.Could use class (static) operations and attributes, butpolymorphic redefinition is not always possible.

Solution:Create a class with a class operation getInstance().When class is first accessed, this creates relevantobject instance and returns object identity to client.On subsequent calls of getInstance(), no newinstance is created, but identity of existing object isreturned.

Singleton

-uniqueInstance-singletonData

+getInstance( )+getSingletonData( )+singletonOperation( )-Singleton( )

Object identifier for singletoninstance, class scope or static

Returns object identifier for unique instance, class-scopeor static

Private constructor only accessiblevia getInstance()

getInstance( ) {if ( uniqueInstance == null ) { uniqueInstance = new Singleton( ) }return uniqueInstance

}

Class Singleton {private static Singleton uniqueInstance = null;private Singleton( ) { .. } // private constructorpublic static Singleton getInstance( ) {

if (uniqueInstance == null)uniqueInstance = new

Singleton(); // call constructor

return uniqueInstance;}

}

Example: Code

To specify a class has only one instance, we make it inherit from Singleton.

+ controlled access to single object instance through Singleton encapsulation

+ Can tailor for any finite number of instances+ namespace not extended by global variables- access requires additional message passing- Pattern limits flexibility, significant redesign if

singleton class later gets many instances

15

A sculpture is singleton

Name: FaçadeProblem: How can we access a large number of classeswith a complex internal interaction in a simplebut safe way?Solution: Introduce a dedicated interface classthat simplifies the view of the class collection.

Provides a unified interface to a set of objects in a subsystem.

A façade defines a higher-level interface that makes the subsystem easier to use (i.e. it abstracts out all the “messy” details)

Façades allow us to provide a closed architecture.

17

Bad!

Good!

Facadesubsystem classes

19

Façade interface to client provides one (or few) method(s) that allows the client to invoke the subsystems services.

<<façade>>SecurityManager

+addAccessRight()+addActor()+addActorRole()+removeActor()

AccessRight

+addAccessRight()

Actor

+addActor()+removeActor()+changeSalary()

ActorRole

+addActorRole()

Method not in Facade

Pattern Name

21

Home Theatre system and compiler are examples of Façade implementation

22

Compiler

compile(s)

Parse Node

create()

Lexical Analysis

getToken()

Code Generator

create()

Parser

generateParseTree()

Optimizer

create()

Compiler

23

Example – Home TheaterLots of classesand interactions,plus many interfaces.

Clients communicate with the subsystem by sending requests to Façade which forwards them to the appropriate subsystem object(s).

Although subsystem objects perform actual work, Façade may have to translate its interface to subsystem interfaces.

Clients that use the Façade don’t have to access its subsystem objects directly.

Usually only one Façade object is required. Thus a Façade object is often a singleton.

Factory pattern can be used with Façade to provide an interface for creating subsystem objects in a subsystem independent way.

Factory can also be used as an alternative to Façade to hide platform-specific classes.

Mediator pattern is similar to Façade in abstracting functionality of classes.

Name: (Abstract) Factory

Problem: Provide an interface for creating

families of related or dependent objects without specifying their concrete classes. Control instantiation Singleton is a special case of Factory

whereonly one object can be created.

AbstractProduct

ConcreteProduct1

AbstractFactory

ConcreteFactory

FactoryMethod()AnOperation()

FactoryMethod()

Product =FactoryMethod()

return newConcreteProduct()

Normally, a single instance of a ConcreteFactory class is created at runtime.

This creates product objects having a particular implementation.

To create different product objects, clients should use a different concrete factory.

AbstractFactory defers creation of product objects to its ConcreteFactory subclasses.

MyClass

createObjectOfRequiredClass():RequiredClass

Factory design pattern

Client RequiredClass

Factory Class Model

create objects

E.g. create objects of different types

We can order a Car and get an Aston Martin, MG, Jaguar etc

We don’t know which factory builds the car, just that they implement CarFactory. Owner has created the actual factory instance.

// we have a reference to ownerCarFactory aFactory = owner.makefactory();Car myCar =aFactory.makeCar(“AstonMartin”);

class BritishFactory implements CarFactory{public Car makeCar(String b) throws Exception {

if(b.equals(“AstonMartin”)) return new AstonMartin();

else if (..) return ..;else throw new Exception(b + “doesn’t

exist”);}

}

Class AstonMartin extends Car {}

Class Jaguar extends Car {}

Interface CarFactory {

Public Car makeCar(String b) throws Exception;

}

33

Aston Martin Jaguar

Abstract Factory classes are often implemented with the Factory Method pattern.

Can also be implemented using the Prototype pattern.

A concrete factory is often a Singleton.

Comments

35

Pattern: Adapter

Suppose a client objects expect a certain interface to be provided by called object.

However, the interface of the called object differs from what the clients expect, and cannot be changed.

How may this situation be improved, i.e. how may the interface satisfy the clients?

36

Transforms the interface of the target class into another interface that the client classes expect.

Adapter lets classes work together that could not otherwise because of incompatible interfaces.

Used to provide a new interface to existing legacy (i.e. old) software components (aka interface engineering, re-engineering).

Adapter also known as a wrapper

37

38

Adapter Patten

Context:

1. Want to use an existing class without modifying it – call it the “legacy” class

2. But context in which you want to use the legacy class requires conformance to a target (i.e. new) interface that is different from that which the legacy provides.

3. However, the target interface and legacy interface are conceptually related.

Solution:

1. Define an adapter class that implements the target interface.2. The adapter class holds a reference (delegates) to the legacy

class. It translates (new) target requests (or method calls) from client classes to (old) legacy requests (or method calls).

39

Participants of the Adapter Pattern

• Target: Defines the application-specific interface that clients use.

• Client: Collaborates with objects conforming to the target interface.

• Legacy: Defines an existing interface that needs adapting.

• Adapter: Adapts the interface of the legacy class to the target interface.

Bind an Adapter class with the Legacy class

The Adapter class implements the ClientInterface expected by the client. It then delegates requests from the client to the Legacy class and performs any necessary conversion.

ClientInterface could be a Java/C# interface, or an abstract class

40

Client

TargetClientInterface

Request()

Legacy

ExistingRequest()

Adapter

Request()

Legacy class

delegationinheritance

41

Interface inheritance is use to specify the interface of the Adapter class – and then delegation is used to reference the Legacy class

Legacy classsupporting old

interface

Class supporting new interface

Inheritance

Delegation

42

Example

Turkeys do not quack, they gobble. Turkeys can fly but for only short distances.

How can we adapt the Turkey class to behave like a Duck class?

43

duck quack becomes turkey gobble

duck fly becomes fivetimes turkey fly

Adapt the Turkey class to have the same interface as Duck.i.e. have methods quack() and fly()

44

Pattern: Bridge

Client objects expect a constant interface to be provided by some called object.

However, the actual implementation of the interface may vary – there may be lots of different implementations, depending on the circumstances.

How may this situation be satisfied?

Use a Bridge pattern to decouple an abstraction from its implementation

so that both can vary independently.

Also known as “handle/body” pattern

Allows different implementations of an interface to be decided upon dynamically.

45

46

Problem- Want to decouple an abstraction (i.e. class interface) from its implementation, allowing them to vary separately.

Context- Want to change implementation details at run-time without impact to clients classes.

Solution- Use delegation from an interface class to an implementation class.

Consequences- Can change (or add) interface without re-implementing.- Can change implementation, but not impact interface for clients.

47

Inheritance

ImplementorAbstractionimplements

ImplementorA ImplementorB

Client

The Abstraction class defines the interface visible to client.

The Implementor class is an abstract implementation that defines the lower-level methods available to Abstraction – namely different “concrete” implementations such as ImplementorA or ImplementorB

Delegation

48

ExampleSupporting multiple Database Vendors with a Bridge

LeagueStoreImplementorLeagueStoreimplements

XML StoreImplementor

SQL Server StoreImplementor

JDBC StoreImplementor

Arena

LeagueStore is the interface class to the pattern

Abstract interfaceprovides common interface

The bridge pattern is used to provide multiple implementations under the same interface.

Decouples an interface from the implementation so that implementation can be substituted, possibly at runtime.

Example: Interface to a component that is incomplete, not yet known, or unavailable during testing

49

50

Consider problem of incrementally developing, testing and integrating subsystems realized by different project teams.

Subsystems may be completed at different times, delaying the integration of all subsystems until the last one has been completed.

To avoid delay, projects often use a stub implementations in place of a specific subsystem so that the integration tests can start even before the subsystems are completed.

51

Example of the bridge pattern

Similarities: Both are used to hide the details of the underlying

implementation. Difference:

The adapter pattern is geared towards making unrelated components work together

Applied to systems after they are designed (reengineering, interface engineering).

A bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently.

Engineering of an “extensible system”. New components can be added to the system, even if these

are not known at analysis or system design time.

52