Design Patterns in Java
Design Patterns
T
h
i
n
k
i
n
g
i
n
P
a
t
t
e
r
n
s
w
i
t
h
J
a
v
a
Bruce Eckel
http://www.mindview.net/Books/TIPatterns/
Design Patterns Classification
•
Creational Design Patterns
•
Structural Design Patterns
•
Behavioral Design Patterns
Creational Design Patterns
•
Singleton
•
Factory Method
•
Factory Pattern
•
Abstract Factory
•
Builder
•
Reusable Pool
•
Prototype
Singleton
Class Singleton
{private static Singleton
instance = null;
private Singleton() {};//private constructor
public static
synchronized
Singleton getInstance()
{if (instance == null) {instance =
new Singleton()
;
}
return instance
;
}
}
Abstract Factory Pattern
Abstract Factory Pattern
Builder
Prototype
Prototype
Shallow copy
Prototype
Shallow copy
copy
Prototype
Deep copy
Prototype
Deep copy
copy
copy
Reusable Pool
Structural Design Patterns
•
Adapter
•
Bridge (sometimes considered to be a behavioral DP)
•
Decorator
•
Composite
•
Facade
•
Proxy
•
and more
Adapter
Adapter
Adapter
Adapter
The Dependency Inversion Principle
•
High level modules should not depend upon low level
modules
;
both should depend on abstractions.
•
Abstractions should not depend upon details;
details should depend upon abstractions.
Dependency Inversion Principle
D
e
p
e
n
d
e
n
c
y
i
n
v
e
r
s
i
o
n
p
r
i
n
c
i
p
l
e
specific form of
decoupling
where conventional
dependency
relationships established from high-level
are inverted (e.g. reversed) for the purpose of rendering
high-level modules independent of the low-level module
implementation details. The principle states:
•
High-level modules should not depend on low-level
modules. Both should depend on abstractions.
•
Abstractions should not depend upon details.
Details should depend upon abstractions.
(
From Wikipedia, the free encyclopedia
)
The Dependency Inversion Principle
The Dependency Inversion Principle
D
e
p
e
n
d
s
o
n
Bridge
Jednoduché rozšíření předešlého diagramu
design pattern Bridge
Bridge
D
e
p
e
n
d
s
o
n
D
e
p
e
n
d
s
o
n
D
o
e
s
n
o
t
d
e
p
e
n
d
o
n
Bridge
Implementation
Abstraction
refinement
•
Máme více hledisek klasifikace.
•
Pokud bychom je chtěli zohlednit v jedné
inheritanční hierarchii, došlo by k explozi počtu
tříd (pro různé kombinace).
•
Řešení – oddělit klasifikační hlediska.
Bridge
Bridge
imp
+
d
r
a
w
L
i
n
e
(
)
:
v
o
i
d
Bridge
Bridge
imp
imp.devDrawLine();
imp.devDrawLine();
imp.devDrawLine();
imp.devDrawLine();
DrawRect();
DrawText();
XDrawLine();
XDrawString();
+
d
r
a
w
R
e
c
t
(
)
:
v
o
i
d
Bridge
Bridge
1.
The Bridge pattern is intended to keep the interface to your
client class constant while allowing you to change the actual
kind of class you use.
2.
You can extend the implementation class and the bridge class
separately, and usually without much interaction with each
other (avoiding permanent binding between abstraction and its
implementation).
3. You can hide implementation details from the client class
much more easily.
Decorator
Possible class explosion
(hard to maintain)
Decorator patterns helps ...
InputStream
ObjectInputStream
ObjectBufferedInputStream
BufferedInputStream
The Open-Close Design Principle
Software entities like classes, modules and functions should be
open for extension but closed for modifications.
Adding new functionality should involve minimal changes to
existing code.
=> adding new functionality will not break the old
functionality
=> old functionality need not be re-tested
Most changes will be handled as new methods and new classes.
Designs following this principle would result in resilient code which does
not break on addition of new functionality.
Decorator
(structural)
InputStream
Decorator
(structural)
InputStream
Buffered
Decorator
(structural)
Káva
S cukrem
Object
InputStream
Buffered
Decorator
(structural)
Decorator
(structural)
InputStream
Buffered
Object
Decorator
(structural)
InputStream is
= new
FileInputStream ("fff");
BufferedInputStream bis
= new
BufferedInputStream
(
is
);
ObjectInputStream ois
= new
ObjectInputStream(bis
);
BufferedInputStream bis = new BufferedInputStream(new FileInputStream("fff"));Decorator
(structural)
T
h
e
D
e
c
o
r
a
t
o
r
P
a
t
t
e
r
n
a
t
t
a
c
h
e
s
a
d
d
i
t
i
o
n
a
l
f
u
n
c
t
i
o
n
a
l
i
t
i
e
s
to an object dynamically.
Decorators provide a flexible alternative to subclassing
for extending functionality.
Decorator prevents explosion of (sub)classes.
Composite
(structural)
graphic
Abstract or interface
Returns Graphic
Composite
(structural)
graphic
Forall g in graphic
g.draw();
Add g to the graphic
list
Composite
(structural)
Composite
(structural)
Forwards the
operation to
all children
Default empty
implementation
Views all components
uniformly regardless
whether leaf or
composite
Façade
(structural)
A complex subsystem
The façade provides a unified
interface that is easier to use
Façade
(structural)
T
h
e
F
a
ç
a
d
e
P
a
t
t
e
r
n
p
r
o
v
i
d
e
s
a
u
n
i
f
i
e
d
i
n
t
e
r
f
a
c
e
t
o
a
s
e
t
of interfaces in a subsystem. Façade defines a higher-level
interface that makes the system easier to use.
D
e
s
i
g
n
P
r
i
n
c
i
p
l
e
Principle of least knowledge -
talk only to your immediate
friends.
Proxy
(structural)
T
h
e
P
r
o
x
y
P
a
t
t
e
r
n
p
r
o
v
i
d
e
s
a
s
u
r
r
o
g
a
t
e
o
r
p
l
a
c
e
h
o
l
d
e
r
f
o
r
a
n
o
t
h
e
r
o
b
j
e
c
t
t
o
a
c
c
e
s
s
c
o
n
t
r
o
l
t
o
i
t
.
Proxy
(structural)
W
i
t
h
R
e
m
o
t
e
P
r
o
x
y
,
t
h
e
p
r
o
x
y
a
c
t
a
s
a
l
o
c
a
l
r
e
p
r
e
s
e
n
t
a
t
i
v
e
f
o
r
a
n
o
b
j
e
c
t
t
h
a
t
l
i
v
e
s
i
n
a
d
i
f
f
e
r
e
n
t
J
V
M
.
Proxy
(structural)
V
i
r
t
u
a
l
P
r
o
x
y
a
c
t
s
a
s
a
r
e
p
r
e
s
e
n
t
a
t
i
v
e
f
o
r
a
n
o
b
j
e
c
t
t
h
a
t
m
a
y
b
e
e
x
p
e
n
s
i
v
e
t
o
c
r
e
a
t
e
.
T
h
e
v
i
r
t
u
a
l
p
r
o
x
y
o
f
t
e
n
d
e
f
e
r
s
c
r
e
a
t
i
o
n
o
f
t
h
e
o
b
j
e
c
t
u
n
t
i
l
i
t
i
s
n
e
e
d
e
d
.
A
f
t
e
r
t
h
a
t
,
t
h
e
v
i
r
t
u
a
l
p
r
o
x
y
d
e
l
e
g
a
t
e
s
r
e
q
u
e
s
t
s
t
o
t
h
e
R
e
a
l
S
u
b
j
e
c
t
.
Proxy
(structural)
Flyweight
(structural)
•
Intrinsic state is stored in the
ConcreteFlyweight
object
•
Extrinsic state is stored or computed by
Client
objects. Clients
pass this state to the flyweight when they invoke they operations
•
Clients should not instantiate
ConcreteFlyweights
directly.
Clients must obtain
ConcreteFlyweights
from the
FlyweightFactory
to ensure they are shared properly.
•
not all Flyweight objects need to be shared. It is common for
UnsharedConcreteFlyweight
objects to have
ConcreteFlyweight
objects as children.
Flyweight
(structural)
Pool of
flyweights
Flyweight
(structural)
Flyweight
(structural)
Flyweight
(structural)
Flyweight
SharedFlyweight
UnsharedFlyweight
UnsharedFlyweight
Behavioral Design Patterns
•
Command
•
Interpreter
•
Iterator
•
Mediator
•
Observer
•
State
•
Strategy
•
Visitor
Command
(behavioral)
C
o
m
m
a
n
d
r
e
p
r
e
s
e
n
t
s
a
n
a
b
s
t
r
a
c
t
a
l
g
o
r
i
t
h
m
i
n
d
e
p
e
n
d
e
n
t
o
n
:
1) The application of the command (Client)
2) The particular implementation of the command (Receiver)
Command
(behavioral)
C
o
m
m
a
n
d
e
n
c
a
p
s
u
l
a
t
e
s
a
r
e
q
u
e
s
t
a
s
a
n
o
b
j
e
c
t
,
t
h
e
r
e
b
y
l
e
t
t
i
n
g
y
o
u
p
a
r
a
m
e
t
r
i
z
e
o
t
h
e
r
o
b
j
e
c
t
s
w
i
t
h
d
i
f
f
e
r
e
n
t
r
e
q
u
e
s
t
s
,
q
u
e
u
e
o
r
l
o
g
r
e
q
u
e
s
t
s
a
n
d
s
u
p
p
o
r
t
u
n
d
o
a
b
l
e
o
p
e
r
a
t
i
o
n
s
.
Command
(behavioral)
Command
(behavioral)
Command
(behavioral)
•
Command decouples the object that invokes the operation from
the one that knows how to perform it.
•
You can assemble commands into a composite command
(composite commands are instances of Composite pattern)
•
Easy to add new commands.
Behavioral Design Patterns
Behavioral
Class
Patterns
Behavioral
Object
Patterns
Other
Behavioral Patterns
Use inheritance to distribute behaviour between classes
•
Template Method
•
Interpreter
Use composition rather than inheritance to distribute behaviour between objects
•
Mediator
•
Chain of Responsibility
•
Observer
•
Strategy
•
Command
•
Visitor
•
Iterator
Template Method
Strategy
(behavioral)
Strategy
(behavioral)
T
h
e
S
t
r
a
t
e
g
y
P
a
t
t
e
r
n
d
e
f
i
n
e
s
a
f
a
m
i
l
y
o
f
a
l
g
o
r
i
t
h
m
s
,
e
n
c
a
p
s
u
l
a
t
e
s
e
a
c
h
o
n
e
,
a
n
d
m
a
k
e
s
t
h
e
m
i
n
t
e
r
c
h
a
n
g
e
a
b
l
e
.
S
t
a
r
t
e
g
y
l
e
t
s
t
h
e
a
l
g
o
r
i
t
h
m
v
a
r
y
i
n
d
e
p
e
n
d
e
n
t
l
y
f
r
o
m
c
l
i
e
n
t
s
t
h
a
t
u
s
e
i
t
.
D
e
s
i
n
g
P
r
i
n
c
i
p
a
l
Favor composition over inheritance.
Observer
(behavioral)
Subject
Observer1
Observer2
Observer3
notify()
notify()
notify()
An object holding
a state and notifying
its observers about state’s
change.
The aim is to make subject independent on observers
- loose coupling.
Observer
(behavioral)
Observer
(behavioral)
Observer
(behavioral)
D
e
s
i
n
g
P
r
i
n
c
i
p
l
e
Loosely coupled designs allows us to build flexible OO
systems that can handle change because they
minimize the interdependency between objects.
Mediator
(behavioral)
•
define an object that encapsulates how a set of objects
interacts
•
mediator promotes loose coupling by keeping objects from
refering to each other explicitly
•
it lets you vary their interactions independently
Mediator
Mediator
(behavioral)
Mediator
(behavioral)
State
(behavioral)
S
t
a
t
e
P
a
t
t
e
r
n
a
l
l
o
w
s
a
n
o
b
j
e
c
t
t
o
a
l
t
e
r
i
t
s
b
e
h
a
v
i
o
r
w
h
e
n
i
t
s
i
n
t
e
r
n
a
l
s
t
a
t
e
c
h
a
n
g
e
s
.
Visitor
(behavioral)
v.visitConcreteElementA
(this)
Visitor
(behavioral)
Visitor
(behavioral)
•
Visitor makes adding new operations
easy
simply by adding a new visitor
•
A visitor gathers related operations and separates
unrelated ones
•
Adding new ConcreteElement classes is
hard
Is mostly likely to change the algorithm or the classes
of objects that make up the structure?
•
Visitor can accumulate state as they visit each element
Explore the world of design patterns with a focus on Java, covering key concepts such as creational, structural, and behavioral patterns. Learn about popular patterns like Singleton, Abstract Factory, Builder, and Prototype with practical examples and explanations.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Thinking in Patterns with Java Bruce Eckel http://www.mindview.net/Books/TIPatterns/
Design Patterns Classification Creational Design Patterns Structural Design Patterns Behavioral Design Patterns
Creational Design Patterns Singleton Factory Method Factory Pattern Abstract Factory Builder Reusable Pool Prototype
Singleton Class Singleton { private static Singleton instance = null; private Singleton() {}; //private constructor public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } }
Abstract Factory Pattern Specialised class just to create an instance of Product Client Factory Product <<abstract nebo interface>> <<abstract nebo interface>> ConcreteFactory ConcreteProduct public Product createProduct() createProduct() { return new ConcreteProduct(); }
Abstract Factory Pattern Window ClientClass <<abstract nebo interface>> WidgetFactory <<abstract nebo interface>> MotifWindow MetalWindow + createWindow() + createScrollBar() ScrollBar <<abstract nebo interface>> MotifScrollbar MetalScrollBar MotifFactory + createWindow() + createScrollBar() MetalFactory + createWindow() + createScrollBar()
Builder AbstractBuilder <<abstract or interface>> Director + builder + buildStep1() + buildStep2() + buildStep3() + getObject() + construct() construct() { builder.buidlStep1(); builder.buildStep2(); buidler.buildStep3(); getObject(); } ConcreteBuilder1 ConcreteBuilder2
Prototype AbstractPrototype <<abstract or interface>> use clone to instantiate Client + clone() ConcretePrototype1 ConcretePrototype2 clone() { // return copy of self } clone() { // return copy of self }
Prototype Shallow copy
Prototype Shallow copy copy
Prototype Deep copy
Prototype Deep copy copy copy
Reusable Pool + pool Client 0..* 1 1 ReusablePool <<singleton>> uses + acquireReusable(): Reusable + releaseReusable(): Reusable 1 * Reusable 0..*
Structural Design Patterns Adapter Bridge (sometimes considered to be a behavioral DP) Decorator Composite Facade Proxy and more
Adapter Vendor class Client class
Adapter Vendor class Adapter Client class
Adapter Vendor class Client class Adapter
Adapter Target <<interface>> Client request() Adapter Adaptee request() specificRequest()
The Dependency Inversion Principle High level modules should not depend upon low level modules; both should depend on abstractions. Abstractions should not depend upon details; details should depend upon abstractions.
Dependency Inversion Principle Dependency inversion principle specific form of decoupling where conventional dependency relationships established from high-level are inverted (e.g. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. The principle states: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. (From Wikipedia, the free encyclopedia)
The Dependency Inversion Principle Depends on
Bridge Jednoduch roz en p ede l ho diagramu design pattern Bridge
Bridge Depends on Does not depend on Depends on
Bridge Implementation M me v ce hledisek klasifikace. Pokud bychom je cht li zohlednit v jedn inheritan n hierarchii, do lo by k explozi po tu t d (pro r zn kombinace). e en odd lit klasifika n hlediska. Abstraction refinement
Bridge Bridge imp + drawLine(): void
Bridge imp.devDrawLine(); imp.devDrawLine(); imp.devDrawLine(); imp.devDrawLine(); Bridge imp + drawRect(): void DrawRect(); DrawText(); XDrawLine(); XDrawString();
Bridge AbstractProvider <<interface>> AbstractUser <<abstract or interface>> provider + oper1() + oper2() + operation() User1 User2 Provider2 Provider1 + operation() + operation() + oper1() + oper2() + oper1() + oper2() operation() { provider.oper1(); } operation() { provider.oper2(); }
Bridge 1. The Bridge pattern is intended to keep the interface to your client class constant while allowing you to change the actual kind of class you use. 2. You can extend the implementation class and the bridge class separately, and usually without much interaction with each other (avoiding permanent binding between abstraction and its implementation). 3. You can hide implementation details from the client class much more easily.
Decorator InputStream ObjectInputStream ObjectBufferedInputStream BufferedInputStream Possible class explosion (hard to maintain) Decorator patterns helps ...
The Open-Close Design Principle Software entities like classes, modules and functions should be open for extension but closed for modifications. Adding new functionality should involve minimal changes to existing code. => adding new functionality will not break the old functionality => old functionality need not be re-tested Most changes will be handled as new methods and new classes. Designs following this principle would result in resilient code which does not break on addition of new functionality.
Decorator (structural) InputStream
Decorator (structural) InputStream Buffered
Decorator (structural) Object S cukrem Buffered InputStream K va
Decorator (structural) Component << abstract >> 1 ClientClass methodA() methodB() // other methods Decorator << abstract >> ConcreteComponent 0..1 methodA() methodB() // other methods methodA() methodB() // other methods ConcreteDecoratorA ConcreteDecoratorB methodA() methodB() // other methods methodA() methodB() // other methods
Decorator (structural) Component << abstract >> 1 ClientClass methodA() methodB() // other methods Decorator << abstract >> ConcreteComponent 0..1 methodA() methodB() // other methods methodA() methodB() // other methods Object ConcreteDecoratorA ConcreteDecoratorB InputStream methodA() methodB() // other methods methodA() methodB() // other methods Buffered
Decorator (structural) InputStream is = new FileInputStream ("fff"); BufferedInputStream bis = new BufferedInputStream(is); ObjectInputStream ois = new ObjectInputStream(bis); BufferedInputStream bis = new BufferedInputStream(new FileInputStream("fff"));
Decorator (structural) The Decorator Pattern attaches additional functionalities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Decorator prevents explosion of (sub)classes.
Composite (structural) Abstract or interface graphic Returns Graphic
Composite (structural) graphic Forall g in graphic g.draw(); Add g to the graphic list
Composite (structural) uniformly regardless whether leaf or composite Views all components Default empty implementation Forwards the operation to all children
Faade (structural) Client Facade The fa ade provides a unified interface that is easier to use A B C D E F A complex subsystem
Faade (structural) The Fa ade Pattern provides a unified interface to a set of interfaces in a subsystem. Fa ade defines a higher-level interface that makes the system easier to use. Client Facade Design Principle Principle of least knowledge - talk only to your immediate friends. A B C D E F
Proxy (structural) request() request() Client Real Subject Proxy The Proxy Pattern provides a surrogate or placeholder for another object to access control to it.
Proxy (structural) request() request() Client Real Subject Proxy A remote object With Remote Proxy, the proxy act as a local representative for an object that lives in a different JVM.
Proxy (structural) request() request() Client Real Subject Proxy Virtual Proxy acts as a representative for an object that may be expensive to create. The virtual proxy often defers creation of the object until it is needed. After that, the virtual proxy delegates requests to the RealSubject.
Proxy (structural) <<interface>> Subject request() Proxy RealSubject subject request() request() The RealSubject does most of the work. The Proxy controls access to it. The Proxy often instantiates or handles creation of the RealSubject.
Flyweight (structural) Intrinsic state is stored in the ConcreteFlyweight object Extrinsic state is stored or computed by Client objects. Clients pass this state to the flyweight when they invoke they operations Clients should not instantiate ConcreteFlyweights directly. Clients must obtain ConcreteFlyweights from the FlyweightFactory to ensure they are shared properly. not all Flyweight objects need to be shared. It is common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children.
