info/DesignPatternsPHP
1
0
Fork 0
mirror of https://github.com/DesignPatternsPHP/DesignPatternsPHP.git synced 2025-08-05 22:47:34 +02:00
Code Issues Projects Releases Wiki Activity

execute read-the-docs.sh

Browse Source
This commit is contained in:
Faust
2015-04-02 00:03:33 +02:00
parent c6cc7f2131
commit bba8b0df43
40 changed files with 2491 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
Structural/Adapter/index.rst Normal file
View File

@@ -0,0 +1,70 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt Adapter UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
PaperBookInterface.php
.. literalinclude:: PaperBookInterface.php
:language: php
:linenos:
EBookInterface.php
.. literalinclude:: EBookInterface.php
:language: php
:linenos:
EBookAdapter.php
.. literalinclude:: EBookAdapter.php
:language: php
:linenos:
Kindle.php
.. literalinclude:: Kindle.php
:language: php
:linenos:
Book.php
.. literalinclude:: Book.php
:language: php
:linenos:
Test
----
Tests/AdapterTest.php
.. literalinclude:: Tests/AdapterTest.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/Adapter

70
Structural/Bridge/index.rst Normal file
View File

@@ -0,0 +1,70 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt Bridge UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
Assemble.php
.. literalinclude:: Assemble.php
:language: php
:linenos:
Workshop.php
.. literalinclude:: Workshop.php
:language: php
:linenos:
Car.php
.. literalinclude:: Car.php
:language: php
:linenos:
Motorcycle.php
.. literalinclude:: Motorcycle.php
:language: php
:linenos:
Vehicle.php
.. literalinclude:: Vehicle.php
:language: php
:linenos:
Produce.php
.. literalinclude:: Produce.php
:language: php
:linenos:
Test
----
Tests/BridgeTest.php
.. literalinclude:: Tests/BridgeTest.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/Bridge

64
Structural/Composite/index.rst Normal file
View File

@@ -0,0 +1,64 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt Composite UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
FormElement.php
.. literalinclude:: FormElement.php
:language: php
:linenos:
Form.php
.. literalinclude:: Form.php
:language: php
:linenos:
InputElement.php
.. literalinclude:: InputElement.php
:language: php
:linenos:
TextElement.php
.. literalinclude:: TextElement.php
:language: php
:linenos:
Test
----
Tests/CompositeTest.php
.. literalinclude:: Tests/CompositeTest.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/Composite

59
Structural/DataMapper/index.rst Normal file
View File

@@ -0,0 +1,59 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt DataMapper UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
UserMapper.php
.. literalinclude:: UserMapper.php
:language: php
:linenos:
User.php
.. literalinclude:: User.php
:language: php
:linenos:
Test
----
Tests/DataMapperTest.php
.. literalinclude:: Tests/DataMapperTest.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/DataMapper

67
Structural/Decorator/index.rst Normal file
View File

@@ -0,0 +1,67 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt Decorator UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
RendererInterface.php
.. literalinclude:: RendererInterface.php
:language: php
:linenos:
RenderInXml.php
.. literalinclude:: RenderInXml.php
:language: php
:linenos:
Webservice.php
.. literalinclude:: Webservice.php
:language: php
:linenos:
RenderInJson.php
.. literalinclude:: RenderInJson.php
:language: php
:linenos:
Decorator.php
.. literalinclude:: Decorator.php
:language: php
:linenos:
Test
----
Tests/DecoratorTest.php
.. literalinclude:: Tests/DecoratorTest.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/Decorator

87
Structural/DependencyInjection/index.rst Normal file
View File

@@ -0,0 +1,87 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt DependencyInjection UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
Connection.php
.. literalinclude:: Connection.php
:language: php
:linenos:
ArrayConfig.php
.. literalinclude:: ArrayConfig.php
:language: php
:linenos:
AbstractConfig.php
.. literalinclude:: AbstractConfig.php
:language: php
:linenos:
Parameters.php
.. literalinclude:: Parameters.php
:language: php
:linenos:
Test
----
Tests/DependencyInjectionTest.php
.. literalinclude:: Tests/DependencyInjectionTest.php
:language: php
:linenos:
Tests/config.php
.. literalinclude:: Tests/config.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/DependencyInjection

65
Structural/Facade/index.rst Normal file
View File

@@ -0,0 +1,65 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt Facade UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
OsInterface.php
.. literalinclude:: OsInterface.php
:language: php
:linenos:
Facade.php
.. literalinclude:: Facade.php
:language: php
:linenos:
BiosInterface.php
.. literalinclude:: BiosInterface.php
:language: php
:linenos:
Test
----
Tests/FacadeTest.php
.. literalinclude:: Tests/FacadeTest.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/Facade

45
Structural/FluentInterface/index.rst Normal file
View File

@@ -0,0 +1,45 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt FluentInterface UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
Sql.php
.. literalinclude:: Sql.php
:language: php
:linenos:
Test
----
Tests/FluentInterfaceTest.php
.. literalinclude:: Tests/FluentInterfaceTest.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/FluentInterface

43
Structural/Proxy/index.rst Normal file
View File

@@ -0,0 +1,43 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt Proxy UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
RecordProxy.php
.. literalinclude:: RecordProxy.php
:language: php
:linenos:
Record.php
.. literalinclude:: Record.php
:language: php
:linenos:
Test
----
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/Proxy

46
Structural/Registry/index.rst Normal file
View File

@@ -0,0 +1,46 @@
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
-----------
.. image:: uml/uml.png
:alt: Alt Registry UML Diagram
:align: center
Code
----
You can also find these code on `GitHub`_
Registry.php
.. literalinclude:: Registry.php
:language: php
:linenos:
Test
----
Tests/RegistryTest.php
.. literalinclude:: Tests/RegistryTest.php
:language: php
:linenos:
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural/Registry

37
Structural/index.rst Normal file
View File

@@ -0,0 +1,37 @@
Structural
==========
In Software Engineering, Structural Design Patterns are Design Patterns
that ease the design by identifying a simple way to realize
relationships between entities.
- `Adapter <Adapter>`__
`:notebook: <http://en.wikipedia.org/wiki/Adapter_pattern>`__
- `Bridge <Bridge>`__
`:notebook: <http://en.wikipedia.org/wiki/Bridge_pattern>`__
- `Composite <Composite>`__
`:notebook: <http://en.wikipedia.org/wiki/Composite_pattern>`__
- `DataMapper <DataMapper>`__
`:notebook: <http://en.wikipedia.org/wiki/Data_mapper_pattern>`__
- `Decorator <Decorator>`__
`:notebook: <http://en.wikipedia.org/wiki/Decorator_pattern>`__
- `DependencyInjection <DependencyInjection>`__
`:notebook: <http://en.wikipedia.org/wiki/Dependency_injection>`__
- `Facade <Facade>`__
`:notebook: <http://en.wikipedia.org/wiki/Facade_pattern>`__
- `FluentInterface <FluentInterface>`__
`:notebook: <http://en.wikipedia.org/wiki/Fluent_interface>`__
- `Proxy <Proxy>`__
`:notebook: <http://en.wikipedia.org/wiki/Proxy_pattern>`__
- `Registry <Registry>`__
`:notebook: <http://en.wikipedia.org/wiki/Service_locator_pattern>`__
Code
----
You can also find these code on `GitHub`_
Test
----
.. _`GitHub`: https://github.com/domnikl/DesignPatternsPHP/tree/master/Structural