From c64c344f0ff3467e971b8d376b4540ac897c87f8 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 09:46:18 +0200 Subject: [PATCH 01/29] added README for Command pattern --- Command/CommandInterface.php | 20 +------------------- Command/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 19 deletions(-) create mode 100644 Command/README.md diff --git a/Command/CommandInterface.php b/Command/CommandInterface.php index 8fe9c5b..ebdbb85 100644 --- a/Command/CommandInterface.php +++ b/Command/CommandInterface.php @@ -3,25 +3,7 @@ namespace DesignPatterns\Command; /** - * Command pattern - * - * Purpose: To encapsulate invocation and decoupling - * - * We have an Invoker and a Receiver. This pattern use a "Command" to delegate the - * method call against the Receiver and presents the same method "execute". - * Therefore, the Invoker just know to call "execute" to process the Command of - * the client. The Receiver is decoupled from the Invoker - * - * The second aspect of ths pattern is the undo(), which undoes the method execute() - * Command can also be agregated to combine more complex commands with minimum - * copy-paste and relying on composition over inheritance. - * - * Examples: - * - A text editor : all events are Command which can be undone, stacked and saved. - * - Symfony2: SF2 Commands that can be run from the CLI are built with just the Command pattern in mind - * - big CLI tools use subcommands to distribute various tasks and pack them in "modules", each of these - * can be implemented with the Command pattern (e.g. vagrant) - * + * class CommandInterface */ interface CommandInterface { diff --git a/Command/README.md b/Command/README.md new file mode 100644 index 0000000..4797c8e --- /dev/null +++ b/Command/README.md @@ -0,0 +1,17 @@ +# Command + +## Purpose + +To encapsulate invocation and decoupling. + +We have an Invoker and a Receiver. This pattern use a "Command" to delegate the method call against the Receiver and presents the same method "execute". +Therefore, the Invoker just knows to call "execute" to process the Command of the client. The Receiver is decoupled from the Invoker. + +The second aspect of ths pattern is the undo(), which undoes the method execute(). +Command can also be aggregated to combine more complex commands with minimum copy-paste and relying on composition over inheritance. + +## Examples + +* A text editor : all events are Command which can be undone, stacked and saved. +* Symfony2: SF2 Commands that can be run from the CLI are built with just the Command pattern in mind +* big CLI tools use subcommands to distribute various tasks and pack them in "modules", each of these can be implemented with the Command pattern (e.g. vagrant) From fe6127044ecf579bddb98859683613aa95319545 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 09:49:29 +0200 Subject: [PATCH 02/29] added README in ChainOfResponsibilities --- ChainOfResponsibilities/README.md | 13 ++++++------- ChainOfResponsibilities/Request.php | 8 ++++---- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/ChainOfResponsibilities/README.md b/ChainOfResponsibilities/README.md index 44496bf..462f6c1 100644 --- a/ChainOfResponsibilities/README.md +++ b/ChainOfResponsibilities/README.md @@ -1,13 +1,12 @@ -# chain of responsibilities +# Chain Of Responsibilities ## Purpose: -To build a chain of objects to handle a call. if one object cannot handle a call, it delegates the call to the next -in the chain and so forth +To build a chain of objects to handle a call. If one object cannot handle a call, it delegates the call to the next in the chain and so forth. ## Examples: -* logging framework -* spam filter - Caching: first object is an instance of e.g. a Memcached Interface, if that "misses" it delegates the call to the database interface -* Yii Framework: CFilterChain is a chain of controller action filters. the executing point is passed from one filter to the next along the chain, and only if all filters say "yes", the action can be invoked at last. \ No newline at end of file +* logging framework, where each chain element decides autonomously what to do with a log message +* a Spam filter +* Caching: first object is an instance of e.g. a Memcached Interface, if that "misses" it delegates the call to the database interface +* Yii Framework: CFilterChain is a chain of controller action filters. the executing point is passed from one filter to the next along the chain, and only if all filters say "yes", the action can be invoked at last. diff --git a/ChainOfResponsibilities/Request.php b/ChainOfResponsibilities/Request.php index 501446a..c50e18e 100644 --- a/ChainOfResponsibilities/Request.php +++ b/ChainOfResponsibilities/Request.php @@ -3,14 +3,14 @@ namespace DesignPatterns\ChainOfResponsibilities; /** - * Request is a request which goes throught the chain of responsibilities. + * Request is a request which goes through the chain of responsibilities. * * About the request : Sometimes, you don't need an object, just an integer or * an array. But in this case of a full example, I've made a class to illustrate * this important idea in the CoR (Chain of Responsibilities). In real world, - * I recommand to always use a class, even a \stdClass if you want, it proves - * to be more adaptative because a single handler doesn't know much about the - * outside world and it is more difficult if, one day, you want add some + * I recommend to always use a class, even a \stdClass if you want, it proves + * to be more adaptive because a single handler doesn't know much about the + * outside world and it is more difficult if, one day, you want to add some * criterion in a decision process. */ class Request From ea3e477a74e2a3df21cef7326bed19b2dd357bda Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:01:41 +0200 Subject: [PATCH 03/29] README in Visitor --- Visitor/README.md | 8 ++++++++ Visitor/Role.php | 9 +-------- 2 files changed, 9 insertions(+), 8 deletions(-) create mode 100644 Visitor/README.md diff --git a/Visitor/README.md b/Visitor/README.md new file mode 100644 index 0000000..1ad8cc0 --- /dev/null +++ b/Visitor/README.md @@ -0,0 +1,8 @@ +# Visitor + +## Purpose + +The Visitor Pattern lets you outsource operations on objects to other objects. The main reason to do this is to keep a separation of concerns. +But classes have to define a contract to allow visitors (the `Role::accept` method in the example). + +The contract is an abstract class but you can have also a clean interface. In that case, each Visitor has to choose itself which method to invoke on the visitor. diff --git a/Visitor/Role.php b/Visitor/Role.php index 6f5a0c4..b4873ce 100644 --- a/Visitor/Role.php +++ b/Visitor/Role.php @@ -3,14 +3,7 @@ namespace DesignPatterns\Visitor; /** - * Visitor Pattern - * - * Purpose: - * The Visitor Pattern lets you outsource operations on objects to other objects. The main reason to do this is to keep - * a separation of concerns. But classes have to define an contract to allow visitors (the "accept" method in the example below). - * - * The contract is an abstract class but you can have also a clean interface. - * In that case, each Visitor has to choose itself which method to invoke on the visitor. + * class Role */ abstract class Role { From c5d0030f5f380cf9d1fe3bc3a31048f3cfb226c5 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:03:40 +0200 Subject: [PATCH 04/29] README in TemplateMethod --- TemplateMethod/Journey.php | 16 +--------------- TemplateMethod/README.md | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 15 deletions(-) create mode 100644 TemplateMethod/README.md diff --git a/TemplateMethod/Journey.php b/TemplateMethod/Journey.php index 5255b97..f5e666d 100644 --- a/TemplateMethod/Journey.php +++ b/TemplateMethod/Journey.php @@ -3,21 +3,7 @@ namespace DesignPatterns\TemplateMethod; /** - * Template Method is a behavioral design pattern. - * - * Perhaps you have encountered it many times already. The idea is to let subclasses - * of this abstract template "finish" the behavior of an algorithm. - * - * A.k.a the "Hollywood principle" : "" Don't call us, we call you. "" - * This class is not called by subclasses but the inverse. - * How ? With abstraction of course. - * - * In other words, this is a skeleton of algorithm, well-suited for framework - * libraries. The user has just to implement one method and the superclass do - * the job. - * - * It is an easy way to decouple concrete classes and reduce copy-paste, - * that's why you'll find it everywhere. + * */ abstract class Journey { diff --git a/TemplateMethod/README.md b/TemplateMethod/README.md new file mode 100644 index 0000000..ce435d2 --- /dev/null +++ b/TemplateMethod/README.md @@ -0,0 +1,14 @@ +# Template Method + +## Purpose + +Template Method is a behavioral design pattern. + +Perhaps you have encountered it many times already. The idea is to let subclasses of this abstract template "finish" the behavior of an algorithm. + +A.k.a the "Hollywood principle": "Don't call us, we call you." This class is not called by subclasses but the inverse. +How? With abstraction of course. + +In other words, this is a skeleton of algorithm, well-suited for framework libraries. The user has just to implement one method and the superclass do the job. + +It is an easy way to decouple concrete classes and reduce copy-paste, that's why you'll find it everywhere. From 06318d6220093cc96c0cf26d3f2f52c76f3ca59b Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:05:47 +0200 Subject: [PATCH 05/29] README Strategy --- Strategy/README.md | 16 ++++++++++++++++ Strategy/index.php | 18 ------------------ 2 files changed, 16 insertions(+), 18 deletions(-) create mode 100644 Strategy/README.md diff --git a/Strategy/README.md b/Strategy/README.md new file mode 100644 index 0000000..88f43dd --- /dev/null +++ b/Strategy/README.md @@ -0,0 +1,16 @@ +# Strategy + +## Terminology: + +* Context +* Strategy +* Concrete Strategy + +## Purpose + +To separate strategies and to enable fast switching between them. Also this pattern is a good alternative to inheritance (instead of having an abstract class that is extended). + +## Examples + +* sorting a list of objects, one strategy by date, the other by id +* simplify unit testing: e.g. switching between file and in-memory storage diff --git a/Strategy/index.php b/Strategy/index.php index d59819a..d04caa2 100644 --- a/Strategy/index.php +++ b/Strategy/index.php @@ -2,24 +2,6 @@ namespace DesignPatterns\Strategy; -/** - * strategy pattern - * - * Terminology: - * - Context - * - Strategy - * - Concrete Strategy - * - * Purpose: - * to separate strategies and to enable fast switching between them. - * also this pattern is a good alternative to inheritance (instead of having an abstract class that is extended) - * - * Examples: - * - sorting a list of objects, one strategy by date, the other by id - * - simplify unit testing: e.g. switching between file and in-memory storage - * - */ - $elements = array( array( 'id' => 2, From 07367d48b2ce731a4fdbcd362e7e7e66bda9d74c Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:08:02 +0200 Subject: [PATCH 06/29] README in StaticFactory --- StaticFactory/README.md | 11 +++++++++++ StaticFactory/StaticFactory.php | 10 ---------- 2 files changed, 11 insertions(+), 10 deletions(-) create mode 100644 StaticFactory/README.md diff --git a/StaticFactory/README.md b/StaticFactory/README.md new file mode 100644 index 0000000..c3131f6 --- /dev/null +++ b/StaticFactory/README.md @@ -0,0 +1,11 @@ +# Static Factory + +## Purpose + +Similar to the AbstractFactory, this pattern is used to create series of related or dependant objects. +The difference between this and the abstract factory pattern is that the static factory pattern uses just one static +method to create all types of objects it can create. It is usually named `factory` or `build`. + +## Examples + +* Zend Framework: `Zend_Cache_Backend` or `_Frontend` use a factory method create cache backends or frontends diff --git a/StaticFactory/StaticFactory.php b/StaticFactory/StaticFactory.php index f31d4a1..2010416 100644 --- a/StaticFactory/StaticFactory.php +++ b/StaticFactory/StaticFactory.php @@ -3,16 +3,6 @@ namespace DesignPatterns\StaticFactory; /** - * Static Factory pattern - * - * Purpose: - * similar to the AbstractFactory, this pattern is used to create series of related or dependant objects. - * The difference between this and the abstract factory pattern is that the static factory pattern uses just one static - * method to create all types of objects it can create. It is usually named "factory" or "build". - * - * Examples: - * - Zend Framework: Zend_Cache_Backend or _Frontend use a factory method create cache backends or frontends - * * Note1: Remember, static => global => evil * Note2: Cannot be subclassed or mock-upped or have multiple different instances */ From fde52def3cf1da1ad7847db8975e3795bd66f46c Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:09:53 +0200 Subject: [PATCH 07/29] README for Composite --- Composite/Form.php | 12 +----------- Composite/README.md | 12 ++++++++++++ 2 files changed, 13 insertions(+), 11 deletions(-) create mode 100644 Composite/README.md diff --git a/Composite/Form.php b/Composite/Form.php index decc599..66248c2 100644 --- a/Composite/Form.php +++ b/Composite/Form.php @@ -3,18 +3,8 @@ namespace DesignPatterns\Composite; /** - * Composite pattern - * - * Purpose: - * to treat a group of objects the same way as a single instance of the object - * - * Example: - * - a form class instance handles all its form elements like a single instance of the form, when render() is called, it - * subsequently runs trough all its child elements and calls render() on them - * - Zend_Config: a tree of configuration options, each one is a Zend_Config object - * * The composite node MUST extend the component contract. This is mandatory for building - * a tree of component. + * a tree of components. */ class Form extends FormElement { diff --git a/Composite/README.md b/Composite/README.md new file mode 100644 index 0000000..01732d1 --- /dev/null +++ b/Composite/README.md @@ -0,0 +1,12 @@ +# Composite + +# Purpose + +To treat a group of objects the same way as a single instance of the object. + +# Examples + +* a form class instance handles all its form elements like a single instance of the form, when `render()` is called, it + subsequently runs trough all its child elements and calls `render()` on them +* `Zend_Config`: a tree of configuration options, each one is a `Zend_Config` object itself + From 5efa7526113df1687c1ea19bd5bbc96f2e660f1b Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:11:41 +0200 Subject: [PATCH 08/29] README for DataMapper --- DataMapper/README.md | 18 ++++++++++++++++++ DataMapper/UserMapper.php | 20 +------------------- 2 files changed, 19 insertions(+), 19 deletions(-) create mode 100644 DataMapper/README.md diff --git a/DataMapper/README.md b/DataMapper/README.md new file mode 100644 index 0000000..61245de --- /dev/null +++ b/DataMapper/README.md @@ -0,0 +1,18 @@ +# Data Mapper + +## Purpose + +A Data Mapper, is a Data Access Layer that performs bidirectional transfer of +data between a persistent data store (often a relational database) and an in +memory data representation (the domain layer). The goal of the pattern is to +keep the in memory representation and the persistent data store independent of +each other and the data mapper itself. The layer is composed of one or more +mappers (or Data Access Objects), performing the data transfer. Mapper +implementations vary in scope. Generic mappers will handle many different domain +entity types, dedicated mappers will handle one or a few. + +The key point of this pattern is, unlike Active Record pattern, the data model follows Single Responsibility Principle. + +## Examples + +* DB Object Relational Mapper (ORM) : Doctrine2 uses DAO named as "EntityRepository" diff --git a/DataMapper/UserMapper.php b/DataMapper/UserMapper.php index 0b6b689..a9d65e7 100644 --- a/DataMapper/UserMapper.php +++ b/DataMapper/UserMapper.php @@ -3,25 +3,7 @@ namespace DesignPatterns\DataMapper; /** - * DataMapper pattern - * - * Purpose: - * A Data Mapper, is a Data Access Layer that performs bidirectional transfer of - * data between a persistent data store (often a relational database) and an in - * memory data representation (the domain layer). The goal of the pattern is to - * keep the in memory representation and the persistent data store independent of - * each other and the data mapper itself. The layer is composed of one or more - * mappers (or Data Access Objects), performing the data transfer. Mapper - * implementations vary in scope. Generic mappers will handle many different domain - * entity types, dedicated mappers will handle one or a few. - * (FROM http://en.wikipedia.org/wiki/Data_mapper_pattern) - * - * The key point of this pattern is, unlike Active Record pattern, the datamodel - * follows Single Responsibility Principle. - * - * Examples: - * - DB Object Relational Mapper (ORM) : Doctrine2 uses DAO named as "EntityRepository" - * + * class UserMapper */ class UserMapper { From 2403083d614ff077757f2ae19aa93297c0b5e493 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:18:21 +0200 Subject: [PATCH 09/29] README Decorator --- Decorator/Decorator.php | 17 ++++------------- Decorator/README.md | 10 ++++++++++ 2 files changed, 14 insertions(+), 13 deletions(-) create mode 100644 Decorator/README.md diff --git a/Decorator/Decorator.php b/Decorator/Decorator.php index 88c1b84..0d314c2 100644 --- a/Decorator/Decorator.php +++ b/Decorator/Decorator.php @@ -2,24 +2,15 @@ namespace DesignPatterns\Decorator; -/** - * Decorator pattern - * - * Purpose: - * to dynamically add new functionality to class instances - * - * Examples: - * - Zend Framework: decorators for Zend_Form_Element instances - * - Web Service Layer: Decorators JSON and XML for a REST service (in this case, only one of these should be allowed of - * course) - * - */ - /** * the Deoorator MUST implement the RendererInterface contract, this is the key-feature * of this design pattern. If not, this is no longer a Decorator but just a dumb * wrapper. */ + +/** + * class Decorator + */ abstract class Decorator implements RendererInterface { /** diff --git a/Decorator/README.md b/Decorator/README.md new file mode 100644 index 0000000..528a0f2 --- /dev/null +++ b/Decorator/README.md @@ -0,0 +1,10 @@ +# Decorator + +## Purpose + +To dynamically add new functionality to class instances. + +## Examples + +* Zend Framework: decorators for Zend_Form_Element instances +* Web Service Layer: Decorators JSON and XML for a REST service (in this case, only one of these should be allowed of course) From 1a3f16ab297045737f9ffb5d41ebbd41ae4f0ed3 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:20:07 +0200 Subject: [PATCH 10/29] README for Builder --- Builder/BuilderInterface.php | 11 +---------- Builder/Parts/README.md | 10 ++++++++++ Builder/README.md | 15 +++++++++++++++ 3 files changed, 26 insertions(+), 10 deletions(-) create mode 100644 Builder/Parts/README.md create mode 100644 Builder/README.md diff --git a/Builder/BuilderInterface.php b/Builder/BuilderInterface.php index f52b56f..89b4b8f 100644 --- a/Builder/BuilderInterface.php +++ b/Builder/BuilderInterface.php @@ -3,16 +3,7 @@ namespace DesignPatterns\Builder; /** - * Builder is an interface that build parts of a complex object. - * - * Sometime, if the builder has a better knowledge of what it builds, this - * interface could be an abstract class with default methods (aka adapter) - * - * If you have a complex inheritance tree for vehicles, it is logical to have - * a complex inheritance tree for builders too. - * - * Note: Builders have often a fluent interface, see the mock builder of - * PHPUnit for example. + * */ interface BuilderInterface { diff --git a/Builder/Parts/README.md b/Builder/Parts/README.md new file mode 100644 index 0000000..9e802c8 --- /dev/null +++ b/Builder/Parts/README.md @@ -0,0 +1,10 @@ +# + +# Purpose + + + +# Examples + +* + diff --git a/Builder/README.md b/Builder/README.md new file mode 100644 index 0000000..3a85f51 --- /dev/null +++ b/Builder/README.md @@ -0,0 +1,15 @@ +# Builder + +## Purpose + +Builder is an interface that build parts of a complex object. + +Sometimes, if the builder has a better knowledge of what it builds, this interface could be an abstract class with default methods (aka adapter). + +If you have a complex inheritance tree for objects, it is logical to have a complex inheritance tree for builders too. + +Note: Builders have often a fluent interface, see the mock builder of PHPUnit for example. + +## Examples + +* PHPUnit: Mock Builder From 0224d6daa4f7e7e86a56fc6472a23426c5997284 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:21:54 +0200 Subject: [PATCH 11/29] README for DI --- DependencyInjection/Configuration.php | 13 +------------ DependencyInjection/README.md | 10 ++++++++++ 2 files changed, 11 insertions(+), 12 deletions(-) create mode 100644 DependencyInjection/README.md diff --git a/DependencyInjection/Configuration.php b/DependencyInjection/Configuration.php index f972bb6..839660a 100644 --- a/DependencyInjection/Configuration.php +++ b/DependencyInjection/Configuration.php @@ -3,18 +3,7 @@ namespace DesignPatterns\DependencyInjection; /** - * Dependency Injection - * - * Purpose: - * to implement a loosely coupled architecture in order to get better testable, maintainable and extendable code - * - * Examples: - * - the Doctrine2 ORM uses dependency injection e.g. for Configuration that is injected into a Connection object. for - * testing purposes, one can easily create a mock object of the configuration and inject that into the connection - * object - * - Symfony and Zend Framework 2 already have containers for DI that create objects via a configuration array and - * inject them where needed (i.e. in Controllers) - * + * class Configuration */ class Configuration { diff --git a/DependencyInjection/README.md b/DependencyInjection/README.md new file mode 100644 index 0000000..7d53085 --- /dev/null +++ b/DependencyInjection/README.md @@ -0,0 +1,10 @@ +# Dependency Injection + +## Purpose + +To implement a loosely coupled architecture in order to get better testable, maintainable and extendable code. + +## Examples + +* the Doctrine2 ORM uses dependency injection e.g. for Configuration that is injected into a Connection object. for testing purposes, one can easily create a mock object of the configuration and inject that into the connection object +* Symfony and Zend Framework 2 already have containers for DI that create objects via a configuration array and inject them where needed (i.e. in Controllers) From d618d2068af17dfc6e9b9445187bece3c3790e08 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:29:38 +0200 Subject: [PATCH 12/29] README Facade --- Facade/Facade.php | 16 ---------------- Facade/README.md | 17 +++++++++++++++++ 2 files changed, 17 insertions(+), 16 deletions(-) create mode 100644 Facade/README.md diff --git a/Facade/Facade.php b/Facade/Facade.php index 82fbab4..ec1dec3 100644 --- a/Facade/Facade.php +++ b/Facade/Facade.php @@ -3,23 +3,7 @@ namespace DesignPatterns\Facade; /** - * The primary goal of a Facade Pattern is not to avoid you to read the manual of - * a complex API. It's only a side-effect. - * - * The first goal is to reduce coupling and follow the Law of Demeter. - * - * A Facade is meant to decouple a client and a sub-system by embedding - * many (but sometimes just one) interface, and of course to reduce complexity. - * - * 1. A facade does not forbid you the access to the sub-system - * 2. You can (you should) have multiple facades for one sub-system - * - * That's why a good facade has no "new" in it. If there are multiple creations - * for each method, it is not a Facade, it's a Builder or a - * [Abstract|Static|Simple] Factory [Method]. * - * The best facade has no new and a constructor with interface-type-hinted parameters. - * If you need creation of new instances, use Factory as argument. * */ class Facade diff --git a/Facade/README.md b/Facade/README.md new file mode 100644 index 0000000..b7e9156 --- /dev/null +++ b/Facade/README.md @@ -0,0 +1,17 @@ +# Facade + +## Purpose + +The primary goal of a Facade Pattern is not to avoid you to read the manual of a complex API. It's only a side-effect. +The first goal is to reduce coupling and follow the Law of Demeter. + +A Facade is meant to decouple a client and a sub-system by embedding many (but sometimes just one) interface, and of course to reduce complexity. + +* A facade does not forbid you the access to the sub-system +* You can (you should) have multiple facades for one sub-system + +That's why a good facade has no `new` in it. If there are multiple creations for each method, it is not a Facade, it's a Builder or a +[Abstract|Static|Simple] Factory [Method]. + +The best facade has no `new` and a constructor with interface-type-hinted parameters. +If you need creation of new instances, use a Factory as argument. From 851aa0a0d8117a915d54cc83244e37648e4dc718 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:31:37 +0200 Subject: [PATCH 13/29] README FactoryMethod --- FactoryMethod/FactoryMethod.php | 12 +----------- FactoryMethod/README.md | 11 +++++++++++ 2 files changed, 12 insertions(+), 11 deletions(-) create mode 100644 FactoryMethod/README.md diff --git a/FactoryMethod/FactoryMethod.php b/FactoryMethod/FactoryMethod.php index 72357d5..677e6a6 100644 --- a/FactoryMethod/FactoryMethod.php +++ b/FactoryMethod/FactoryMethod.php @@ -3,17 +3,7 @@ namespace DesignPatterns\FactoryMethod; /** - * FactoryMethod is a factory method. The good point over the SimpleFactory - * is you can subclass it to implement different way to create vehicle for - * each country (see subclasses) - * - * For simple case, this abstract class could be just an interface - * - * This pattern is a "real" Design Pattern because it achieves the - * "Dependency Inversion Principle" a.k.a the "D" in S.O.L.I.D principles. - * - * It means the FactoryMethod class depends on abstractions not concrete classes. - * This is the real trick compared to SImpleFactory or StaticFactory. + * class FactoryMethod */ abstract class FactoryMethod { diff --git a/FactoryMethod/README.md b/FactoryMethod/README.md new file mode 100644 index 0000000..10af7fd --- /dev/null +++ b/FactoryMethod/README.md @@ -0,0 +1,11 @@ +# Factory Method + +## Purpose + +The good point over the SimpleFactory is you can subclass it to implement different ways to create objects + +For simple case, this abstract class could be just an interface + +This pattern is a "real" Design Pattern because it achieves the "Dependency Inversion Principle" a.k.a the "D" in S.O.L.I.D principles. + +It means the FactoryMethod class depends on abstractions, not concrete classes. This is the real trick compared to SimpleFactory or StaticFactory. From 1d166d474bfc1d704af0e6e30206438f859b5fba Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:33:01 +0200 Subject: [PATCH 14/29] README FluentInterface --- FluentInterface/README.md | 11 +++++++++++ FluentInterface/SQL.php | 10 +--------- 2 files changed, 12 insertions(+), 9 deletions(-) create mode 100644 FluentInterface/README.md diff --git a/FluentInterface/README.md b/FluentInterface/README.md new file mode 100644 index 0000000..7b605a4 --- /dev/null +++ b/FluentInterface/README.md @@ -0,0 +1,11 @@ +# Fluent Interface + +## Purpose + +To write code that is easy readable just like sentences in a natural language (like English). + +## Examples + +* Doctrine2's QueryBuilder works something like that example class below +* PHPUnit uses fluent interfaces to build mock objects +* Yii Framework: CDbCommand and CActiveRecord use this pattern, too diff --git a/FluentInterface/SQL.php b/FluentInterface/SQL.php index 6074f70..6b7d82d 100644 --- a/FluentInterface/SQL.php +++ b/FluentInterface/SQL.php @@ -3,15 +3,7 @@ namespace DesignPatterns\FluentInterface; /** - * fluent interface pattern - * - * Purpose: - * to write code that is easy readable just like "real" sentences - * - * Examples: - * - Doctrine2's QueryBuilder works something like that example class below - * - PHPUnit uses fluent interfaces to build mock objects - * - Yii Framework: CDbCommand and CActiveRecord use this pattern, too + * class SQL */ class SQL { From 0251304b9a613372710f99dea7dd8a168b934a3c Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:35:11 +0200 Subject: [PATCH 15/29] README iterator --- Iterator/File.php | 14 +------------- Iterator/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 13 deletions(-) create mode 100644 Iterator/README.md diff --git a/Iterator/File.php b/Iterator/File.php index 0e1aa3d..e2e6a3d 100644 --- a/Iterator/File.php +++ b/Iterator/File.php @@ -3,21 +3,9 @@ namespace DesignPatterns\Iterator; /** - * iterator pattern - * - * Purpose: - * to make an object iterable - * - * Examples: - * - to process a file line by line by just running over all lines (which have an object representation) for a file - * (which of course is an object, too) - * - * Note: - * Standard PHP Library (SPL) defines an interface Iterator which is best suited for this! - * Often you would want to implement the Countable interface too, to allow count($object) on your iterable object + * class File * * THIS EXAMPLE ALSO APPLIES THE COMPOSITE PATTERN - * */ class File { diff --git a/Iterator/README.md b/Iterator/README.md new file mode 100644 index 0000000..d364490 --- /dev/null +++ b/Iterator/README.md @@ -0,0 +1,13 @@ +# Iterator + +## Purpose + +To make an object iterable and to make it appear like a collection of objects. + +## Examples + +* to process a file line by line by just running over all lines (which have an object representation) for a file (which of course is an object, too) + +## Note + +Standard PHP Library (SPL) defines an interface Iterator which is best suited for this! Often you would want to implement the Countable interface too, to allow `count($object)` on your iterable object From 580e6ec9a89ae3d294dcbb71a236be3f08e036a2 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:36:30 +0200 Subject: [PATCH 16/29] README Mediator --- Mediator/Mediator.php | 10 +--------- Mediator/README.md | 11 +++++++++++ 2 files changed, 12 insertions(+), 9 deletions(-) create mode 100644 Mediator/README.md diff --git a/Mediator/Mediator.php b/Mediator/Mediator.php index 9a9c3f1..11f7ad8 100644 --- a/Mediator/Mediator.php +++ b/Mediator/Mediator.php @@ -7,15 +7,7 @@ use DesignPatterns\Mediator\Subsystem; /** * Mediator is the concrete Mediator for this design pattern. * - * This pattern provides an easy to decouple many components working together. - * It is a good alternative over Observer IF you have a "central intelligence", - * like a controller (but not in the sense of the MVC). - * - * All components (called Colleague) are only coupled to the MediatorInterface and - * it is a good thing because in OOP, one good friend is better than many. This - * is the key-feature of this pattern. - * - * In this example, I have made a "Hello World" with the Mediator Pattern, have fun (^_^) + * In this example, I have made a "Hello World" with the Mediator Pattern. */ class Mediator implements MediatorInterface { diff --git a/Mediator/README.md b/Mediator/README.md new file mode 100644 index 0000000..5376000 --- /dev/null +++ b/Mediator/README.md @@ -0,0 +1,11 @@ +# Mediator + +## Purpose + +This pattern provides an easy to decouple many components working together. +It is a good alternative over Observer IF you have a "central intelligence", +like a controller (but not in the sense of the MVC). + +All components (called Colleague) are only coupled to the MediatorInterface and +it is a good thing because in OOP, one good friend is better than many. This +is the key-feature of this pattern. From c3ede29de811c48a4407a7a9adaba612d9e486a0 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:39:25 +0200 Subject: [PATCH 17/29] README Multiton --- Multiton/Multiton.php | 15 +-------------- Multiton/README.md | 12 ++++++++++++ 2 files changed, 13 insertions(+), 14 deletions(-) create mode 100644 Multiton/README.md diff --git a/Multiton/Multiton.php b/Multiton/Multiton.php index 1dddebb..cacc79b 100644 --- a/Multiton/Multiton.php +++ b/Multiton/Multiton.php @@ -3,20 +3,7 @@ namespace DesignPatterns; /** - * Multiton pattern - * - * -------------------------------------------------------------------------------------------------------------- - * THIS IS CONSIDERED TO BE AN ANTI-PATTERN! FOR BETTER TESTABILITY AND MAINTAINABILITY USE DEPENDENCY INJECTION! - * -------------------------------------------------------------------------------------------------------------- - * - * Purpose: - * to have only a list of named instances that are used, like a singleton but with n instances - * - * Examples: - * - 2 DB Connectors, e.g. one for MySQL, the other for SQLite - * - multiple Loggers (one for debug messages, one for errors) - * - * + * class Multiton */ class Multiton { diff --git a/Multiton/README.md b/Multiton/README.md new file mode 100644 index 0000000..938de9c --- /dev/null +++ b/Multiton/README.md @@ -0,0 +1,12 @@ +# Multiton + +**THIS IS CONSIDERED TO BE AN ANTI-PATTERN! FOR BETTER TESTABILITY AND MAINTAINABILITY USE DEPENDENCY INJECTION!** + +# Purpose + +To have only a list of named instances that are used, like a singleton but with n instances. + +# Examples + +* 2 DB Connectors, e.g. one for MySQL, the other for SQLite +* multiple Loggers (one for debug messages, one for errors) From 722218f1a20fdc7b24f8298df6743682419f2d53 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:42:52 +0200 Subject: [PATCH 18/29] README NullObject --- NullObject/NullLogger.php | 19 +------------------ NullObject/README.md | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+), 18 deletions(-) create mode 100644 NullObject/README.md diff --git a/NullObject/NullLogger.php b/NullObject/NullLogger.php index aafa327..7f013dc 100644 --- a/NullObject/NullLogger.php +++ b/NullObject/NullLogger.php @@ -3,23 +3,6 @@ namespace DesignPatterns\NullObject; /** - * NullOutput is a example of NullObject pattern. It is not formely a Design - * Pattern by the GoF but it's a schema which appears frequently enough to - * be a pattern. Futhermore it is a really good pattern in my opinion : - * - the code in the client is simple - * - it reduces the chance of null pointer exception - * - less "if" => less test cases - * - * The purpose : every time you have a method which returns an object or null, - * you should return an object or a "NullObject". With NullObject, you don't need - * statement like "if (!is_null($obj)) { $obj->callSomething(); }" anymore. - * - * In this case, this a logger which does nothing. Other examples : - * - null logger of symfony profiler - * - null output in symfony/console - * - null handler in a Chain of Responsiblities pattern - * - null command in a Command pattern - * * Performance concerns : ok there is a call for nothing but we spare an "if is_null" * I didn't run a benchmark but I think it's equivalent. * @@ -29,7 +12,7 @@ namespace DesignPatterns\NullObject; class NullLogger implements LoggerInterface { /** - * @param string $str + * {@inheritdoc} */ public function log($str) { diff --git a/NullObject/README.md b/NullObject/README.md new file mode 100644 index 0000000..1e18d25 --- /dev/null +++ b/NullObject/README.md @@ -0,0 +1,20 @@ +# Null Object + +## Purpose + +NullOutput is a example of NullObject pattern. It is not formally a Design Pattern by the GoF but it's a schema which appears frequently enough to +be a pattern. Furthermore it is a really good pattern in my opinion: + +* the code in the client is simple +* it reduces the chance of null pointer exception +* less "if" => less test cases + +Every time you have a method which returns an object or null, you should return an object or a `NullObject`. With NullObject, you don't need +a statement like `if (!is_null($obj)) { $obj->callSomething(); }` anymore. + +## Examples + +* Symfony2: null logger of profiler +* Symfony2: null output in Symfony/Console +* null handler in a Chain of Responsibilities pattern +* null command in a Command pattern From 5633c8508cae66dd06981c077730242a869666a1 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:44:11 +0200 Subject: [PATCH 19/29] README Observer --- Observer/README.md | 14 ++++++++++++++ Observer/UserObserver.php | 12 +----------- 2 files changed, 15 insertions(+), 11 deletions(-) create mode 100644 Observer/README.md diff --git a/Observer/README.md b/Observer/README.md new file mode 100644 index 0000000..c59a584 --- /dev/null +++ b/Observer/README.md @@ -0,0 +1,14 @@ +# Observer + +## Purpose + +To implement a publish/subscribe behaviour to an object, whenever a "Subject" object changes it's state, the attached +"Observers" will be notified. It is used to shorten the amount of coupled objects and uses loose coupling instead. + +## Examples + +* a message queue system is observed to show the progress of a job in a GUI + +## Note + +PHP already defines two interfaces that can help to implement this pattern: SplObserver and SplSubject. \ No newline at end of file diff --git a/Observer/UserObserver.php b/Observer/UserObserver.php index 549da20..20bdf71 100644 --- a/Observer/UserObserver.php +++ b/Observer/UserObserver.php @@ -3,17 +3,7 @@ namespace DesignPatterns\Observer; /** - * Observer pattern - * - * Purpose: - * to implement a publish/subscribe behaviour to an object, whenever a "Subject" object changes it's state, the attached - * "Observers" will be notified. It is used to shorten the amount of coupled objects and uses loose coupling instead - * - * Examples: - * - a message queue system is observed to show the progress of a job in a GUI - * - * PHP already defines two interfaces that can help to implement this pattern: SplObserver and SplSubject - * + * class UserObserver */ class UserObserver implements \SplObserver { From 02d616a0b223ac96e90cf4b9da5b1304232f0b0c Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 13:44:34 +0200 Subject: [PATCH 20/29] cs --- Mediator/Mediator.php | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Mediator/Mediator.php b/Mediator/Mediator.php index 11f7ad8..d501573 100644 --- a/Mediator/Mediator.php +++ b/Mediator/Mediator.php @@ -6,7 +6,7 @@ use DesignPatterns\Mediator\Subsystem; /** * Mediator is the concrete Mediator for this design pattern. - * + * * In this example, I have made a "Hello World" with the Mediator Pattern. */ class Mediator implements MediatorInterface From c8d88b0b0817cc326100dd8a860261078958c235 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 14:02:52 +0200 Subject: [PATCH 21/29] README Prototype --- Prototype/BookPrototype.php | 9 +-------- Prototype/README.md | 9 +++++++++ 2 files changed, 10 insertions(+), 8 deletions(-) create mode 100644 Prototype/README.md diff --git a/Prototype/BookPrototype.php b/Prototype/BookPrototype.php index c75795e..79ddf36 100644 --- a/Prototype/BookPrototype.php +++ b/Prototype/BookPrototype.php @@ -3,14 +3,7 @@ namespace DesignPatterns\Prototype; /** - * Prototype pattern - * - * Purpose: - * to avoid the cost of creating objects the standard way (new Foo()) and instead create a prototype and clone it - * - * Examples: - * - Large amounts of data (e.g. create 1,000,000 rows in a database at once via a ORM) - * + * class BookPrototype */ abstract class BookPrototype { diff --git a/Prototype/README.md b/Prototype/README.md new file mode 100644 index 0000000..3a99777 --- /dev/null +++ b/Prototype/README.md @@ -0,0 +1,9 @@ +# Prototype + +## Purpose + +To avoid the cost of creating objects the standard way (new Foo()) and instead create a prototype and clone it + +## Examples + +* Large amounts of data (e.g. create 1,000,000 rows in a database at once via a ORM) From 4d916f3ffec14d5371e6d5e027951ed162ec6fc2 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 14:04:00 +0200 Subject: [PATCH 22/29] README Proxy --- Proxy/README.md | 9 +++++++++ Proxy/Record.php | 10 +--------- 2 files changed, 10 insertions(+), 9 deletions(-) create mode 100644 Proxy/README.md diff --git a/Proxy/README.md b/Proxy/README.md new file mode 100644 index 0000000..3ee37ef --- /dev/null +++ b/Proxy/README.md @@ -0,0 +1,9 @@ +# Proxy + +## Purpose + +To interface to anything that is expensive or impossible to duplicate. + +## Examples + +* Doctrine2 uses proxies to implement framework magic (e.g. lazy initialization) in them, while the user still works with his own entity classes and will never use nor touch the proxies diff --git a/Proxy/Record.php b/Proxy/Record.php index 722d946..28d861c 100644 --- a/Proxy/Record.php +++ b/Proxy/Record.php @@ -3,15 +3,7 @@ namespace DesignPatterns\Proxy; /** - * Proxy pattern - * - * Purpose: - * to interface to anything that is expensive or impossible to duplicate - * - * Examples: - * - Doctrine2 uses proxies to implement framework magic (e.g. lazy initialization) in them, while the user still works - * with his own entity classes and will never use nor touch the proxies - * + * class Record */ class Record { From 59001ecf9289325a566441a008b1e9840f415ae3 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 14:07:04 +0200 Subject: [PATCH 23/29] README Registry --- Registry/README.md | 11 +++++++++++ Registry/Registry.php | 13 ++----------- Registry/index.php | 2 +- 3 files changed, 14 insertions(+), 12 deletions(-) create mode 100644 Registry/README.md diff --git a/Registry/README.md b/Registry/README.md new file mode 100644 index 0000000..39a2661 --- /dev/null +++ b/Registry/README.md @@ -0,0 +1,11 @@ +# Registry + +## Purpose + +To implement a central storage for objects often used throughout the application, is typically implemented using +an abstract class with only static methods (or using the Singleton pattern) + +## Examples + +* Zend Framework: `Zend_Registry` holds the application's logger object, front controller etc. +* Yii Framework: `CWebApplication` holds all the application components, such as `CWebUser`, `CUrlManager`, etc. diff --git a/Registry/Registry.php b/Registry/Registry.php index 020398a..11df8d6 100644 --- a/Registry/Registry.php +++ b/Registry/Registry.php @@ -1,18 +1,9 @@ Date: Tue, 24 Sep 2013 14:08:25 +0200 Subject: [PATCH 24/29] README SimpleFactory --- SimpleFactory/ConcreteFactory.php | 8 +------- SimpleFactory/README.md | 9 +++++++++ 2 files changed, 10 insertions(+), 7 deletions(-) create mode 100644 SimpleFactory/README.md diff --git a/SimpleFactory/ConcreteFactory.php b/SimpleFactory/ConcreteFactory.php index 2890da6..fba685f 100644 --- a/SimpleFactory/ConcreteFactory.php +++ b/SimpleFactory/ConcreteFactory.php @@ -3,13 +3,7 @@ namespace DesignPatterns\SimpleFactory; /** - * ConcreteFactory is a simple factory pattern. - * - * It differs from the static factory because it is NOT static and as you - * know : static => global => evil - * - * Therefore, you can haZ multiple factories, differently parametrized, - * you can subclass it and you can mock-up it. + * class ConcreteFactory */ class ConcreteFactory { diff --git a/SimpleFactory/README.md b/SimpleFactory/README.md new file mode 100644 index 0000000..5bb2af6 --- /dev/null +++ b/SimpleFactory/README.md @@ -0,0 +1,9 @@ +# Simple Factory + +## Purpose + +ConcreteFactory is a simple factory pattern. + +It differs from the static factory because it is NOT static and as you know: static => global => evil! + +Therefore, you can haZ multiple factories, differently parametrized, you can subclass it and you can mock-up it. From 5e0fe5445da37659ba0a14d1fd1eb255a4d74920 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 14:10:45 +0200 Subject: [PATCH 25/29] README Singleton --- Singleton/README.md | 13 +++++++++++++ Singleton/Singleton.php | 14 +------------- 2 files changed, 14 insertions(+), 13 deletions(-) create mode 100644 Singleton/README.md diff --git a/Singleton/README.md b/Singleton/README.md new file mode 100644 index 0000000..140c4a1 --- /dev/null +++ b/Singleton/README.md @@ -0,0 +1,13 @@ +# Singleton + +**THIS IS CONSIDERED TO BE AN ANTI-PATTERN! FOR BETTER TESTABILITY AND MAINTAINABILITY USE DEPENDENCY INJECTION!** + +## Purpose + +To have only one instance of this object in the application that will handle all calls. + +## Examples + +* DB Connector +* Logger (may also be a Multiton if there are many log files for several purposes) +* Lock file for the application (there is only one in the filesystem ...) diff --git a/Singleton/Singleton.php b/Singleton/Singleton.php index e47579a..c52b6f3 100644 --- a/Singleton/Singleton.php +++ b/Singleton/Singleton.php @@ -3,19 +3,7 @@ namespace DesignPatterns\Singleton; /** - * Singleton pattern - * - * -------------------------------------------------------------------------------------------------------------- - * THIS IS CONSIDERED TO BE AN ANTI-PATTERN! FOR BETTER TESTABILITY AND MAINTAINABILITY USE DEPENDENCY INJECTION! - * -------------------------------------------------------------------------------------------------------------- - * - * Purpose: - * to have only one instance of this object in the application that will handle all calls - * - * Examples: - * - DB Connector - * - Logger (may also be a Multiton if there are many log files for several purposes) - * - Lock file for the application (there is only one in the filesystem ...) + * class Singleton */ class Singleton { From f1e8c5796fc14a4a8163fca69d2547c98047f837 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 14:13:00 +0200 Subject: [PATCH 26/29] README State --- State/README.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 State/README.md diff --git a/State/README.md b/State/README.md new file mode 100644 index 0000000..97daa28 --- /dev/null +++ b/State/README.md @@ -0,0 +1,5 @@ +# State + +## Purpose + +Encapsulate varying behavior fo the same routine based on an object's state. This can be a cleaner way for an object to change its behavior at runtime without resorting to large monolithic conditional statements. From f8e801d445dcc8ef25a5de540891383c8b6bfaf1 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 14:18:33 +0200 Subject: [PATCH 27/29] README AbstractFactory --- AbstractFactory/AbstractFactory.php | 17 ++++++----------- AbstractFactory/README.md | 6 ++++++ 2 files changed, 12 insertions(+), 11 deletions(-) create mode 100644 AbstractFactory/README.md diff --git a/AbstractFactory/AbstractFactory.php b/AbstractFactory/AbstractFactory.php index e322325..8b8cdec 100644 --- a/AbstractFactory/AbstractFactory.php +++ b/AbstractFactory/AbstractFactory.php @@ -3,22 +3,17 @@ namespace DesignPatterns\AbstractFactory; /** - * Abstract Factory pattern + * class AbstractFactory + * + * Sometimes also known as "Kit" in a GUI libraries. * - * Purpose: - * to create series of related or dependant objects without specifying their concrete classes, - * usually the created classes all implement the same interface. The client of the abstract - * factory does not care about how these objects are created, he just knows they go together. - * - * Sometimes also known as "Kit" in a GUI libraries. - * * This design pattern implements the Dependency Inversion Principle since * it is the concrete subclass which creates concrete components. - * + * * In this case, the abstract factory is a contract for creating some components - * for the web. There are two components : Text and Picture. There is two ways + * for the web. There are two components : Text and Picture. There is two ways * of rendering : HTML or JSON. - * + * * Therefore 4 concretes classes, but the client just need to know this contract * to build a correct http response (for a html page or for an ajax request) */ diff --git a/AbstractFactory/README.md b/AbstractFactory/README.md new file mode 100644 index 0000000..c568d80 --- /dev/null +++ b/AbstractFactory/README.md @@ -0,0 +1,6 @@ +# Abstract Factory + +## Purpose + +To create series of related or dependant objects without specifying their concrete classes. +Usually the created classes all implement the same interface. The client of the abstract factory does not care about how these objects are created, he just knows how they go together. From 8ff9f1fc01e9aa5840861f2c7aa8ad55e9c9c5f4 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 14:22:30 +0200 Subject: [PATCH 28/29] cs --- AbstractFactory/AbstractFactory.php | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AbstractFactory/AbstractFactory.php b/AbstractFactory/AbstractFactory.php index 8b8cdec..481e14e 100644 --- a/AbstractFactory/AbstractFactory.php +++ b/AbstractFactory/AbstractFactory.php @@ -4,7 +4,7 @@ namespace DesignPatterns\AbstractFactory; /** * class AbstractFactory - * + * * Sometimes also known as "Kit" in a GUI libraries. * * This design pattern implements the Dependency Inversion Principle since From 069b6de8ba2acfc8047edf036a94a8484ae80090 Mon Sep 17 00:00:00 2001 From: Dominik Liebler Date: Tue, 24 Sep 2013 14:22:38 +0200 Subject: [PATCH 29/29] README Adapter --- Adapter/EBookAdapter.php | 2 +- Adapter/README.md | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 Adapter/README.md diff --git a/Adapter/EBookAdapter.php b/Adapter/EBookAdapter.php index 9677553..d8c5574 100644 --- a/Adapter/EBookAdapter.php +++ b/Adapter/EBookAdapter.php @@ -5,7 +5,7 @@ namespace DesignPatterns\Adapter; /** * EBookAdapter is an adapter to fit an e-book like a paper book * - * This is the adapter here. Notice it implemennts PaperBookInterface, + * This is the adapter here. Notice it implements PaperBookInterface, * therefore you don't have to change the code of the client which using paper book. */ class EBookAdapter implements PaperBookInterface diff --git a/Adapter/README.md b/Adapter/README.md new file mode 100644 index 0000000..5d77709 --- /dev/null +++ b/Adapter/README.md @@ -0,0 +1,10 @@ +# Adapter / Wrapper + +## Purpose + +To translate one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces by providing it's interface to clients while using the original interface. + +## Examples + +* DB Client libraries adapter +* using multiple different webservices and adapters normalize data so that the outcome is the same for all