The Command Design Pattern in PHP 5

[FluffyCat]

New on November 29, 2005 for www.FluffyCat.com PHP 5 Design Pattern
Examples - the Command Pattern.

Since you all enjoyed the Visitor Pattern so much yesterday, today I
have the Command Pattern for you. This one is pretty straight
forward. In the Command Pattern an object encapsulates everything
needed to execute a method in another object.

http://www.fluffycat.com/SDCMSv2/PHP...terns-Command/

[Oli Filth]

FluffyCat wrote:

New on November 29, 2005 for www.FluffyCat.com PHP 5 Design Pattern
Examples - the Command Pattern.

Since you all enjoyed the Visitor Pattern so much yesterday, today I
have the Command Pattern for you. This one is pretty straight
forward. In the Command Pattern an object encapsulates everything
needed to execute a method in another object.

http://www.fluffycat.com/SDCMSv2/PHP...terns-Command/

Firstly, a typo - you have references to $plainVisitor, which is from
another example!!

Also, I'd recommend changing the name of BookCommandee to Book, because
that's all it is sematically.

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?".

--
Oli

[FluffyCat]

On 30 Nov 2005 08:42:45 -0800, "Oli Filth" <ca***@olifilth.co.uk>
wrote:

FluffyCat wrote:

New on November 29, 2005 for www.FluffyCat.com PHP 5 Design Pattern
Examples - the Command Pattern.

Since you all enjoyed the Visitor Pattern so much yesterday, today I
have the Command Pattern for you. This one is pretty straight
forward. In the Command Pattern an object encapsulates everything
needed to execute a method in another object.

http://www.fluffycat.com/SDCMSv2/PHP...terns-Command/

Firstly, a typo - you have references to $plainVisitor, which is from
another example!!

Also, I'd recommend changing the name of BookCommandee to Book, because
that's all it is sematically.

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?".

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. Interesting.

I have BookCommandee named as it is because other examples I have on
the site already use the plain vanilla Book class. So, I had to give
it a name other than Book.php in order to have similar classes in the
same directory. You are of course correct, Book would do the trick
naming wise if it didn't conflict with my other examples.

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. 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. This pattern is used, for example, in Java's EJBs.

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.

Again, thanks for checking it out and catching that typo!

[Oli Filth]

FluffyCat said the following on 30/11/2005 18:46:

On 30 Nov 2005 08:42:45 -0800, "Oli Filth" <ca***@olifilth.co.uk>
wrote:

FluffyCat wrote:

http://www.fluffycat.com/SDCMSv2/PHP...terns-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

[FluffyCat]

Good suggestions.

I added a function to testCommand which is only passed an instance of
Command. The function then calls $command_in->execute(). Hopefully
this will better illustrate that with the command pattern an instance
of Command encapsulates a call to another class.