This document describes various design patterns from GOF patterns.

1. Introduction to Design Patterns
Through Java
@Copyright Aditya Pratap Bhuyan 1

2. Agenda
 Introduction to Design Patterns
 Creational Patterns
 Behavioral Patterns
 Structural Patterns
 J2EE Patterns
@Copyright Aditya Pratap Bhuyan 2

3. Introduction to Design Patterns
A design pattern is not a finished design, it is
a description of a solution to a common
problem. A design pattern can be reused in
multiple applications, and that is the main
advantage of using it. It can also be seen as
a template for how to solve a problem that
can occur in many different situations
and/or applications. It is not code reuse as it
usually does not specify code, but code can
be easily created from a design pattern.
Object-oriented design patterns typically
show relationships and interactions between@Copyright Aditya Pratap Bhuyan 3

4. Introduction to Design Patterns
Problem/requirement
To create a design pattern, we need to go through a mini analysis
design and may be coding to test out the solution. This section
state the requirements the problem we want to solve. This is
usually a common problem that will occur in more than one
application.
Forces
This section state the technological boundaries, that helps and
guides the creation of the solution.
Solution
This section describes how to write the code to solve the above
problem. This is the design part of the design pattern. It may
contain class diagrams, sequence diagrams, and or whatever is
needed to describe how to code the solution.
A design pattern can be considered as block that can be placed in
@Copyright Aditya Pratap Bhuyan 4

5. Creational Patterns
Creational design patterns abstract the
instantiation process. They help make a system
independent of how its objects are created,
composed, and represented. A class creational
pattern uses inheritance to vary the class that's
instantiated, whereas an object creational
pattern will delegate instantiation to another
object.
Creational patterns become important as systems
evolve to depend more on object composition@Copyright Aditya Pratap Bhuyan 5

6. Creational Patterns
There are two recurring themes in these patterns.
First, they all encapsulate knowledge about
which concrete classes the system uses.
Second, they hide how instances of these
classes are created and put together. All the
system at large knows about the objects is their
interfaces as defined by abstract classes.
Consequently, the creational patterns give you a
lot of flexibility in what gets created, who creates@Copyright Aditya Pratap Bhuyan 6

7. Abstract Factory
Provide an interface for creating families of
related or dependent objects without specifying
their concrete classes.
@Copyright Aditya Pratap Bhuyan 7

8. Abstract Factory
The abstract factory pattern provides a way to
encapsulate a group of individual factories that have a
common theme without specifying their concrete
classes. In normal usage, the client software creates a
concrete implementation of the abstract factory and
then uses the generic interface of the factory to create
the concrete objects that are part of the theme. The
client does not know (or care) which concrete objects it
gets from each of these internal factories, since it uses
only the generic interfaces of their products. This
pattern separates the details of implementation of a set
of objects from their general usage and relies on object@Copyright Aditya Pratap Bhuyan 8

9. Abstract Factory
@Copyright Aditya Pratap Bhuyan 9

10. Builder Pattern
The more complex an application is the complexity of classes and
objects used increases. Complex objects are made of parts produced
by other objects that need special care when being built. An
application might need a mechanism for building complex objects that
is independent from the ones that make up the object. If this is the
problem you are being confronted with, you might want to try using
the Builder (or Adaptive Builder) design pattern.
This pattern allows a client object to construct a complex object by
specifying only its type and content, being shielded from the details
related to the objects representation. This way the construction
process can be used to create different representations. The logic of
this process is isolated form the actual steps used in creating the
complex object, so the process can be used again to create a different
object form the same set of simple objects as the first one.
@Copyright Aditya Pratap Bhuyan 10

11. Builder Pattern
Separate the construction of a complex object from its representation so
that the same construction process can create different
representations.
@Copyright Aditya Pratap Bhuyan 11

12. Builder Pattern
@Copyright Aditya Pratap Bhuyan 12

13. Prototype Pattern
The Prototype design pattern is the one in
question. It allows an object to create
customized objects without knowing their class
or any details of how to create them. Up to this
point it sounds a lot like the Factory Method
pattern, the difference being the fact that for the
Factory the palette of prototypical objects never
contains more than one object.
@Copyright Aditya Pratap Bhuyan 13

14. Prototype Pattern
@Copyright Aditya Pratap Bhuyan 14

15. Structural Pattern
Structural patterns are concerned with how
classes and objects are composed to form
larger structures. Structural class patterns use
inheritance to compose interfaces or
implementations. As a simple example,consider
how multiple inheritance mixes two or more
classes into one. The result is a class that
combines the properties of its parent classes.
This pattern is particularly useful for making
independently developed class libraries work
together.
@Copyright Aditya Pratap Bhuyan 15

16. Flyweight Pattern
It is a mechanism by which you can avoid creating
a large number of object instances to represent
the entire system. To decide if some part of a
program is a candidate for using Flyweights,
consider whether it is possible to remove some
data from the class and make it extrinsic.
@Copyright Aditya Pratap Bhuyan 16

17. Flyweight Pattern
Some programs require a large number of objects that
have some shared state among them. Consider for
example a game of war, were there is a large number
of soldier objects; a soldier object maintain the
graphical representation of a soldier, soldier behavior
such as motion, and firing weapons, in addition
soldiers health and location on the war terrain.
Creating a large number of soldier objects is a
necessity however it would incur a huge memory
cost. Note that although the representation and
behavior of a soldier is the same their health and
location can vary greatly.
@Copyright Aditya Pratap Bhuyan 17

18. Flyweight Pattern
@Copyright Aditya Pratap Bhuyan 18

19. Proxy Pattern
It is used when you need to represent a complex with a
simpler one. If creation of object is expensive, its
creation can be postponed till the very need arises
and till then, a simple object can represent it. This
simple object is called the “Proxy” for the complex
object.
@Copyright Aditya Pratap Bhuyan 19

20. Proxy Pattern
Sometimes we need the ability to control the access to
an object. For example if we need to use only a few
methods of some costly objects we'll initialize those
objects when we need them entirely. Until that point
we can use some light objects exposing the same
interface as the heavy objects. These light objects are
called proxies and they will instantiate those heavy
objects when they are really need and by then we'll
use some light objects instead.
@Copyright Aditya Pratap Bhuyan 20

21. Proxy Pattern
@Copyright Aditya Pratap Bhuyan 21

22. Decorator Pattern
Attach additional responsibilities to an object
dynamically. Decorators provide a flexible
alternative to subclassing for extending functionality.
The decorator pattern helps to add behavior or
responsibilities to an object. This is also called
“Wrapper”.
@Copyright Aditya Pratap Bhuyan 22

23. Decorator Pattern
Sometimes we want to add
responsibilities to individual
objects, not to an entire class. A
graphical user interface
toolkit, for example, should let you
add properties like borders or
behaviors like scrolling to any user
interface
@Copyright Aditya Pratap Bhuyan 23

24. Behavioral Patterns
Behavioral patterns are concerned with algorithms and
the assignment of responsibilities between objects.
Behavioral patterns describe not just patterns of
objects or classes but also the patterns of
communication between them. These patterns
characterize complex control flow that's difficult to
follow at run-time. They shift your focus away from
flow of control to let you concentrate just on the way
objects are interconnected.
@Copyright Aditya Pratap Bhuyan 25

25. Chain of Responsibility
Avoid coupling the sender of a request to its receiver
by giving more than one object a chance to handle
the request. Chain the receiving objects and pass the
request along the chain until an object handles it.
The idea of this pattern is to decouple senders and
receivers by giving multiple objects a chance to
handle a request. The request gets passed along a
chain of objects until one of them handles it.
@Copyright Aditya Pratap Bhuyan 26

26. Chain of Responsibility
The Chain of Responsibility design pattern allows an
object to send a command without knowing what
object will receive and handle it. The request is sent
from one object to another making them parts of a
chain and each object in this chain can handle the
command, pass it on or do both. The most usual
example of a machine using the Chain of
Responsibility is the vending machine coin slot:
rather than having a slot for each type of coin, the
machine has only one slot for all of them. The
dropped coin is routed to the appropriate storage
place that is determined by the receiver of the
@Copyright Aditya Pratap Bhuyan 27

27. Chain of Responsibility
@Copyright Aditya Pratap Bhuyan 28

28. Mediator Pattern
Define an object that encapsulates how a set of objects
interact. Mediator promotes loose coupling by
keeping objects from referring to each other
explicitly, and it lets you vary their interaction
independently.
Object-oriented design encourages the distribution of
behavior among objects. Such distribution can result
in an object structure with many connections
between objects; in the worst case, every object ends
up knowing about every other.
@Copyright Aditya Pratap Bhuyan 29

29. Mediator Pattern
Though partitioning a system into many objects
generally enhances re-usability, proliferating
interconnections tend to reduce it again. Lots of
interconnections make it less likely that an object can
work without the support of others—the system acts
as though it were monolithic. Moreover, it can be
difficult to change the system's behavior in any
significant way, since behavior is distributed among
many objects. As a result, you may be forced to
define many subclasses to customize the system's
behavior.
@Copyright Aditya Pratap Bhuyan 30

30. Mediator Pattern
@Copyright Aditya Pratap Bhuyan 31

31. Memento Pattern
Briefly, the Originator (the object to be saved) creates a
snap-shot of itself as a Memento object, and passes
that reference to the Caretaker object. The Caretaker
object keeps the Memento until such a time as the
Originator may want to revert to a previous state as
recorded in the Memento object.
The intent of this pattern is to capture the internal state
of an object without violating encapsulation and thus
providing a mean for restoring the object into initial
state when needed.
@Copyright Aditya Pratap Bhuyan 32

32. Memento Pattern
It is sometimes necessary to capture the internal state of an object at some
point and have the ability to restore the object to that state later in time.
Such a case is useful in case of error or failure. Consider the case of a
calculator object with an undo operation such a calculator could simply
maintain a list of all previous operation that it has performed and thus
would be able to restore a previous calculation it has performed. This
would cause the calculator object to become larger, more complex, and
heavyweight, as the calculator object would have to provide additional
undo functionality and should maintain a list of all previous operations.
This functionality can be moved out of the calculator class, so that an
external (let's call it undo manager class) can collect the internal state
of the calculator and save it. However providing the explicit access to
every state variable of the calculator to the restore manager would be
impractical and would violate the encapsulation principle.
@Copyright Aditya Pratap Bhuyan 33

33. Memento Pattern
@Copyright Aditya Pratap Bhuyan 34

34. Template Method Pattern
If we take a look at the dictionary definition of a
template we can see that a template is a preset
format, used as a starting point for a particular
application so that the format does not have to be
recreated each time it is used.
On the same idea is the template method is based. A
template method defines an algorithm in a base class
using abstract operations that subclasses override to
provide concrete behavior.
@Copyright Aditya Pratap Bhuyan 35

35. Template Method Pattern
Consider an application framework that provides
Application and Document classes. The Application
class is responsible for opening existing documents
stored in an external format, such as a file. A
Document object represents the information in a
document once it's read from the file. Applications
built with the framework can subclass Application
and Document to suit specific needs. For example, a
drawing application defines DrawApplication and
DrawDocument subclasses; a spreadsheet application
defines SpreadsheetApplication and
SpreadsheetDocument subclasses.
@Copyright Aditya Pratap Bhuyan 36

36. Template Method Pattern
@Copyright Aditya Pratap Bhuyan 37

37. Visitor Pattern
Collections are data types widely used in object
oriented programming. Often collections contain
objects of different types and in those cases some
operations have to be performed on all the collection
elements without knowing the type.
A possible approach to apply a specific operation on
objects of different types in a collection would be the
use if blocks in conjunction with 'instanceof' for each
element. This approach is not a nice one, not flexible
and not object oriented at all. At this point we should@Copyright Aditya Pratap Bhuyan 38

38. Visitor Pattern
@Copyright Aditya Pratap Bhuyan 40