By Sergii Stets
DESIGN PATTERNS
Build flexible applications
Agenda
 What are patterns?
 Types of patterns
 Examples: commonly used patterns
 References
Design
patterns
2
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
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
Who made them?
Christopher Alexander
(architect)
published in 1977
”Gang of Four”
(computer scientists)
published in 1994
…
Design
patterns
5
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
Types of patterns
There are three basic kinds of design patterns:
 structural
 creational
 behavioural
Design
patterns
7
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
Structural patterns
Design
patterns
10
Structural patterns identify a simple
way to realize relationships between
entities.
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
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
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
Design
patterns
12
Singleton. It is so easy…
…that this will be working
in a multithreading
application?
Design
patterns
13
Singleton. Synchronized.
I still don’t like it!
Why did you synchronize the whole method?
Design
patterns
14
Singleton. Synchronizing critical
parts.
Gotcha! Two threads may
enter the if clause and create
two different instances!
Design
patterns
15
Singleton. Double check locking.
I heard it would still fail
because of Java memory
model!
Design
patterns
16
Singleton. Volatile.
Many believe it causes
performance problems in
multiprocessors systems. And
it works only since Java 5.
Design
patterns
17
Singleton. Bill Pugh implementation.
Looks good. But… what about
serialization?
Design
patterns
18
Singleton. Serialization.
Not bad. And what is the
shortest way to write
singleton?
Design
patterns
19
Singleton. The shortest way.
I like it.
Design
patterns
20
Singleton. Be responsible.
Think twice before using singleton
Design
patterns
21
By the way…
Do you the difference between?
Simple factory Factory method Abstract Factory
method ()
Simple factory
Design
patterns
22
The simple factory returns one
of many different classes.
It is not even a pattern, it’s an
ideology.
Simple factory. Code snippet
Design
patterns
23
Just take out object creation
process out of the client code and
put into some other class
Factory method
Design
patterns
24
Defines an interface for
creating an object, but let
subclasses decide which class
to instantiate.
method ()
Factory method. Code snippet
Design
patterns
25
Concrete factory
returns concrete
customer
Abstract factory
Design
patterns
26
Offers the interface for creating a
family of related objects, without
explicitly specifying their classes.
Factory method. Code snippet (1)
Design
patterns
27
Factory method. Code snippet (2)
Design
patterns
28
Create families of related
or dependent objects.
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.
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
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.
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
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.
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.
Design
patterns
35
Strategy
A Strategy defines a
set of algorithms that
can be used
interchangeably.
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
Any questions?
Design
patterns
37
Question time
Thank you
Design
patterns
38
Oh…stop.
I almost forgot about your
homework
Design
patterns
39
Home work
Please, implement any 6 design patterns two different ways:
1) Classical approach
2) Using Spring Framework.
Some not discussed patterns
go next…
Design
patterns
40
Builder
Design
patterns
41
Separate the construction of a
complex object from its
representation.
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)
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.
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.
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.
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.
Flightweight. Example
Design
patterns
47
Flightweight. Example
Design
patterns
48
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.
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)
Design
patterns
51
Momento. Example
Originator Caretaker
Momento
Client
Null object
Design
patterns
52
Null Object is an object with defined neutral
("null") behavior.
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

Design Patterns

Editor's Notes

  • #4 Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most—if not all—languages, depending on the capabilities of the language. Most importantly, any design pattern can be a double-edged sword— if implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior.
  • #5 Benefits of Patterns Benefits of knowing and using design patters are several. Patterns are known solution for building software systems. They can reduce development time as known solutions are used instead of reinventing the wheel. It is also a benefit to use known solutions that are tried and tested. Finally, patterns make the communication of development teams easier.
  • #6 Design patterns have their roots in the work of Christopher Alexander, a civil engineer who wrote about his experience in solving design issues as they related to buildings and towns. It occurred to Alexander that certain design constructs, when used time and time again, lead to the desired effect. He documented and published the wisdom and experience he gained so that others could benefit. About 15 years ago, software professionals began to incorporate Alexander's principles into the creation of early design pattern documentation as a guide to novice developers. This early work led others to also write about design patterns and culminated in the publication of Design Patterns: Elements of Reusable Object-Oriented Software in 1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 
  • #7 Много паттернов и но пытайтесь их всо запомнить.
  • #8 Порождающие паттерны, предназначенные для создания новых объектов в системе. Структурные паттерны, решающие задачи кОПпОнОвки системы на ОснОво кНассОв и объектов. Паттерны поведения, предназначенные для распределения обязанностей ПоМду объектами в системе.
  • #11 Работа с аудиторией
  • #17 volatile – говорит Đž том, что осНи нокиК поток изменяет это пОНо, то на данный момент времени никакОК другой поток но может менять значение этой переменной. ТакМо это говорит Đž том, что в любой момент времени значение этой переменной ОдинакОвО для любого потока и соответствует пОсНодноПу изменению. ТО есть любой поток напрямую тыркается иПоннО в "подлинную" переменную.
  • #19 Serialization has a special hook it uses - a private method on the class being instantiated called readResolve() - which is meant to supply a 'hook' for a class developer to ensure that they have a say in what object is returned by serialization.
  • #20 ТакОК метод потокопезопасен, краток, нО йоС НонивОК инициализации.
  • #30 Второй вопрос
  • #31 Второй вопрос
  • #32 Второй вопрос
  • #33 Второй вопрос
  • #34 Второй вопрос
  • #35 Второй вопрос
  • #36 Второй вопрос
  • #43 In Abstract Factory we define an interface which will create families of related or dependent objects. In simple words, interface will expose multiple methods each of which will create some object. Again, here method return types will be generic interfaces. All this objects will together become the part of some important functionality.
  • #44 Приспособленец - паттерн, структурирующий объекты таким образом, что иС них инстанцируется всогО лишь ограниченный необходимый набор экземпляров вместо всогО боль http://codelab.ru/pattern/flyweight/ шОгО множества.  Flyweight is used when there is a need to create high number of objects of almost similar nature. High number of objects consumes high memory and flyweight design pattern gives a solution to reduce the load on memory by sharing objects.
  • #47 Для того, чтоб воспользоваться паттерном Приспособленец, нуМнО разделить атрибуты на два типа: Intrinsic – параметры, которые но зависят от контекста, и Они но изменяемые и Extrinsic - передаются иСвно и принадлежат контексту.
  • #51 Необходимо сохранять, фиксировать и восстанавливать внутреннее состояние объекта но нарушая инкапсуляцию. http://habrahabr.ru/sandbox/39499/  У нас есть главный объект, который имеет внутреннее состояние, именуемый ”Создатель” (Originator).  Так Мо у нас есть объект, который может выполнять определенные действия над “Создателем” (при этом внутреннее состояние “Создателя” может изменяться) и имеет возможность сохранять и восстанавливать состояние “Создателя”, кОгда оПу это необходимо. Этот кНасс именуется “Опекун”(Caretaker). Для того, что бы “Опекун” сПОг запомнить внутреннее состояние “Создателя”, Он запрашивает у ногО объект, содержащий необходимые данные, именуемый “Хранитель” (Memento).  http://www.journaldev.com/1734/memento-design-pattern-in-java-example-tutorial
  • #54 Представьте, что у вас есть задача выкопать яму, пО алгоритму у вас есть СоПНокОп. АнаНОг нуНН-а — отсутствие СоПНокОпа. Если огО нет, то да, я хочу, чтобы вся задача прервалась, это исключение. ĐŻ но хочу тихого выполнения, будто бы СоПНокОп есть, нО яма но выкопана. Вы скажете, что такие ситуации тоже отслеживаются в функциональных языках. Но, позвольте, какая тогда разница: проверяю я нуНН иНи еще что-НийО? Хорошо это иНи плохо, нО проверка на нуНН инОгда обладает семантикой, а но является просто проверкой на присутствие объекта. Да в любом языке программирования вместо нуНН-а ПОМнО возвращать фиктивное пустое значение (Null object шайНОн), нО хорошо подумайте, стоит Ни это делать: явную Ошийку проще отловить, чем неявную.