The goal of the presentation is to tell about the design patterns that are widely used in software developing in an easy to understand manner.

1. By Sergii Stets
DESIGN PATTERNS
Build flexible applications

2. Agenda
 What are patterns?
 Types of patterns
 Examples: commonly used patterns
 References
Design
patterns
2

3. What are patterns?
 Optimized, reusable solutions to the
programming problems that we encounter
every day.
 It is not a class or a library that we can
simply plug into our system.
 It's not language-specific.
Design
patterns
3

4. Why do we need it?
 It gives developers a common vocabulary to
talk about software solutions.
 Reduces development time as known
solutions are used instead of reinventing the
wheel.
 Tried and tested solutions
Design
patterns
4

5. Who made them?
Christopher Alexander
(architect)
published in 1977
”Gang of Four”
(computer scientists)
published in 1994
…
Design
patterns
5

6. Bunch of Patterns
Design
patterns
6
Observe
State
Strategy
Templat
Visitor
Null obje
Abstract
Factory
Builder Factory
Method
Prototype
Singleton
Chain of
responsibility
Command
Interpreter
Iterator
Mediator
Memento
Adapter
Bridge
Composite
Decorator Facad
e
Flyweight
Proxy

7. Types of patterns
There are three basic kinds of design patterns:
 structural
 creational
 behavioural
Design
patterns
7

8. Creational patterns
Design
patterns
8
Deal with object
creation mechanisms, trying to create
objects in a manner suitable to the
situation.
Abstract factory
Builder
Factory method
Prototype
Singleton

9. Structural patterns
Design
patterns
10
Structural patterns identify a simple
way to realize relationships between
entities.
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

10. Behavioral patterns
Design
patterns
9
Behavioural patterns are used in
communications between entities.
Make it easier and more flexible for
these entities to communicate.
Template method
Iterator
Strategy
Command
Chain of responsibility
Momento
Mediator
Observer
Visitor
Interpreter
State
Null object

11. Singleton
Design
patterns
11
Ensure a class has only one
instance, and provide a global point of
access to it.
Seems to be easy…
Let’s check…
Exercise time
5 minutes

12. Design
patterns
12
Singleton. It is so easy…
…that this will be working
in a multithreading
application?

13. Design
patterns
13
Singleton. Synchronized.
I still don’t like it!
Why did you synchronize the whole method?

14. Design
patterns
14
Singleton. Synchronizing critical
parts.
Gotcha! Two threads may
enter the if clause and create
two different instances!

15. Design
patterns
15
Singleton. Double check locking.
I heard it would still fail
because of Java memory
model!

16. Design
patterns
16
Singleton. Volatile.
Many believe it causes
performance problems in
multiprocessors systems. And
it works only since Java 5.

17. Design
patterns
17
Singleton. Bill Pugh implementation.
Looks good. But… what about
serialization?

18. Design
patterns
18
Singleton. Serialization.
Not bad. And what is the
shortest way to write
singleton?

19. Design
patterns
19
Singleton. The shortest way.
I like it.

20. Design
patterns
20
Singleton. Be responsible.
Think twice before using singleton

21. Design
patterns
21
By the way…
Do you the difference between?
Simple factory Factory method Abstract Factory
method ()

22. Simple factory
Design
patterns
22
The simple factory returns one
of many different classes.
It is not even a pattern, it’s an
ideology.

23. Simple factory. Code snippet
Design
patterns
23
Just take out object creation
process out of the client code and
put into some other class

24. Factory method
Design
patterns
24
Defines an interface for
creating an object, but let
subclasses decide which class
to instantiate.
method ()

25. Factory method. Code snippet
Design
patterns
25
Concrete factory
returns concrete
customer

26. Abstract factory
Design
patterns
26
Offers the interface for creating a
family of related objects, without
explicitly specifying their classes.

27. Factory method. Code snippet (1)
Design
patterns
27

28. Factory method. Code snippet (2)
Design
patterns
28
Create families of related
or dependent objects.

29. Design
patterns
29
Abstract vs method vs simple
Factory Method pattern is a simplified version of Abstract
Factory pattern.
Factory Method pattern is responsible of creating products
that belong to one family, while Abstract Factory pattern
deals with multiple families of products.
Simple factory is an ideology not pattern.

30. Design
patterns
30
Bridge vs Adapter
Bridge decouples an abstraction from its
implementation so that the two can vary
independently.
Fill the difference
The Adapter pattern is used so that two
unrelated interfaces can work together

31. Design
patterns
31
Refactoring to “Bridge”
Before refactoring:
After refactoring:
The Bridge pattern is an application of the
old advice, "prefer composition over
inheritance".
It becomes handy when you must subclass
different times in ways that are orthogonal with
one another.
Say you must implement a hierarchy of colored
shapes. You wouldn't subclass Shape with
Rectangle and Circle and then subclass
Rectangle with RedRectangle, BlueRectangle
and GreenRectangle and the same for Circle,
would you? You would prefer to say that each
Shape has a Color and to implement a hierarchy
of colors, and that is the Bridge Pattern.

32. Design
patterns
32
Adapter
A legacy Rectangle component's display()
method expects to receive "x, y, w, h"
parameters. But the client wants to pass
"upper left x and y" and "lower right x and
y".
This incongruity can be reconciled by
adding an additional level of indirection –
i.e. an Adapter object.
So old component is plugged into to a new sys

33. Design
patterns
33
Template method vs Strategy
We use the Template Method when we
have a long, complicated algorithm that
can be decomposed into a series of
discreet steps.
Fill the difference
Strategy pattern is used when we have
multiple algorithm for a specific task and
client decides the actual implementation to
be used at runtime.

34. Design
patterns
34
Template method
A Template method
pattern provides a skeleton
for performing any sort of
algorithm or an operation,
and it allows the sub-
classes to re-define part of
the logic.

35. Design
patterns
35
Strategy
A Strategy defines a
set of algorithms that
can be used
interchangeably.

36. References
Design
patterns
36
1. Head First Design Patterns by Eric Freeman, Elisabeth
Robson, Bert Bates, Kathy Sierra
2. Design Patterns: Elements of Reusable Object-Oriented
Software by Gang of Four
3. Refactoring to Patterns by Joshua Kerievsky

37. Any questions?
Design
patterns
37
Question time

38. Thank you
Design
patterns
38
Oh…stop.
I almost forgot about your
homework

39. Design
patterns
39
Home work
Please, implement any 6 design patterns two different ways:
1) Classical approach
2) Using Spring Framework.

40. Some not discussed patterns
go next…
Design
patterns
40

41. Builder
Design
patterns
41
Separate the construction of a
complex object from its
representation.

42. Design
patterns
42
Builder
specifies an abstract interface for creating
parts of a Product object
Concrete Builder
constructs and assembles parts of the
product by implementing the Builder
interface
defines and keeps track of the
representation it creates
provides an interface for retrieving the
product
Director
constructs an object using the Builder
interface
Product
represents the complex object under
construction.
Builder (UML)

43. Flightweight
Design
patterns
43
A flyweight is an object that
minimizes memory use by sharing as
much data as possible with other similar
objects.
It is all about sharing.

44. Flightweight. When should we
use it?
Design
patterns
44
When:
o Need to create a large number of objects
o Because of the large number when memory cost is a constraint.
o When most of the object attributes can be made external and shared.
o Same object will be used repeatedly.
For example:
Imagine we have a text editor. If we create an object for every character in a file,
think of it how many objects we will create for a long document. What will be the
application performance.

45. Flightweight. UML
Design
patterns
45
Flyweight
Declares an interface through which flyweights
can receive
Concrete Flyweight
Implements the Flyweight interface and stores
intrinsic state.
Flyweight Factory
The factory creates and manages flyweight
objects.

46. Flightweight. Object properties.
Design
patterns
46
Object properties
Intrinsic Extrinsic
Intrinsic - naturally belongs to the
'Fly Weight' object and thus should
be permanent or immutable
(internal) or context free.
Extrinsic - state that belongs to the
context of the object (external) or
unique to that instance.

47. Flightweight. Example
Design
patterns
47

48. Flightweight. Example
Design
patterns
48

49. Momento
Design
patterns
49
Captures the internal state of an object
without violating encapsulation and thus
providing a mean for restoring the object
into initial state when needed.

50. Design
patterns
50
Caretaker
Responsible for keeping the memento.
Originator
Creates a memento object capturing the
originators internal state.
Memento
Stores internal state of the Originator object.
Momento (UML)

51. Design
patterns
51
Momento. Example
Originator Caretaker
Momento
Client

52. Null object
Design
patterns
52
Null Object is an object with defined neutral
("null") behavior.

53. Null object. UML
Abstract Class
Defines abstract primitive operations that
concrete implementations have to define.
Real Class
A real implementation of the Abstract Class
performing some real actions.
Null Class
An implementation which do nothing of the
abstract class, in order to provide a non-null
object to the client.
Client
Gets an implementation of the abstract class
and uses it. It doesn't really care if the
implementation is a null object or an real object
Design
patterns
53