Basic OO design patterns

This page is published under the terms of the licence summarized in the footnote.

This paper continues our discussion of design patterns with a focus on OO design patterns commonly used in web applications.

Contents

Introduction (recap) 1

OO design patterns. 1

Adding a level of indirection. 2

Façade. 2

Adapter (aka Wrapper) 2

Proxy (aka Surrogate or Ambassador) 3

Singleton – a single-object class. 3

Observer 3

Other design patterns in the GoF’s famous book. 3

An anti-OO pattern: point-to-point coupling. 4

Introduction (recap)

Software architecture is about specifying data processing needs, and describing how components will be organised to cooperate in the required processes.

To design a large and complex system – one that is successful and easy to manage - takes more than description.

The architect has to make a series of modular design decisions.

· What is the right size and scope of a component?

· How to avoid or minimise duplication between components?

· How to separate or distribute components?

· How integrate components?

The architect’s tool kit includes pre-defined OO design patterns..

OO design patterns

Common OO design patterns, used by architects of web-oriented SOA implementations are:

• Façade
• Adapter
• Proxy
• Singleton
• Observer

There are overlaps between some patterns

Enterprise and solution architects do not need to memorise the details of specific OO design patterns

But what follows may help you understand software architecture thinking.

Adding a level of indirection

A general idea underpins many OO design patterns.

Problem: A client wants something a server will not do directly, or wants to be hidden from server details

Solution: Introduce a broker or intermediary component between client and server "adding a level of indirection".

Façade

Façade is a frontage to a building; an interface that sits in front of a system.

Essentials

• decouples clients from server components
• abstracts clients from a system’s internal implementation details
• hides fine-grained services behind coarser-grained services that clients want
• presents a consistent interface to many clients
• provides a place to attach security and transaction management applicable on entering or leaving a system

Problem: How can a client avoid being too tightly coupled with a server subsystem?

How to aggregate services into a coarser-grained component?

Solution: introduce a façade that provides a unified interface for different clients, and makes the subsystem easier to use

So clients know what the subsystem does for them, but nothing else

Trade offs

• Calling many fine-grained services tends to increase network traffic
• A coarse-grained service takes longer to complete.

About a façade component

• It acts as an interface or broker
• It needs no intelligence, beyond being able to forward messages
• It is usually stateless
• It cannot entirely decouple, some changes to internal components will force themselves into the façade, and so into clients of that facade.

The façade pattern takes the interface to a substantial system of components and puts the interface inside a component that does nothing else but present the interface.

Adapter (aka Wrapper)

Essentials

• broker where required interface not = provided interface
• converts the interface of an existing component into an interface that clients want to use
• enables reuse of legacy systems/technologies, prolongs their life
• (though not every application provides an interface usefully exposed via web services)

Problem: How can a client avoid knowing server details, be shielded from server changes, call a server that does not have exactly the interface required?

Solution: Introduce an adapter to convert the server’s offered interface into the one that is required.

Proxy (aka Surrogate or Ambassador)

Essentials

• A surrogate or placeholder for a server component
• Can simplify the client’s service request by hiding technology and location of the server
• used in CORBA, DCOM and Web Services technologies.
• can act as a façade, dispatching each service request to the appropriate back end component
• can be used for testing, can stand in place of a server component during the testing process.

Problem: How can a client avoid dependence on a specific object representation or implementation?

Invoke a server in a different name space, or a server to which access must be restricted in some way?

Solution: Introduce a proxy (on the client side) to forward the request and control access.

A proxy can hide and handle the distribution of code to different name spaces; this principle underlies CORBA and DCOM.

In Distributed Objects, Object Request Broker establishes the proxies which manage the remote procedure call.

Singleton – a single-object class

We only need one copy of:

• Global variables – e.g. current date and time
• A commonly required table – e.g. exchange rates
• A façade – e.g. a stateless controller

So, a single-object class can hold the data or do the job.

How to recognise it?

• A private constructor
• A public static field or method (acts at the class level, cannot refer to a specific instance of the class.)

Observer

The observer pattern comprises two kinds of component.

A subject: notifies observers of changes to its state

Observers: registers with the subject to be notified of changes. Unregisters when it lose interest.

Other design patterns in the GoF’s famous book

This table lists about half the patterns (including the ones mentioned above).

Name	Description or purpose
Singleton	A component (or class) with only one instance (or object).
Façade	Consistent interface coarse-grained services that encapsulate a suibsystem
Proxy	A surrogate for a distributed component. Used in distribution of code between different name spaces.
Adapter	A wrapper that converts a provided service into a required service. Facilitates the reuse of existing technologies.
Observer	A component that monitors the state of another component. Curiously, the subject of observation may be an object.
Composite	Enables a class to process operations on every level of a hierarchical structure, including composite and leaf nodes
Template method	Offers several variations of an algorithm.
Strategy	Adds a façade to a template method.
Manager	Often used to manage a set of objects.
Factory method	Create the right server object for the client - hiding how the server object is initialized.
Abstract object factory	Create the right factory object for the client - hiding which factory class is used.

An anti-OO pattern: point-to-point coupling

Adding a level of indirection underpins many OO design patterns

But sometimes, the anti-pattern is better.

Problem: A broker cannot entirely shield a client from server changes. A broker requires some redundant coding and incur some communication costs.

Solution: There are times when it is simpler and cheaper for the client to call the server directly, accept the coupling this involves.

(Sometimes house seller and buyer are better off talking to each other without an estate agent getting in the way.)

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org