mirror of
https://github.com/DesignPatternsPHP/DesignPatternsPHP.git
synced 2025-07-31 12:10:10 +02:00
Change index.rst to README.rst
remove all pattern's README.md
This commit is contained in:
Faust
@@ -1,10 +0,0 @@
|
||||
# Abstract Factory
|
||||
|
||||
## Purpose
|
||||
|
||||
To create series of related or dependent 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,10 +0,0 @@
|
||||
#
|
||||
|
||||
# Purpose
|
||||
|
||||
|
||||
|
||||
# Examples
|
||||
|
||||
*
|
||||
|
||||
@@ -1,19 +0,0 @@
|
||||
# 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
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
# 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,16 +0,0 @@
|
||||
# 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)
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
Pool
|
||||
====
|
||||
|
||||
The **object pool pattern** is a software creational design pattern that uses a set of initialized objects kept ready to use – a "pool" – rather than allocating and destroying them on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished, it returns the object, which is a specific type of factory object, to the pool rather than destroying it.
|
||||
|
||||
Object pooling can offer a significant performance boost in situations where the cost of initializing a class instance is high, the rate of instantiation of a class is high, and the number of instances in use at any one time is low. The pooled object is obtained in predictable time when creation of the new objects (especially over network) may take variable time.
|
||||
|
||||
However these benefits are mostly true for objects that are expensive with respect to time, such as database connections, socket connections, threads and large graphic objects like fonts or bitmaps. In certain situations, simple object pooling (that hold no external resources, but only occupy memory) may not be efficient and could decrease performance.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,13 +0,0 @@
|
||||
# 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).
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -11,12 +11,12 @@ this object creation.
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
AbstractFactory/index
|
||||
Builder/index
|
||||
FactoryMethod/index
|
||||
Multiton/index
|
||||
Pool/index
|
||||
Prototype/index
|
||||
SimpleFactory/index
|
||||
Singleton/index
|
||||
StaticFactory/index
|
||||
AbstractFactory/README
|
||||
Builder/README
|
||||
FactoryMethod/README
|
||||
Multiton/README
|
||||
Pool/README
|
||||
Prototype/README
|
||||
SimpleFactory/README
|
||||
Singleton/README
|
||||
StaticFactory/README
|
||||
@@ -1,13 +0,0 @@
|
||||
# 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 have multiple factories, differently parametrized, you can subclass it and you can mock-up it.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
# 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 ...)
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
# Static Factory
|
||||
|
||||
## Purpose
|
||||
|
||||
Similar to the AbstractFactory, this pattern is used to create series of related or dependent 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
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
Reference in New Issue
Block a user