Design Patterns

Patterns

•     Architectural patterns

– Large scale, course grained design

– Early iteration stages

– Layers, Client-Server, Model-View-Controller

•     Design patterns

– Small and medium-scale design

– Observer, Abstract Factory, Singleton

•     Idioms

– Language or implementation oriented low-level design solutions

 

Layered Architecture

    As in previous lecture

§ Presentation

§ Application

§ Domain

§ Business Infrastructure

§  Technical Services

§ Foundation

 

Model-View-Controller (MVC)

•     Context: Interactive applications with a flexible human-computer interface

•     Problem: UI are especially prone to change requests

•     Solution: MVC

Model-View-Controller (Cont.)

•     The Model-View-Controller architectural pattern divides an interactive application into three components

– The model contains the core functionality and data

– Views display information to the user

– Controllers handle user input.

•     Views and controllers together comprise the user interface

•     A change-propagation mechanism ensures consistency between the user interface and the model

 

Model-View-Controller (Cont.)

•     Flexible

– Easy to add new views

– Easy to add new controllers

– Easy to add new look-and-feel

•     Difficulties in reusing views separate from model

•     Platform-dependent code in view and controller

Design Patterns

•     A design pattern systematically names, motivates, and explains a general design that addresses recurring design problem in object-oriented systems

•     It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples

•     The solution is a general arrangement of objects and classes that solve the problem.

•     The solution is customised and implemented  to solve the problem in a particular context

     Gamma et al., Design Patterns,  Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994 

Design Pattern Description

• Name: Adapter.

• Intent: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

• Alias: Wrapper.

Design Pattern Description (Cont.)

• Motivation: Sometimes a toolkit that’s designed for reuse isn’t reusable only because its interface doesn’t match the domain-specific interface an application requires.

The Adapter provides a wrapper to the desired interface.

Design Pattern Description (Cont.)

• Applicability: Use the Adapter pattern when

– You want to use an existing class, and its interface does not match the one you need.

– You want to create a reusable class that cooperates with unrelated or unforeseen classes, i.e. classes that do not necessarily have compatible interfaces.

– You need to use several existing subclasses, but it’s impractical to adapt their interface by sub-classing every one. An object adapter can adapt the interface of its parent class.

 

Design Pattern Description (Cont.)

• Participants:

– Target

– Client

– Adaptee

– Adapter

• Collaborations: Clients call operations on an Adapter instance.

   In turn, the adapter calls Adaptee operations that carry out the request.

Design Pattern Description (Cont.)

• Consequences: A class adapter

– Adapts Adaptee to Target by committing to a concrete Adapter class. As a consequence, a class adapter won’t work when we want to adapt a class and all its subclasses.

– Lets Adapter override some of Adaptee’s behaviour, since Adapter is a subclass of Adaptee.

– Introduces only one object, and no additional pointer indirection is needed to get to the adaptee.

 

Design Pattern Description (Cont.)

• Consequences: An object adapter

– Lets a single Adapter work with many Adaptees, i.e. the Adaptee itself and all of its subclasses (if any). The Adapter can also add functionality to all Adaptees at once.

– Makes it harder to override Adaptee behaviour. It will require subclassing Adaptee and making Adapter refer to the subclass rather than the Adaptee itself.

Design Pattern Description (Cont.)

• Implementation: In a C++ implementation of a class adapter, Adapter would inherit publicly from Target and privately from Adaptee.

       …

• Sample Code: …

• Known uses: Adapters are common in Java, for example in a WindowAdapter class

• Related patterns: Bridge, Decorator, Proxy

Singleton

•  Intent: Ensure that a class only has one instance, and provide a global point of access to it.

•  Applicability: 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.

 

Polymorphism

•         Problem

–      How to handle alternatives based on type

–      Example: Paint program: Circle, Line, Rectangle

–      if-then-else requires code modification in several places if a new variation arises

–      Type variants (data and  behaviour)

–      How to create pluggable software components?

Polymorphism (Cont.)

•         Solution

–      Use polymorphic operations to assign responsibility for the behaviour to the types for which the behaviour varies

–      Do not test for the type of an object or use conditional logic

Pure Fabrication

•         Problem

–      What do we do when we do not want to violate high cohesion and low coupling?

•         Solution

–      Assign a highly cohesive set of responsibilities to an artificial class

•         Example

–      Saving Sale instances in a database

–      By Expert: assign this responsibility to Sale

–      But...

Pure Fabrication (Cont.)

•         But...

–      Large number of database operations

–      Coupling to a database

–      Saving objects in a database is a common task

=> many classes need to know how to work with the database

•         So

–      Create a new class, PersistentStorageBroker, with a method “Save( )”

•         Benefits

–      Sale remains well designed with high cohesion

–      PersistentStorageBroker is cohesive, generic and reusable

Indirection

•         Problem

–      How to decouple objects so that low coupling is supported and potential reuse remains high

•         Solution

–      Assign responsibilities to an intermediate object to mediate between the other objects so that they are not directly coupled

•         Example

–      Storing Sale to a database using PersistentStorageBroker

Indirection - Example

•         Modem

–      POS needs to manipulate a modem in order to transmit credit payments

–      Operating System provides low-level functionality for doing this

–      CreditAuthroisationService is responsible for talking to modem

•         Solutions

–      CreditAuthorisationService invokes low-level functions directly

»      High coupling

»      Low cohesion

»      Low portability

–      Intermediate class “Modem” between CreditAuthorisationService and modem