mirror of
https://github.com/DesignPatternsPHP/DesignPatternsPHP.git
synced 2025-08-07 15:36:34 +02:00
Change index.rst to README.rst
remove all pattern's README.md
This commit is contained in:
Faust
@@ -1,16 +0,0 @@
|
||||
# Chain Of Responsibilities
|
||||
|
||||
## Purpose:
|
||||
|
||||
To build a chain of objects to handle a call in sequential order. If one object cannot handle a call, it delegates the call to the next in the chain and so forth.
|
||||
|
||||
## Examples:
|
||||
|
||||
* 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
# Command
|
||||
|
||||
## Purpose
|
||||
|
||||
To encapsulate invocation and decoupling.
|
||||
|
||||
We have an Invoker and a Receiver. This pattern uses 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 this 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)
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
# 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
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
# 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,22 +0,0 @@
|
||||
# Memento
|
||||
|
||||
## Purpose
|
||||
|
||||
Provide the ability to restore an object to its previous state (undo via rollback).
|
||||
|
||||
The memento pattern is implemented with three objects: the originator, a caretaker and a memento.
|
||||
The originator is some object that has an internal state.
|
||||
The caretaker is going to do something to the originator, but wants to be able to undo the change.
|
||||
The caretaker first asks the originator for a memento object. Then it does whatever operation (or sequence of operations) it was going to do.
|
||||
To roll back to the state before the operations, it returns the memento object to the originator.
|
||||
The memento object itself is an opaque object (one which the caretaker cannot, or should not, change).
|
||||
When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object.
|
||||
|
||||
## Examples
|
||||
|
||||
* The seed of a pseudorandom number generator
|
||||
* The state in a finite state machine
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,22 +0,0 @@
|
||||
# Null Object
|
||||
|
||||
## Purpose
|
||||
|
||||
NullObject is not a GoF design pattern but a schema which appears frequently enough to be considered a pattern. It has the following benefits:
|
||||
|
||||
* Client code is simplified
|
||||
* Reduces the chance of null pointer exceptions
|
||||
* Fewer conditionals require less test cases
|
||||
|
||||
Methods that return an object or null should instead return an object or `NullObject`. `NullObject`s simplify boilerplate code such as `if (!is_null($obj)) { $obj->callSomething(); }` to just `$obj->callSomething();` by eliminating the conditional check in client code.
|
||||
|
||||
## 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
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
# 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -9,15 +9,15 @@ carrying out this communication.
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
ChainOfResponsibilities/index
|
||||
Command/index
|
||||
Iterator/index
|
||||
Mediator/index
|
||||
Memento/index
|
||||
NullObject/index
|
||||
Observer/index
|
||||
Specification/index
|
||||
State/index
|
||||
Strategy/index
|
||||
TemplateMethod/index
|
||||
Visitor/index
|
||||
ChainOfResponsibilities/README
|
||||
Command/README
|
||||
Iterator/README
|
||||
Mediator/README
|
||||
Memento/README
|
||||
NullObject/README
|
||||
Observer/README
|
||||
Specification/README
|
||||
State/README
|
||||
Strategy/README
|
||||
TemplateMethod/README
|
||||
Visitor/README
|
||||
@@ -1,10 +0,0 @@
|
||||
# Specification
|
||||
|
||||
## Purpose
|
||||
|
||||
Builds a clear specification of business rules, where objects can be checked against. The composite specification class has
|
||||
one method called `isSatisfiedBy` that returns either true or false depending on whether the given object satisfies the specification.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
# State
|
||||
|
||||
## Purpose
|
||||
|
||||
Encapsulate varying behavior for 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,20 +0,0 @@
|
||||
# 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
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
# 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
# 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
Reference in New Issue
Block a user