Introduction To

Design Pattern
 Design Patterns
What is a Design Pattern?

“Each pattern describes a problem which occurs over

and over again in our environment, and then describes
the core of the solution to that problem, in such a way
that you can use this solution a million times over,
without ever doing it the same way twice.” [1]
[Christopher Alexander]
Design patterns capture the best practices of
experienced object-oriented software developers.
Design patterns are solutions to general software
development problems.
 Design Patterns
Pattern’s Elements – Pattern Name

In general, a pattern has four essential elements.

 The pattern name

 The problem
 The solution
 The consequences
 Design Patterns
Pattern’s Elements – The Pattern Name

The pattern name is a handle we can use to describe a

design problem, its solutions, and consequences in a word
or two.
► Naming a pattern immediately increases the design
vocabulary. It lets us design at a higher level of
abstraction.
► ItHaving a vocabulary for patterns lets us talk about
them.
► makes it easier to think about designs and to
communicate them and their trade-offs to others.
 Design Patterns
Pattern’s Elements – The Problem

The problem describes when to apply the pattern.

► It explains the problem and its context.
► It might describe specific design problems such as how
to represent algorithms as objects.
► It might describe class or object structures that are
symptomatic of an inflexible design.
► Sometimes the problem will include a list of conditions
that must be met before it makes sense to apply the
pattern.
 Design Patterns
Pattern’s Elements – The Solution

The solution describes the elements that make up the

design, relationships, responsibilities, and collaborations.
► The solution doesn't describe a particular concrete
design or implementation, because a pattern is like a
template that can be applied in many different
situations.
► Instead, the pattern provides an abstract description
of a design problem and how a general arrangement
of elements (classes and objects in our case) solves it.
 Design Patterns

Pattern’s Elements – The Consequences

The consequences are the results and trade-offs of applying the pattern.
► The consequences for software often concern space and time
trade-offs.
► They may address language and implementation issues as well.
Since reuse is often a factor in object-oriented design, the
consequences of a pattern include its impact on a system's flexibility,
extensibility, or portability.
► Listing these consequences explicitly helps you understand and
evaluate them
 Design Patterns

Types
Erich Gamma, Richard Helm, Ralph Johnson and John Vlisides in
their Design Patterns book define 23 design patterns divided into three
types:
► Creational patterns are ones that create objects for you, rather than
having you instantiate objects directly. This gives your program
more flexibility in deciding which objects need to be created for a
given case.
► Structural patterns help you compose groups of objects into larger
structures, such as complex user interfaces or accounting data.
► Behavioral patterns help you define the communication between
objects in your system and how the flow is controlled in a complex
program.
 Java Design Patterns
Creational Patterns

► The creational patterns deal with the best way to create instances of
objects.
► In Java, the simplest way to create an instance of an object is by
using the new operator.
Fred = new Fred(); //instance of Fred class
► This amounts to hard coding, depending on how you create the
object within your program.
► In many cases, the exact nature of the object that is created could
vary with the needs of the program and abstracting the creation
process into a special “creator” class can make your program more
flexible and general.
 Java Design Patterns

Creational Patterns and Java II

► The Singleton Pattern:
is a class of which there can be no more than one instance.It provides a
single global point of access to that instance.
► The Factory Pattern:

provides a simple decision making class that returns one of several

possible subclasses of an abstract base class depending on the data that
are provided.
► The Abstract Factory Pattern:

provides an interface to create and return one of several families of

related objects.
 Java Design Patterns

Creational Patterns and Java II

► The Builder Pattern:

separates the construction of a complex object from its representation.
► The Prototype Pattern:

starts with an initialized and instantiated class and copies or clones it

to make new instances rather than creating new instances.
 The Singleton Pattern
Definition & Applicability - I

Sometimes it is appropriate to have exactly one instance of a class:

► window managers, print spoolers, filesystems.
Typically, those types of objects known as singletons, are accessed by
disparate objects throughout a software system, and therefore require a
global point of access.
The Singleton pattern addresses all the concerns above. With the
Singleton design pattern you can:
► Ensure that only one instance of a class is created.
► Provide a global point of access to the object.
► Allow multiple instances in the future without affecting a
singleton class' clients.
 The Singleton Pattern
Definition & Applicability - II

 The Singleton pattern ensures a class has only one instance, and provides a
global point of access to it.
 The class itself is responsible for keeping track of its sole instance. The class
can ensure that no other instance can be created (by intercepting requests to
create new objects), and it can provide a way to access the instance.
 Singletons maintain a static reference to the sole singleton instance and return a
reference to that instance from a static instance() method.
 The Singleton Pattern
The Classic Singleton - I

public class ClassicSingleton {

private static ClassicSingleton instance = null;

protected ClassicSingleton() {
// exists only to defeat instantiation.
}
public static ClassicSingleton getInstance() {
if(instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}
The ClassicSingleton class maintains a static reference to the lone singleton
instance and returns that reference from the static getInstance() method.
 The Singleton Pattern
The Classic Singleton - II

 The ClassicSingleton class employs a technique known as lazy instantiation to create

the singleton; as a result, the singleton instance is not created until the getInstance()
method is called for the first time. This technique ensures that singleton instances are
created only when needed.
 The ClassicSingleton class implements a protected constructor so clients cannot
instantiate ClassicSingleton instances; however, the following code is perfectly legal:

public class SingletonInstantiator {

public SingletonInstantiator() {
ClassicSingleton instance =
ClassicSingleton.getInstance();

ClassicSingleton anotherInstance = new ClassicSingleton();

...
 The Singleton Pattern
Problems - I

How can a class that does not extend ClassicSingleton create a

ClassicSingleton instance if the ClassicSingleton constructor is
protected?
 Protected constructors can be called by subclasses and by other
classes in the same package. Hence, because ClassicSingleton
and SingletonInstantiator are in the same package (the default
package), SingletonInstantiator() methods can create
ClassicSingleton instances.
Solutions:
1. We can make the ClassicSingleton constructor private so that
only ClassicSingleton’s methods call it; however, that means
ClassicSingleton cannot be subclassed. Also, it's a good idea to
declare the singleton class final, which makes that intention
explicit and allows the compiler to apply performance
optimizations.
2. We can put your singleton class in an explicit package, so
classes in other packages (including the default package) cannot
instantiate singleton instances.
 The Singleton Pattern
Problems - II

The ClassicSingleton class is not thread-safe.

If two threads – we will call them Thread 1 and Thread 2, call
ClassicSingleton.getInstance() at the same time, two ClassicSingleton
instances can be created if Thread 1 is preempted just after it enters
the if block and control is subsequently given to Thread 2.
Solution: Synchronization
public class ClassicSingleton {
private static ClassicSingleton instance = null;
private static Object syncObject; // to synchronize a block
protected ClassicSingleton() {
/*exists only to defeat instantiation*/ };
public static ClassicSingleton getInstance() {
synchronized(syncObject) {
if (instance == null) instance = new
ClassicSingleton();}
return instance;}
}