mirror of
https://github.com/DesignPatternsPHP/DesignPatternsPHP.git
synced 2025-07-31 04:00:18 +02:00
some typo and comments
This commit is contained in:
@@ -8,7 +8,7 @@ namespace DesignPatterns\Command;
|
||||
* Purpose: To encapsulate invocation and decoupling
|
||||
*
|
||||
* We have an Invoker and a Receiver. This pattern use a "Command" to delegate the
|
||||
* method call against the Receiver and use the same method "execute".
|
||||
* method call against the Receiver and presents the same method "execute".
|
||||
* Therefore, the Invoker just know to call "execute" to process the Command of
|
||||
* the client. The Receiver is decoupled from the Invoker
|
||||
*
|
||||
@@ -28,7 +28,7 @@ interface Command
|
||||
|
||||
/**
|
||||
* this is the most important method in the Command pattern,
|
||||
* The Receiver go in the constructor.
|
||||
* The Receiver goes in the constructor.
|
||||
*/
|
||||
public function execute();
|
||||
}
|
||||
|
@@ -10,7 +10,7 @@ namespace DesignPatterns\Facade;
|
||||
* 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 folow the Law of Demeter.
|
||||
* 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.
|
||||
|
@@ -23,7 +23,7 @@ namespace DesignPatterns\Iterator;
|
||||
* arrays.
|
||||
*
|
||||
* If tomorrow you decide to read cards from a database, the client
|
||||
* (see the PHPUnit test) will remain unchanged. That's beauty of it.
|
||||
* (see the PHPUnit test) will remain unchanged. That's the beauty of it.
|
||||
*/
|
||||
class CardGame implements \Iterator
|
||||
{
|
||||
|
@@ -29,7 +29,7 @@ class FormTest extends \PHPUnit_Framework_TestCase
|
||||
|
||||
/**
|
||||
* The all point of this pattern, a Composite must inherit from the node
|
||||
* if you wanto to builld trees
|
||||
* if you want to builld trees
|
||||
*/
|
||||
public function testFormImplementsFormEelement()
|
||||
{
|
||||
|
@@ -46,6 +46,8 @@ class DecoratorTest extends \PHPUnit_Framework_TestCase
|
||||
}
|
||||
|
||||
/**
|
||||
* Second key-point of this pattern : the decorator is type-hinted
|
||||
*
|
||||
* @expectedException \PHPUnit_Framework_Error
|
||||
*/
|
||||
public function testDecoratorTypeHinted()
|
||||
@@ -53,6 +55,9 @@ class DecoratorTest extends \PHPUnit_Framework_TestCase
|
||||
$this->getMockForAbstractClass('DesignPatterns\Decorator\Decorator', array(new \stdClass()));
|
||||
}
|
||||
|
||||
/**
|
||||
* The decorator implements and wraps the same interface
|
||||
*/
|
||||
public function testDecoratorOnlyAcceptRenderer()
|
||||
{
|
||||
$mock = $this->getMock('DesignPatterns\Decorator\Renderer');
|
||||
|
@@ -9,9 +9,7 @@ namespace DesignPatterns\Tests\Iterator;
|
||||
use DesignPatterns\Iterator\CardGame;
|
||||
|
||||
/**
|
||||
* IteratorTest the CardGame iterator
|
||||
*
|
||||
* @author flo
|
||||
* IteratorTest tests the CardGame iterator
|
||||
*/
|
||||
class IteratorTest extends \PHPUnit_Framework_TestCase
|
||||
{
|
||||
@@ -25,7 +23,7 @@ class IteratorTest extends \PHPUnit_Framework_TestCase
|
||||
|
||||
/**
|
||||
* This is the client of the iterator.
|
||||
* It remains unchanged even if one I decide to use MongoDB to store the
|
||||
* It remains unchanged even if one day I decide to use MongoDB to store the
|
||||
* card.
|
||||
*/
|
||||
public function testCardinal()
|
||||
|
@@ -10,8 +10,6 @@ use DesignPatterns\SimpleFactory\ConcreteFactory;
|
||||
|
||||
/**
|
||||
* SimpleFactoryTest tests the Simple Factory pattern
|
||||
*
|
||||
* @author flo
|
||||
*/
|
||||
class SimpleFactoryTest extends \PHPUnit_Framework_TestCase
|
||||
{
|
||||
|
Reference in New Issue
Block a user