design patterns illustrated-2015-03

98
Design Patterns illustrated Herman Peeren, March 17, 2015 (Design Patterns illustrations: Nelleke Verhoeff, 2010) in this presentation I also used some UML-diagrams from these handy UML-reference cards: http://www.mcdonaldland.info/2007/11/28/40/

Upload: herman-peeren

Post on 14-Jul-2015

275 views

Category:

Software


0 download

TRANSCRIPT

Page 1: Design patterns illustrated-2015-03

Design Patterns illustrated

Herman Peeren, March 17, 2015(Design Patterns illustrations: Nelleke Verhoeff, 2010)

in this presentation I also used some UML-diagramsfrom these handy UML-reference cards:http://www.mcdonaldland.info/2007/11/28/40/

Page 2: Design patterns illustrated-2015-03

Design Patterns ● recipes against common (OO-) programming problems ● code reuse: no need to reinvent the wheel ● common language ● GOF: 23 “classical” patterns

classic, The Book

四人帮

Page 3: Design patterns illustrated-2015-03

The one constant in software development:

Page 4: Design patterns illustrated-2015-03

CHANGE!The one constant in software development:

Page 5: Design patterns illustrated-2015-03

CHANGE!The one constant in software development:

I knew it ...

Page 6: Design patterns illustrated-2015-03

Ideal: code as modular black boxes

Page 7: Design patterns illustrated-2015-03

Single responsibility principle

Open for extension, closed for modification

Liskov subsitution principle

Interface segregation

Dependency inversion

Page 8: Design patterns illustrated-2015-03

Avoid: tight coupling!

Page 9: Design patterns illustrated-2015-03

It might get you into trouble...

Page 10: Design patterns illustrated-2015-03

Code smells!

Beware of:

Page 11: Design patterns illustrated-2015-03

some code smells: ► duplicate code ► long method ► large class ► combinatorial explosion ► conditional complexity ► switch statements ► indecent exposure

Page 12: Design patterns illustrated-2015-03

Code often starts simple

But “grows”:

► more methods in a class

► longer methods

► more if then but if then while x>0 or and etc.

► more classes, that depends on other classes

and becomes more complex

Page 13: Design patterns illustrated-2015-03

Example: a shopping cart

► implement putting products in the cart

► start with some pay() method

► if paypal then..., if iDEAL then...

► let’s extract a payment interface

► with several implementations (paypal, iDEAL, etc)

► mutually exclusive choices

each choice is a “strategy” (hurray, our first pattern!)

Page 14: Design patterns illustrated-2015-03

Encapsulate what varies

Page 15: Design patterns illustrated-2015-03

Strategy pattern

For instance: different payment possibilities at checkout

Page 16: Design patterns illustrated-2015-03

Replace Conditional Logic with Strategy if ($income <= 10000) { return $income*0.365; } else if ($income <= 30000) { return ($income-10000)*0.2+35600; } else //etc (...) return ($income-60000)*0.02+105600; } // note: mutual exclusive grouping

if ($income <= 100000) { $strategy = new InsuranceStrategyLow($income); } else if ($income <= 300000) { $strategy = new InsuranceStrategyMedium($income); } else //etc (...) $strategy = new InsuranceStrategyVeryHigh($income); } return $strategy->calculateInsurance();

http://wiki.jetbrains.net/intellij/Replace_conditional_logic_with_strategy_pattern

Page 17: Design patterns illustrated-2015-03

StrategyWhen something can be done in several ways, make those ways interchangeable.

POSSI-BILITIES

yep

r

Page 18: Design patterns illustrated-2015-03

State example: states of a document

► a draft doesn’t need a depublish() method

► a published document doesn’t need a publish() method

or states of a shopping-cart

► while shopping you don’t need a pay() method

► but you need methods to put product in or out the cart

► when paid you don’t need a pay() method

► nor put_product_in_cart()

Page 19: Design patterns illustrated-2015-03

StateLet an object show other methods after a change of internal state (as if it changes it’s class).

in a.....hick......different state, ....hick....I behave differently....hick.....

c© yepr

Page 20: Design patterns illustrated-2015-03

Bridge example: payment and payment providers

Page 21: Design patterns illustrated-2015-03

BridgeDecouple an abstraction from its implementation.

c

COLA

COLA

COLA

COLA

1 LITER

1 LITER

COLA

MILK

MILK

1 LITER

1 LITER

MILK

© y

epr

Page 22: Design patterns illustrated-2015-03

Create those objects

Page 23: Design patterns illustrated-2015-03

Factory method example: different kinds of customers...

Page 24: Design patterns illustrated-2015-03

...with different kinds of invoices

Page 25: Design patterns illustrated-2015-03

Factory MethodProvide an interface for the creation of objects.Allow subclasses to “decide” which class to instantiate.

yep

r

Page 26: Design patterns illustrated-2015-03

Abstract factory example: a Gold customer, cart, invoice, etc.

Page 27: Design patterns illustrated-2015-03

Abstract FactoryPovide an interface for creating families of related or dependent objects. A factory for factories.

yep

r

Page 28: Design patterns illustrated-2015-03

Building (complex) objects

Example: DI-container

Other example: documentbuilder (for tree-like structures):

/$domtree = new DOMDocument(‘1.0’, ‘UTF-8’);

/* create the root element of the xml tree */$xmlRoot = $domtree->createElement(“xml”);/* append it to the document created */$xmlRoot = $domtree->appendChild($xmlRoot);

$currentTrack = $domtree->createElement(“track”);$currentTrack = $xmlRoot->appendChild($currentTrack);// etc...

Page 29: Design patterns illustrated-2015-03

BuilderSeperate the construction process (how) of a complex object from the concrete representations (what).

yep

r

Page 30: Design patterns illustrated-2015-03

Encapsulate what doesn’t vary...

Page 31: Design patterns illustrated-2015-03

Template MethodThe skeleton of an algorithm is fixed, but parts can be filled in differently.

yep

r

Page 32: Design patterns illustrated-2015-03

Add behaviour

► but respect the Open-Closed principle

Page 33: Design patterns illustrated-2015-03

Decorator

Page 34: Design patterns illustrated-2015-03

In PHP you can use __call to copy parent methods:

public function __call($method, $args) { return call_user_func_array( array($this->decoratedInstance, $method), $args );}

N.B.: Magic functions are magic... but come at a cost!

Page 35: Design patterns illustrated-2015-03

DecoratorAdd extra functionallity (at runtime), while keeping the interface the same. Matroushka’s...

c© ye

pr

Page 36: Design patterns illustrated-2015-03

Move Accumulation to Visitor

Page 37: Design patterns illustrated-2015-03

VisitorMake a kind of plugin-possibility for methods: in that way methods can be added in runtime.

printservice!

yep

r

Page 38: Design patterns illustrated-2015-03

CompositeCreate a tree structure for part-whole hierarchies. A node is also a (part of a) tree. Recursive:

yep

r

Page 39: Design patterns illustrated-2015-03

Interfacing

Page 40: Design patterns illustrated-2015-03

Unify interfaces with Adapter:For instance: different payment gateways (PayPal, iDEAL, Hipay, Moneybookers, etc.)

Instead of different interfaces refactor to

one preferred interfaceand write adapters for the others

Page 41: Design patterns illustrated-2015-03

Adapter (= Wrapper)Adapt an interface to an expected interface.

yep

r

Page 42: Design patterns illustrated-2015-03

ProxyProvide a surrogate or placeholder for another object to control access to it.

yep

r

Page 43: Design patterns illustrated-2015-03

FacadeProvide a general (simpler) interface for a set of interfaces.

lookssimple

yep

r

Page 44: Design patterns illustrated-2015-03

Decoupling

Page 45: Design patterns illustrated-2015-03

ObserverNotify “subscribers” of changes.

WHO?

ME

ME

MENO

yep

r

Page 46: Design patterns illustrated-2015-03

MediatorLayer in between: communication via one object.

yep

r

Page 47: Design patterns illustrated-2015-03

Undo

Page 48: Design patterns illustrated-2015-03

MementoSave and restore the internal state of an object.

ME

c© ye

pr

Page 49: Design patterns illustrated-2015-03

Sequence of actions

Page 50: Design patterns illustrated-2015-03

Chain of ResponsibilityDefine a method of passing a request among a chain of objects.

c© ye

pr

Page 51: Design patterns illustrated-2015-03

A command is an object to execute 1 method

Decoupling (Symfony2) Forms from Entities:http://verraes.net/2013/04/decoupling-symfony2-forms-from-entities/

Chain of Command: Chain of Responsability with Commands

Replace Conditional Dispatcher with Commandif ($actionName == NEW_WORKSHOP) { //do a lot} else if ($actionName == ALL_WORKSHOPS) { // do a lot of other things } // and many more elseif-statements

NewWorkshopHandler, AllWorkshopsHandler, etc.

Page 52: Design patterns illustrated-2015-03

CommandEncapsulate a command request in an object.

c

YOU,DO YOURTASK!

LIGHTOFF

LIGHTON

TASKTASK

© y

epr

Page 53: Design patterns illustrated-2015-03

Leftovers

Page 54: Design patterns illustrated-2015-03

FlyweightUse one instance of a class to provide many “virtual” instances.

yep

r

Page 55: Design patterns illustrated-2015-03

PHP: SPL iterators

► http://www.php.net/manual/en/class.iterator.php ► http://www.php.net/manual/en/spl.iterators.php

Stefan Froelich: ► http://www.sitepoint.com/using-spl-iterators-1/ ► http://www.sitepoint.com/using-spl-iterators-2/

Anthony Ferrara video: ► http://blog.ircmaxell.com/2013/01/todays-programming-with-anthony-vi-

deo.html

Page 56: Design patterns illustrated-2015-03

IteratorEnable sequential access to collection elements, without showing the underlying data-structures (array, list, records, etc)

nextnext

next

yep

r

Page 57: Design patterns illustrated-2015-03

Replace implicit language with Interpreter:

search-methods including combinations: ► belowPriceAvoidingAColor( ) ► byColorAndBelowPrice( ) ► byColorSizeAndBelowPrice( )

interpretable expression:$productSpec = new AndSpec( new BelowPriceSpec(9.00), new NotSpec(newColorSpec(WHITE)) );

“You don’t need an Interpreter for complex languages or for really simple ones.” (Joshua Kerievsky)

Page 58: Design patterns illustrated-2015-03

InterpreterDomain -> (little) language -> grammar -> objects (DSL)

he means:do this, do that,

and after finishing it, go there!

HÉ!HÉ!

yep

r

Page 59: Design patterns illustrated-2015-03

Javascript:var Person = function() { // bladibla };var Customer = function(name) { this.name = name;};Customer.prototype = new Person();

Prototype in PHP: ► adding properties is easy ► adding behaviour is less obvious, but... ► CLOSURES can help here, with some (dirty) tricks

Page 60: Design patterns illustrated-2015-03

PrototypeMake variations on copies of a basic-object.

COPY-SERVICE

yep

r

Page 61: Design patterns illustrated-2015-03

SingletonEnsure a class only has one instance, and provide a global point of access to it.

Oh, I’m soloooooooonly

c© ye

pr

Page 62: Design patterns illustrated-2015-03

SingletonEnsure a class only has one instance, and provide a global point of access to it. Did anybody say GLOBAL???

Oh, I’m soloooooooonly

c BANN

ED!

© y

epr

Page 63: Design patterns illustrated-2015-03

“Every advantage

has its disadvantages”

(free to Johan Cruyff, Dutch Football Pattern Designer and Ajax-fan...)

Page 64: Design patterns illustrated-2015-03

Résumé

Page 65: Design patterns illustrated-2015-03

Classic pattern categories

creational, structural and behavioral patterns:

► creational: object instantiation

► structural: larger structures of classes or objects

► behavioral: interaction and distribution of responsibility

Page 66: Design patterns illustrated-2015-03

Other categorisations

Loek Bergman (dev. from Rotterdam):

► transformational

► transportational

► translational

Anthony Ferrara:

► Shim : not necessary (for PHP)

► decompositional: breaking objects apart

► compositional: making things simpler by assembling

http://loekbergman.nl/InsideArchitecture

http://blog.ircmaxell.com/2013/09/beyond-design-patterns.html

Page 67: Design patterns illustrated-2015-03

Creational design patterns

► Factory Method: Allow subclasses to “decide” which class to instantiate.

► Abstract Factory: Encapsulate a set of analo- gous factories that produce families of objects.

► Builder: Encapsulate the construction of com- plex objects from their representation; so, the same building process can create various repre- sentations by specifying only type and content.

► Singleton: Ensure that only a single instance of a class exists and provide a single method for gaining access to it.

► Prototype: Create an initialized instance for cloning or copying.

Page 68: Design patterns illustrated-2015-03

Factory MethodProvide an interface for the creation of objects.Allow subclasses to “decide” which class to instantiate.

yep

r

Page 69: Design patterns illustrated-2015-03

Abstract FactoryPovide an interface for creating families of related or dependent objects. A factory for factories.

yep

r

Page 70: Design patterns illustrated-2015-03

BuilderSeperate the construction process (how) of a complex object from the concrete representations (what).

yep

r

Page 71: Design patterns illustrated-2015-03

SingletonEnsure a class only has one instance, and provide a global point of access to it.

Oh, I’m soloooooooonly

c© ye

pr

Page 72: Design patterns illustrated-2015-03

SingletonEnsure a class only has one instance, and provide a global point of access to it. Did anybody say GLOBAL???

Oh, I’m soloooooooonly

c BANN

ED!

© y

epr

Page 73: Design patterns illustrated-2015-03

PrototypeMake variations on copies of a basic-object.

COPY-SERVICE

yep

r

Page 74: Design patterns illustrated-2015-03

Structural design patterns ● Adapter: Adapt an interface to an expected interface.

● Bridge: Decouple an interface from its implementation.

● Composite: Create a tree structure for part-whole hierarchies.

● Decorator: Extend functionality dynamically.

● Facade: Simplify usage by defining a high-level interface.

● Flyweight: Support fine-grained objects efficiently by sharing.

● Proxy: Represent an object with another object for access control.

Page 75: Design patterns illustrated-2015-03

Adapter (= Wrapper)Adapt an interface to an expected interface.

yep

r

Page 76: Design patterns illustrated-2015-03

BridgeDecouple an abstraction from its implementation.

c

COLA

COLA

COLA

COLA

1 LITER

1 LITER

COLA

MILK

MILK

1 LITER

1 LITER

MILK

© y

epr

Page 77: Design patterns illustrated-2015-03

CompositeCreate a tree structure for part-whole hierarchies. A node is also a (part of a) tree. Recursive:

yep

r

Page 78: Design patterns illustrated-2015-03

DecoratorAdd extra functionallity (at runtime), while keeping the interface the same. Matroushka’s...

c© ye

pr

Page 79: Design patterns illustrated-2015-03

FacadeProvide a general (simpler) interface for a set of interfaces.

lookssimple

yep

r

Page 80: Design patterns illustrated-2015-03

FlyweightUse one instance of a class to provide many “virtual” instances.

yep

r

Page 81: Design patterns illustrated-2015-03

ProxyProvide a surrogate or placeholder for another object to control access to it.

yep

r

Page 82: Design patterns illustrated-2015-03

Behavioral design patterns ● Chain of Responsibility: Define a method of passing a request among a chain of objects. ● Command: Encapsulate a command request in an object. ● Interpreter: Allow inclusion of language elements in an appli-cation. ● Iterator: Enable sequential access to collection elements. ● Mediator: Define simplified communication between classes. ● Memento: Save and restore the internal state of an object. ● Observer: Define a scheme for notifying objects of changes to another object. ● State: Alter the behavior of an object when its state changes. ● Strategy: Encapsulate an algorithm inside a class. ● Template Method: Allow subclasses to redefine the steps of an algorithm. ● Visitor: Define a new operation on a class without changing it.

Page 83: Design patterns illustrated-2015-03

CommandEncapsulate a command request in an object.

c

YOU,DO YOURTASK!

LIGHTOFF

LIGHTON

TASKTASK

© y

epr

Page 84: Design patterns illustrated-2015-03

Chain of ResponsibilityDefine a method of passing a request among a chain of objects.

c© ye

pr

Page 85: Design patterns illustrated-2015-03

InterpreterDomain -> (little) language -> grammar -> objects (DSL)

he means:do this, do that,

and after finishing it, go there!

HÉ!HÉ!

yep

r

Page 86: Design patterns illustrated-2015-03

IteratorEnable sequential access to collection elements, without showing the underlying data-structures (array, list, records, etc)

nextnext

next

yep

r

Page 87: Design patterns illustrated-2015-03

MediatorLayer in between: communication via one object.

yep

r

Page 88: Design patterns illustrated-2015-03

MementoSave and restore the internal state of an object.

ME

c© ye

pr

Page 89: Design patterns illustrated-2015-03

ObserverNotify “subscribers” of changes.

WHO?

ME

ME

MENO

yep

r

Page 90: Design patterns illustrated-2015-03

StateLet an object show other methods after a change of internal state (as if it changes it’s class).

in a.....hick......different state, ....hick....I behave differently....hick.....

c© yepr

Page 91: Design patterns illustrated-2015-03

StrategyWhen something can be done in several ways, make those ways interchangeable.

POSSI-BILITIES

yep

r

Page 92: Design patterns illustrated-2015-03

Template MethodThe skeleton of an algorithm is fixed, but parts can be filled in differently.

yep

r

Page 93: Design patterns illustrated-2015-03

VisitorMake a kind of plugin-possibility for methods: in that way methods can be added in runtime.

printservice!

yep

r

Page 94: Design patterns illustrated-2015-03

Some booksGOF: 23 “classical” patterns:

classic, The Book

fun!

good start

Page 95: Design patterns illustrated-2015-03

Dec. 2013Simple

Febr. 2013Selection

PHP-examples

PHP and Design Patterns

Page 96: Design patterns illustrated-2015-03

Fowler: architectural patterns for enterprise applications

Fowler: also known from refactoring

Kerievsky: refactoring to patterns

PEAA & Refactoring

Page 97: Design patterns illustrated-2015-03

Resign Patterns: Ailments of Unsuitable Project-Disoriented Software

Page 98: Design patterns illustrated-2015-03

Questions?

Contact info:Herman [email protected]

© YeprDesign Pattern Illustrations: Nelleke Verhoeff, Red Cheeks Factory, 2010 Creative Commons Public License for noncommercial use http://creativecommons.org/licenses/by-nc/3.0/legalcode