|
|
Posted by Oli Filth on 10/11/04 11:33
FluffyCat said the following on 30/11/2005 18:46:
> On 30 Nov 2005 08:42:45 -0800, "Oli Filth" <catch@olifilth.co.uk>
> wrote:
>
>>FluffyCat wrote:
>>
>>>http://www.fluffycat.com/SDCMSv2/PHP-Design-Patterns-Command/
>>
>>Firstly, a typo - you have references to $plainVisitor, which is from
>>another example!!
> Good catch on the typo, thanks! PHP saw that as resolving to NULL,
> and so not there, and thus allowed a parameter where one should not
> be.
You should turn error-checking up to E_ALL, perhaps!
>>Also, it would be more demonstrative if the logic to insert/remove the
>>stars was in the BookStarsOnCommand and BookStarsOffCommand classes,
>>i.e. remove BookCommandee::setStarsOn() and
>>BookCommandee::setStarsOff().
>>
>>Otherwise, it begs the question "why not just call $book->setStarsOn()
>>from testCommand.php?".
>
>
> The design of the Command pattern, which of course I did not design,
> is that the Command class executes an operation of another class. As
> I understand it, the Command class shouldn't contain or enhance the
> operation.
>
> The key word for the Command pattern is encapsulation.
But in your example, it doesn't encapsulate anything...
> You would use
> this if you wanted to allow access to one specific function in one
> specific object, but not necessarily give any additional access to the
> object.
>
In that instance, having Book implement an interface would make more
sense than having to define and instantiate a separate Commander class
which does nothing more than pass method calls...
> Perhaps my example doesn't emphasize this because testCommand creates
> BookCommandee and BookStarsOnCommand, and then goes on to use both.
> Perhaps if after creating BookStarsOnCommand it passed it to another
> class which could call only BookStarsOnCommand, but not access
> BookCommandee, it would make the intent clearer.
There's little point having an example of something if it doesn't
demonstrate its benefits and/or a sensible use!
To improve your example, you might demonstrate the benefits of treating
the Commanders polymorphically. e.g. along the lines of:
interface Command
{
function do();
}
class Eat implements Command
{ ... }
class Sleep implements Command
{ ... }
class GoToShops implements Command
{ ... }
function makeStuffHappen(Command $command)
{
$command->do();
}
$obj = new ObjectToBeControlled();
$commands = array(new Eat($obj), new Sleep($obj), new GoToShops($obj));
foreach ($commands as $cmd)
{
makeStuffHappen($cmd);
}
--
Oli
Navigation:
[Reply to this message]
|