By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,180 Members | 1,051 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,180 IT Pros & Developers. It's quick & easy.

The Command Design Pattern in PHP 5

P: n/a
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/
Nov 30 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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

Nov 30 '05 #2

P: n/a
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!
Nov 30 '05 #3

P: n/a
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
Nov 30 '05 #4

P: n/a

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.
Dec 1 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.