Design PatternsDon’t reinvent the wheel

Hanoi - April, 2009Duong Trong Tan, (tandt@fpt.edu.vn)

What are design patterns?

They› are common ways of structuring programs› typically deal with a small number of

classes, but can be of any size› provide a communication framework in

which ideas can be discussed at a high level

› can specify how objects are created, how they interact, or how they are structured

Why design patterns?

Reuse solutions Vocabulary for development Better software

Who?

Alexandre Christopher ‘Gang of Four’: Erich Gamma, Richard

Helm, Ralph Johnson, and John M. Vlissides

What?

Gang of Four common design patterns Some new J2EE design patterns

How can design patterns be derived?

They do use the Design Principles

Programming to interfaces not implementations Favor composition over inheritance Encapsulate what varies Strive for loosely coupled between objects that interact Classes should OPEN for extension and CLOSE for

modification Depends on abstraction, not concrete classes Don't call us, we'll call you A class should have only one reason to change

Com

mon

patte

rns

Desig

n Pa

ttern

sC

ate

gorie

s

Singleton Builder Factory method Facade Decorator Observer Command Strategy

Creational: How to create objects (higher level than constructors)

Behavioral: Describing how objects interact

Structural: Common relationships in class diagrams

C

BS

Singleton

public static Counter getInstance() { if(uInstance == null) { this.uInstance = new Counter(); return this.uInstance; } else { return this.uInstance; }}

C

The purpose of Singleton

› Makes sure only one instance of an object exists within an application.

› A better solution compared to global variables

› Provide global access to the object instance.

› Example: Counter, Application Menu System, Application objects, Services, Clients

› Not as easy as you think: What about threading?

Factory Method

Defines an interface for creating an object but lets subclasses decide which class to instantiate.

Lets classes defer instantiation to subclasses

C

Benefits of Factories

We can choose what to instantiate at runtime

We can code to an interface› Don’t have to know exactly what kind of

object we’ll get back We centralize code

› In order to add new types of objects, we only have to modify one place, the factory

12

Builder C

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Façade

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.(GoF)

S

The DBFacade Example Common JDBC uses:

› Open a connection to DB

› Close a connection› Get all tables from

DB› Executes a SQL

statement› Retrieve result from

a SELECT statementAll That I Need

DatabaseFacade Outlook

JDBC APIDatabaseFacade

Clientuses

Connection

Statement

ResultSet

DatabaseMetadata

ResultSetMetadata

Driver…

Decorator

BufferedReader in = new BufferedReader(new FileReader(“foo.in"));

S

Strategy B

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it

Observer

GoF

B

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

MVC

What does it hire?

Command B

“Let’s hide (encapsulate) the way we call (invoke) methods.”

Example: Menus

Consider an application menu system. How do we de-couple our menu system from our document class?

Command Interface

Client

We can do a lot of things (actions) with a document. Each interface might be different!

Receiver

ConcreteCommandMenu contains many menu items.

Composite Pattern!

invoker

AllGoF patterns

J2EE patterns

Categorized by tiers: Presentation Tier Business Tier Integration Tier

Data Access Object

Alur et al.

Business Objects

Alur et al.

Session Façade

Alur et al.

Application Service

Alur et al.

References

E. Gamma, R. Helm, R. Johnson, & J. Vlissides. Design Patterns: Elements of Object-Oriented Software. Addison-Wesley, Boston, 1995.

D. Alur, J. Crupi and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies, Second Edition, 2003