info/DesignPatternsPHP
1
0
Fork 0
mirror of https://github.com/DesignPatternsPHP/DesignPatternsPHP.git synced 2025-02-24 09:42:24 +01:00
Code Issues Projects Releases Wiki Activity

adding comments

Browse Source
This commit is contained in:
Trismegiste 2013-05-12 14:32:16 +02:00
parent d2e86f1c35
commit a3648c449e
3 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
Mediator/Mediator.php
View File

@ -15,8 +15,9 @@ use DesignPatterns\Mediator\Subsystem;
* 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 objects (called Colleague) are coupled only to the MediatorInterface and
* it is a good thing because in OOP, one good friend is better than many unreliable.
* 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 (^_^)
*/

2
README.markdown
View File

@ -23,4 +23,4 @@ Changes I've made :
* Fixing the Adapter Pattern because it was buggy and incomplete (+ Tests)
* Adding Template Method Pattern (+ Tests)
* Adding Builder Pattern (+ Tests)
*
* Adding Mediator Pattern (+ Tests)

3
Tests/Mediator/MediatorTest.php
View File

@ -30,7 +30,10 @@ class MediatorTest extends \PHPUnit_Framework_TestCase
{
// testing if Hello World is output :
$this->expectOutputString('Hello World');
// as you see, the 3 components Client, Server and Database are totally decoupled
$this->client->request();
// Anyway, it remains complexity in the Mediator that's why the pattern
// Observer is preferable in mnay situations.
}
}