Behavioral patterns tackle the challenge of communication between various objects. They describe how different objects and classes send messages to each other to make things happen. The following is a list of patterns we categorize as behavioral patterns:
The chain of responsibility pattern decouples the sender of a request from its receiver, by enabling more than one object to handle requests, in a chain manner. Various types of handling objects can be added dynamically to the chain. Using a recursive composition chain allows for an unlimited number of handling objects.
The following is an example of chain of responsibility pattern implementation:
abstract class SocialNotifier { private $notifyNext = null; public function notifyNext(SocialNotifier $notifier) { $this->notifyNext = $notifier; return $this->notifyNext; } final public function push($message) { $this->publish($message); if ($this->notifyNext !== null) { $this->notifyNext->push($message); } } abstract protected function publish($message); } class TwitterSocialNotifier extends SocialNotifier { public function publish($message) { // Implementation... } } class FacebookSocialNotifier extends SocialNotifier { protected function publish($message) { // Implementation... } } class PinterestSocialNotifier extends SocialNotifier { protected function publish($message) { // Implementation... } } // Client $notifier = new TwitterSocialNotifier(); $notifier->notifyNext(new FacebookSocialNotifier()) ->notifyNext(new PinterestSocialNotifier()); $notifier->push('Awesome new product available!');
We started off by creating an abstract SocialNotifier
class with the abstract method publish
, notifyNext
, and push
method implementations. We then defined TwitterSocialNotifier
, FacebookSocialNotifier
, and PinterestSocialNotifier
, all of which extend the abstract SocialNotifier
. The client starts by instantiating the TwitterSocialNotifier
, followed by two notifyNext
calls, passing it instances of two other notifier
types before it calls the final push
method.
The command pattern decouples the object that executes certain operations from objects that know how to use it. It does so by encapsulating all of the relevant information needed for later execution of a certain action. This implies information about object, method name, and method parameters.
The following is an example of command pattern implementation:
interface LightBulbCommand { public function execute(); } class LightBulbControl { public function turnOn() { echo 'LightBulb turnOn'; } public function turnOff() { echo 'LightBulb turnOff'; } } class TurnOnLightBulb implements LightBulbCommand { private $lightBulbControl; public function __construct(LightBulbControl $lightBulbControl) { $this->lightBulbControl = $lightBulbControl; } public function execute() { $this->lightBulbControl->turnOn(); } } class TurnOffLightBulb implements LightBulbCommand { private $lightBulbControl; public function __construct(LightBulbControl $lightBulbControl) { $this->lightBulbControl = $lightBulbControl; } public function execute() { $this->lightBulbControl->turnOff(); } } // Client $command = new TurnOffLightBulb(new LightBulbControl()); $command->execute();
We started off by creating a LightBulbCommand
interface. We then defined the LightBulbControl
class that provides two simple turnOn
/ turnOff
methods. Then we defined the TurnOnLightBulb
and TurnOffLightBulb
classes which implement the LightBulbCommand
interface. Finally, the client is instantiating the TurnOffLightBulb
object with an instance of LightBulbControl
, and calling the execute
method on it.
The interpreter pattern specifies how to evaluate language grammar or expressions. We define a representation for language grammar along with an interpreter. Representation of language grammar uses composite class hierarchy, where rules are mapped to classes. The interpreter then uses the representation to interpret expressions in the language.
The following is an example of interpreter pattern implementation:
interface MathExpression { public function interpret(array $values); } class Variable implements MathExpression { private $char; public function __construct($char) { $this->char = $char; } public function interpret(array $values) { return $values[$this->char]; } } class Literal implements MathExpression { private $value; public function __construct($value) { $this->value = $value; } public function interpret(array $values) { return $this->value; } } class Sum implements MathExpression { private $x; private $y; public function __construct(MathExpression $x, MathExpression $y) { $this->x = $x; $this->y = $y; } public function interpret(array $values) { return $this->x->interpret($values) + $this->y->interpret($values); } } class Product implements MathExpression { private $x; private $y; public function __construct(MathExpression $x, MathExpression $y) { $this->x = $x; $this->y = $y; } public function interpret(array $values) { return $this->x->interpret($values) * $this->y->interpret($values); } } // Client $expression = new Product( new Literal(5), new Sum( new Variable('c'), new Literal(2) ) ); echo $expression->interpret(array('c' => 3)); // 25
We started off by creating a MathExpression
interface, with a single interpret
method. We then add Variable
, Literal
, Sum
, and Product
classes, all of which implement the MathExpression
interface. The client then instantiates from the Product
class, passing it instances of Literal
and Sum
, finishing with an interpret
method call.
The iterator pattern is used to traverse a container and access its elements. In other words, one class becomes able to traverse the elements of another class. The PHP has a native support for the iterator as part of built in Iterator
and IteratorAggregate
interfaces.
The following is an example of iterator pattern implementation:
class ProductIterator implements Iterator { private $position = 0; private $productsCollection; public function __construct(ProductCollection $productsCollection) { $this->productsCollection = $productsCollection; } public function current() { return $this->productsCollection->getProduct($this->position); } public function key() { return $this->position; } public function next() { $this->position++; } public function rewind() { $this->position = 0; } public function valid() { return !is_null($this->productsCollection->getProduct($this->position)); } } class ProductCollection implements IteratorAggregate { private $products = array(); public function getIterator() { return new ProductIterator($this); } public function addProduct($string) { $this->products[] = $string; } public function getProduct($key) { if (isset($this->products[$key])) { return $this->products[$key]; } return null; } public function isEmpty() { return empty($products); } } $products = new ProductCollection(); $products->addProduct('T-Shirt Red'); $products->addProduct('T-Shirt Blue'); $products->addProduct('T-Shirt Green'); $products->addProduct('T-Shirt Yellow'); foreach ($products as $product) { var_dump($product); }
We started off by creating a ProductIterator
which implements the standard PHP Iterator
interface. We then added the ProductCollection
which implements the standard PHP IteratorAggregate
interface. The client creates an instance of ProductCollection
, stacking values into it via the addProduct
method call and loops through the entire collection.
The more classes we have in our software, the more complex their communication becomes. The mediator pattern addresses this complexity by encapsulating it into a mediator object. Objects no longer communicate directly, but rather through a mediator object, therefore lowering the overall coupling.
The following is an example of mediator pattern implementation:
interface MediatorInterface { public function fight(); public function talk(); public function registerA(ColleagueA $a); public function registerB(ColleagueB $b); } class ConcreteMediator implements MediatorInterface { protected $talk; // ColleagueA protected $fight; // ColleagueB public function registerA(ColleagueA $a) { $this->talk = $a; } public function registerB(ColleagueB $b) { $this->fight = $b; } public function fight() { echo 'fighting...'; } public function talk() { echo 'talking...'; } } abstract class Colleague { protected $mediator; // MediatorInterface public abstract function doSomething(); } class ColleagueA extends Colleague { public function __construct(MediatorInterface $mediator) { $this->mediator = $mediator; $this->mediator->registerA($this); } public function doSomething() { $this->mediator->talk(); } } class ColleagueB extends Colleague { public function __construct(MediatorInterface $mediator) { $this->mediator = $mediator; $this->mediator->registerB($this); } public function doSomething() { $this->mediator->fight(); } } // Client $mediator = new ConcreteMediator(); $talkColleague = new ColleagueA($mediator); $fightColleague = new ColleagueB($mediator); $talkColleague->doSomething(); $fightColleague->doSomething();
We started off by creating a MediatorInterface
with several methods, implemented by the ConcreteMediator
class. We then defined the abstract class Colleague
to force the doSomething
method implementation on the following ColleagueA
and ColleagueB
classes. The client instantiates the ConcreteMediator
first, and passes its instance to the instances of ColleagueA
and ColleagueB
, upon which it calls the doSomething
method.
The memento pattern provides the object restore functionality. Implementation is done through three different objects; originator, caretaker, and a memento, where the originator is the one preserving the internal state required for a later restore.
The following is an example of memento pattern implementation:
class Memento { private $state; public function __construct($state) { $this->state = $state; } public function getState() { return $this->state; } } class Originator { private $state; public function setState($state) { return $this->state = $state; } public function getState() { return $this->state; } public function saveToMemento() { return new Memento($this->state); } public function restoreFromMemento(Memento $memento) { $this->state = $memento->getState(); } } // Client - Caretaker $savedStates = array(); $originator = new Originator(); $originator->setState('new'); $originator->setState('pending'); $savedStates[] = $originator->saveToMemento(); $originator->setState('processing'); $savedStates[] = $originator->saveToMemento(); $originator->setState('complete'); $originator->restoreFromMemento($savedStates[1]); echo $originator->getState(); // processing
We started off by creating a Memento
class, which will provide the a current state of the object through the getState
method. We then defined the Originator
class that pushed the state to Memento
. Finally, the client takes the role of caretaker
by instantiating Originator
, juggling among its few states, saving and restoring them from memento
.
The observer pattern implements a one-too-many dependency between objects. The object that holds the list of dependencies is called subject, while the dependents are called observers. When the subject object changes state, all of the dependents are notified and updated automatically.
The following is an example of observer pattern implementation:
class Customer implements SplSubject { protected $data = array(); protected $observers = array(); public function attach(SplObserver $observer) { $this->observers[] = $observer; } public function detach(SplObserver $observer) { $index = array_search($observer, $this->observers); if ($index !== false) { unset($this->observers[$index]); } } public function notify() { foreach ($this->observers as $observer) { $observer->update($this); echo 'observer updated'; } } public function __set($name, $value) { $this->data[$name] = $value; // notify the observers, that user has been updated $this->notify(); } } class CustomerObserver implements SplObserver { public function update(SplSubject $subject) { /* Implementation... */ } } // Client $user = new Customer(); $customerObserver = new CustomerObserver(); $user->attach($customerObserver); $user->name = 'John Doe'; $user->email = '[email protected]';
We started off by creating a Customer
class which implements the standard PHP SplSubject
interface. We then defined the CustomerObserver
class which implements the standard PHP SplObserver
interface. Finally, the client instantiates the Customer
and CustomerObserver
objects and attaches the CustomerObserver
objects to Customer
. Any changes to name
and email
properties are then caught by the observer
.
The state pattern encapsulates the varying behavior for the same object based on its internal state, making an object appear as if it has changed its class.
The following is an example of state pattern implementation:
interface Statelike { public function writeName(StateContext $context, $name); } class StateLowerCase implements Statelike { public function writeName(StateContext $context, $name) { echo strtolower($name); $context->setState(new StateMultipleUpperCase()); } } class StateMultipleUpperCase implements Statelike { private $count = 0; public function writeName(StateContext $context, $name) { $this->count++; echo strtoupper($name); /* Change state after two invocations */ if ($this->count > 1) { $context->setState(new StateLowerCase()); } } } class StateContext { private $state; public function setState(Statelike $state) { $this->state = $state; } public function writeName($name) { $this->state->writeName($this, $name); } } // Client $stateContext = new StateContext(); $stateContext->setState(new StateLowerCase()); $stateContext->writeName('Monday'); $stateContext->writeName('Tuesday'); $stateContext->writeName('Wednesday'); $stateContext->writeName('Thursday'); $stateContext->writeName('Friday'); $stateContext->writeName('Saturday'); $stateContext->writeName('Sunday');
We started off by creating a Statelike
interface, followed by StateLowerCase
and StateMultipleUpperCase
which implement that interface. The StateMultipleUpperCase
has a bit of counting logic added to its writeName
, so it kicks off the new state after two invocations. We then defined the StateContext
class, which we will use to switch contexts. Finally, the client instantiates the StateContext
, and passes an instance of StateLowerCase
to it through the setState
method, followed by several writeName
methods.
The strategy pattern defines a family of algorithms, each of which is encapsulated and made interchangeable with other members within that family.
The following is an example of strategy pattern implementation:
interface PaymentStrategy { public function pay($amount); } class StripePayment implements PaymentStrategy { public function pay($amount) { echo 'StripePayment...'; } } class PayPalPayment implements PaymentStrategy { public function pay($amount) { echo 'PayPalPayment...'; } } class Checkout { private $amount = 0; public function __construct($amount = 0) { $this->amount = $amount; } public function capturePayment() { if ($this->amount > 99.99) { $payment = new PayPalPayment(); } else { $payment = new StripePayment(); } $payment->pay($this->amount); } } $checkout = new Checkout(49.99); $checkout->capturePayment(); // StripePayment... $checkout = new Checkout(199.99); $checkout->capturePayment(); // PayPalPayment...
We started off by creating a PaymentStrategy
interface followed with concrete classes StripePayment
and PayPalPayment
which implement it. We then defined the Checkout
class with a bit of decision making logic within the capturePayment
method. Finally, the client instantiates the Checkout
, passing a certain amount through its constructor. Based on the amount, the Checkout
internally triggers one or another payment
when capturePayment
is called.
The template design pattern defines the program skeleton of an algorithm in a method. It lets us, via use of class overriding, redefine certain steps of an algorithm without really changing the algorithm's structure.
The following is an example of template pattern implementation:
abstract class Game { private $playersCount; abstract function initializeGame(); abstract function makePlay($player); abstract function endOfGame(); abstract function printWinner(); public function playOneGame($playersCount) { $this->playersCount = $playersCount; $this->initializeGame(); $j = 0; while (!$this->endOfGame()) { $this->makePlay($j); $j = ($j + 1) % $playersCount; } $this->printWinner(); } } class Monopoly extends Game { public function initializeGame() { // Implementation... } public function makePlay($player) { // Implementation... } public function endOfGame() { // Implementation... } public function printWinner() { // Implementation... } } class Chess extends Game { public function initializeGame() { // Implementation... } public function makePlay($player) { // Implementation... } public function endOfGame() { // Implementation... } public function printWinner() { // Implementation... } } $game = new Chess(); $game->playOneGame(2); $game = new Monopoly(); $game->playOneGame(4);
We started off by creating an abstract Game
class that provides all of the actual abstract methods encapsulating the game-play. We then defined the Monopoly
and Chess
classes, both of which extend from the Game
class, implementing game specific method game-play for each. The client simply instantiates the Monopoly
and Chess
objects, calling the playOneGame
method on each.
The visitor design pattern is a way of separating an algorithm from an object structure on which it operates. As a result, we are able to add new operations to existing object structures without actually modifying those structures.
The following is an example of visitor pattern implementation:
interface RoleVisitorInterface { public function visitUser(User $role); public function visitGroup(Group $role); } class RolePrintVisitor implements RoleVisitorInterface { public function visitGroup(Group $role) { echo 'Role: ' . $role->getName(); } public function visitUser(User $role) { echo 'Role: ' . $role->getName(); } } abstract class Role { public function accept(RoleVisitorInterface $visitor) { $klass = get_called_class(); preg_match('#([^\\]+)$#', $klass, $extract); $visitingMethod = 'visit' . $extract[1]; if (!method_exists(__NAMESPACE__ . 'RoleVisitorInterface', $visitingMethod)) { throw new InvalidArgumentException("The visitor you provide cannot visit a $klass instance"); } call_user_func(array($visitor, $visitingMethod), $this); } } class User extends Role { protected $name; public function __construct($name) { $this->name = (string)$name; } public function getName() { return 'User ' . $this->name; } } class Group extends Role { protected $name; public function __construct($name) { $this->name = (string)$name; } public function getName() { return 'Group: ' . $this->name; } } $group = new Group('my group'); $user = new User('my user'); $visitor = new RolePrintVisitor; $group->accept($visitor); $user->accept($visitor);
We started off by creating a RoleVisitorInterface
, followed by RolePrintVisitor
which implements the RoleVisitorInterface
itself. We then defined the abstract class Role
, with an accept method taking in the RoleVisitorInterface
parameter type. We further defined the concrete User
and Group
classes, both of which extend from Role
. The client instantiates User
, Group
, and the RolePrintVisitor
; passing in the visitor
to the accept method call of User
and Group
instances.
52.14.168.56