mirror of
https://github.com/DesignPatternsPHP/DesignPatternsPHP.git
synced 2025-09-30 08:19:12 +02:00
Change index.rst to README.rst
remove all pattern's README.md
This commit is contained in:
Faust
@@ -1,14 +0,0 @@
|
||||
# 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
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
## Purpose
|
||||
|
||||
Decouple an abstraction from its implementation so that the two can vary
|
||||
independently. (http://en.wikipedia.org/wiki/Bridge_pattern)
|
||||
|
||||
#### Sample:
|
||||
|
||||
* [Symfony DoctrineBridge](https://github.com/symfony/DoctrineBridge)
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
# 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 through all its child elements and calls `render()` on them
|
||||
* `Zend_Config`: a tree of configuration options, each one is a `Zend_Config` object itself
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,22 +0,0 @@
|
||||
# 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"
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
# 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)
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,20 +0,0 @@
|
||||
# Dependency Injection
|
||||
|
||||
## Purpose
|
||||
|
||||
To implement a loosely coupled architecture in order to get better testable, maintainable and extendable code.
|
||||
|
||||
## Usage
|
||||
|
||||
Configuration gets injected and `Connection` will get all that it needs from `$config`. Without DI, the configuration would be created directly in `Connection`, which is not very good for testing and extending `Connection`.
|
||||
|
||||
Notice we are following Inversion of control principle in `Connection` by asking `$config` to implement `Parameters` interface. This decouples our components. We don't care where the source of information comes from, we only care that `$config` has certain methods to retrieve that information. Read more about Inversion of control [here](http://en.wikipedia.org/wiki/Inversion_of_control).
|
||||
|
||||
## 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)
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
# 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
# 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
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -1,13 +0,0 @@
|
||||
# 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
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
@@ -8,13 +8,13 @@ relationships between entities.
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
Adapter/index
|
||||
Bridge/index
|
||||
Composite/index
|
||||
DataMapper/index
|
||||
Decorator/index
|
||||
DependencyInjection/index
|
||||
Facade/index
|
||||
FluentInterface/index
|
||||
Proxy/index
|
||||
Registry/index
|
||||
Adapter/README
|
||||
Bridge/README
|
||||
Composite/README
|
||||
DataMapper/README
|
||||
Decorator/README
|
||||
DependencyInjection/README
|
||||
Facade/README
|
||||
FluentInterface/README
|
||||
Proxy/README
|
||||
Registry/README
|
||||
@@ -1,15 +0,0 @@
|
||||
# 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.
|
||||
|
||||
## UML Diagram
|
||||
|
||||
|
||||
Reference in New Issue
Block a user