First of all you should understand the concept. This nice little “definition” (from flow3.typo3.org) sums it up pretty well:

A signal, which contains event information as it makes sense in the case at hand, can be emitted (sent) by any part of the code and is received by one or more slots, which can be any function in FLOW3 in extbase.

To get this running in extbase, you’ve to get hold of the Tx_Extbase_SignalSlot_Dispatcher, which is the central instance to manage all of it. Within Extbase that’s done easily with this snippet within your classes:

   ...
	/**
	 * @var Tx_Extbase_SignalSlot_Dispatcher
	 */
	protected $signalSlotDispatcher;

	/**
	 * @param Tx_Extbase_SignalSlot_Dispatcher $signalSlotDispatcher
	 */
	public function injectSignalSlotDispatcher(Tx_Extbase_SignalSlot_Dispatcher $signalSlotDispatcher) {
		$this->signalSlotDispatcher = $signalSlotDispatcher;
	}
   ...

Next thing is to make use of it. The Slot (listener) part could look like one of following blocks. In all cases you define the Signal by it’s class (not necessarily a PHP Class) and it’s name. Next to that the Slot can either be defined by a Closure, an object with a method name or a PHP-Class and a method name.

   ...
// Using a closure
$this->signalSlotDispatcher->connect(
      'Crunching', 'emitDataReady', function($data) { crunch($data) }, NULL, FALSE
);
   ...
// Using a method of the current object
$this->signalSlotDispatcher->connect(
     'Crunching', 'emitDataReady', $this, 'crunch', FALSE
);
   ...
// Using a method of the specified class
$this->signalSlotDispatcher->connect(
     'Crunching', 'emitDataReady', 'Cruncher', 'crunch', FALSE
);
   ...

To trigger the Signal which invokes the Slots registered above, you’ve to run the following code.

$this->signalSlotDispatcher->dispatch('Crunching', 'emitDataReady', array($data));

One thing I found was that by default the Tx_Extbase_SignalSlot_Dispatcher it not a Singleton in older extbase versions. Bastian fixed that already in the master and 1-4 branches and lucky enough this change was part within the TYPO3 4.6.1 release. But I think it’s still important to mention that this wasn’t the default from the beginning on.

Even if AOP is a nicer way to implement this feature, the extbase backport still works pretty straigh forward.

Edit: One thing I’ve to add – Felix is not “just” talking about Signal/Slots – he’s the one to thank for the backport. And now that his blog is running again – this post seems like a summary

As you see it’s pretty easy to have lists of objects in PHP. You might also think that always creating to some list-object over and over again is very odd and you’re right. For the most common tasks like iterating through arrays, directory-lists and a few more task you can use objects which are shipped with the Standard PHP Library ,which is also part of PHP since version 5 and mandatory in 5.3. So the example shown above could also look like this:

As I said at the beginning, there are lots of situations where you might want to have a list for something and if you store that list in PHP the Iterator-pattern can keep your code clean and tasty

Instead of typing the “if(object == null)” phrase again and again, you could use the Null-Object pattern, you’ll see that this can make some situations much clearer.

Basically Null-Object ensures that the client always receives a valid object for it’s interaction, so that there’s no need to do the check shown above again and again. This happens since your concrete Null-Object just shares the interface, or inherits from the same class as it’s effective counterpart, but it’s implementation just leaves out any effectiveness.

So a code-example could look like this:

class CookieFactory {
public function makeInstance() {
if(date(‘l’)==‘Monday’) return new NullCookie();
return new RealCookie();
}
}

interface iCookie {
function getCalories();
}

class RealCookie implements iCookie {
protected $calories=250;
public function getCalories() {
return $this->calories;
}
}

class NullCookie implements iCookie {
public function getCalories() {
return 0;
}
}

I think you can imagine what happens when you make use of the CookieFactory - diet on monday

There’re also some disadvantages, your clients normally don’t have a chance to react that there’s something special happening, also the clients must “share” the same expectation what “do nothing” means, the number of required Null-Objects might be very large and unhandy and the Null-Object shares a very deep knowledge with the real one, so that it might be a large effort to create it if the real object is complex too.

I’m so glad that today is tuesday

Sometimes this is what you also want to have in your software. To achieve different behaviour you normally just implement two different classes or aggregates and since they have the same “meaning” they normally share a interface (a.k.a Separated Interface). But who decides which implementation fits into the current environment/context?

The easiest way is to have a Factory Method with a small condition to decide this, but this method might grow very fast if you have various options. In this situation its also a matter of form to move this decision into some kind of configuration(-file) so that there’s only on file which differs in various environments.

Martin Fowler suggests to place some kind of mapping into the configuration-file, so that your Factory knows which implementation to instantiate in the current context. The key for the mapping in this case is the name of the Separated Interface.

As you see in the example code below, there are Cookie Tins which create contain Cookies and depending on the current month you want to use a more or less restrictive Cookie Tin. In May, June and July you restrict your application to create max. 5 cookies, the rest of the year you don’t care

	// The Separated Interface
interface CookieTin {
	public function getCookieInstance();
}

class NormalTin implements CookieTin {
	public function getCookieInstance() {
		return new Cookie();
	}
}

class DietTin implements CookieTin {
	protected $i=0;
	public function getCookieInstance() {
		return ($this->i++ < 5)?new Cookie():new NullCookie();
	}
}

// The Factory which supports Plugin-Creation
class CookieTinFactory {
	public static function getPlugin( $class ) {
		try {
			return new $GLOBALS['Plugins'][$class]();
		} catch( Exception $e) {
			// maybe call some default implementation if the mapping is wrong
		}
	}
}

class Cookie {
	public function printCalories() {
		echo ’200 ‘;
	}
}

class NullCookie extends Cookie{
	public function printCalories() { }
}

// This is usually in a configuration-file, normally this should
// also sit in a XML structure….

// That’s what it would be in 300 days/year
$GLOBALS['Plugins']['CookieTin'] = “NormalTin”;
// That’s what we have to turn it to before summer
if(in_array(date(‘n’),array(5,6,7))) {
	$GLOBALS['Plugins']['CookieTin'] = “DietTin”;
}

$tin = CookieTinFactory::getPlugin(‘CookieTin’);
$i=10;
while($i–) {
	$cookie = $tin->getCookieInstance();
	$cookie->printCalories();
}

A very common use-case for this is the changed behaviour in a testing-environment compared to the production-environment.
There's something else in the example beside the Plugin Pattern - I also made use of the Special Case (the NullCookie) pattern which I'm going to show in a future post....

Let’s say you have your grannies recipe for a chocolate cookie and you want to keep this in mind, but also you like to somehow experiment with some new or different ingredients. Normally you just keep in mind what you changed and later you write down the new recipe. But from time to time you might want to compare the two recipes or maybe you want to make cookies with the new and the changed recipes. In this situation it’s really good to have both written down on paper.

In the world of OOP you could think of a solution using the Memento-Pattern but this doesn’t really fit the situation and it’s also some kind of overhead. That’s the reason why the Value Object is the pattern of my choice.

So let’s look at the recipes again – we want to add and remove ingredients without modifying the original recipe and we want to compare the resulting recipes. We don’t need to track a special identity of our recipes since we’re only “collecting” ingredients.

The idea of the Value Object is that every every method which somehow transforms the state of a object always returns a new object and the old object stays untouched. Whenever needed you should also implement a method to compare objects, I must concede that the common “Money Example” shows much better when that’s needed …

Another edge of this pattern in PHP is that you can use method-chaining to perform multiple actions within a single line of code. So just have a look at the example you will like it’s taste

class Recipe {
	protected $ingredients;

	public function __construct($ingred=”) {
		$this->ingredients = implode(‘,’,array_unique(explode(‘,’,$ingred)));
	}

	public function addIncredient($ingred=”) {
		return new Recipe($this->ingredients.‘,’.$ingred);
	}

	public function removeIncredien($ingred=”) {
		return new Recipe(preg_replace(‘/,{0,1}’.$ingred.‘,{0,1}/’,”,$this->ingredients.‘,’));
	}

	public function printIncredients() {
		echo str_replace(‘,’,‘
’,$this->ingredients);
	}

	public function equals(Recipe $recipe) {
		return (strcmp($this->ingredients,$recipe->ingredients)===0)?true:false;
	}
}

$granniesRecipe = new Recipe(‘flour,baking soda,sugar,salt,butter,vanilla,chocolate’);
$aNewRecipe = $granniesRecipe->addIncredient(‘lemon’);
$coconutRecipe = $granniesRecipe->removeIncredien(‘chocolate’)->addIncredient(‘coconut’);

// check if that worked:
echo ‘
 Grannies Cookie Recipe – Incredients are:
’;
$granniesRecipe->printIncredients();
echo ‘
 A new Cookie Recipe could look like:
’;
$aNewRecipe->printIncredients();
echo ‘
 A coconut cookie would look like:
’;
$coconutRecipe->printIncredients();

The implementation is a bit odd, since it only collects the names of the ingredients but not the amount, but including the amounts of incredients would not change the concept and that’s why I left it out. I hope you got a idea how the pattern works – the main thing is that there’s no identity and that new objects are instantiated as soon as the state of the old one would change.

So the example just shows a cookie-machine which makes use of the prototype-pattern to create new cookies (depending on the cookie you throw in before)… yummy

abstract class Cookie {
function __clone() { }
abstract public function printFlavor();
}

class CoconutCookie extends Cookie {
public function printFlavor() {
echo ‘Coconut Flavor<br/>’;
}
}
class ChocolateCookie extends Cookie {
public function printFlavor() {
echo ‘Chocolate Flavor<br/>’;
}
}

class CookieMachine {
protected $cookie;
public function __construct(Cookie $cookie) {
$this->cookie = $cookie;
}
public function makeCookie() {
return clone $this->cookie;
}
}

The client-code can look like this:

$coconutCookie = new CoconutCookie();
$coconutCookieMachine = new CookieMachine($coconutCookie);

$chocolateCookie = new ChocolateCookie();
$chocolateCookieMachine = new CookieMachine($chocolateCookie);

//while(true) {
for($i=0;$i<5;$i++) {
$coconutCookieMachine->makeCookie()->printFlavor();
$chocolateCookieMachine->makeCookie()->printFlavor();
}

In the world of OOP it’s often much harder to collect a few objects out of a large number of different objects, also combining different requirements isn’t easy and that’s where the specification pattern can help you out. It implements some basic operations to combine requirements (AND, OR, NOT) and the only thing a concrete specification for a concrete class has to do is to implement a method (isSatisfied()) which is able to determine whether a object meats a requirement or not.

I splitted the generic part of the script and the cookie-example. The first part just implements the methods which are needed for the combination and provides a abstract class which is extended by the specifications in the second part. As you see the specification is combined which normally encapsulates the retrieval of the objects ,for example from a database. ….just have a look it’s really easy to select the right cookie … yummy

interface Specification {
	public function isSatisfiedBy($obj);
	public function _and(Specification $spec);
	public function _or(Specification $spec);
	public function _not();
}

abstract class AbstractSpecification implements Specification {
	public function isSatisfiedBy($obj) { }
	public function _and(Specification $spec) {
		return new AndSpecification($this, $spec);
	}
	public function _or(Specification $spec) {
		return new OrSpecification($this, $spec);
	}
	public function _not() {
		return new NotSpecification($this);
	}
}

class AndSpecification extends AbstractSpecification {
	private $spec1, $spec2;
	public function __construct(Specification $spec1, Specification $spec2) {
		$this->spec1 = $spec1;
		$this->spec2 = $spec2;
	}
	public function isSatisfiedBy($obj) {
		return $this->spec1->isSatisfiedBy($obj) && $this->spec2->isSatisfiedBy($obj);
	}
}

class OrSpecification extends AbstractSpecification {
	private $spec1, $spec2;
	public function __construct(Specification $spec1, Specification $spec2) {
		$this->spec1 = $spec1;
		$this->spec2 = $spec2;
	}
	public function isSatisfiedBy($obj) {
		return $this->spec1->isSatisfiedBy($obj) || $this->spec2->isSatisfiedBy($obj);
	}
}

class NotSpecification extends AbstractSpecification {
	private $spec;
	public function __construct(Specification $spec) {
		$this->spec = $spec;
	}
	public function isSatisfiedBy($obj) {
		return !$this->spec->isSatisfiedBy($obj);
	}
}

/**
* Cookie object just a container for the relevant data.
*
*/
class Cookie {
	protected $name,$flavor,$size;
	public function __construct($name=”,$flavor=‘chocolate’,$size=100) {
	$this->name=$name;
	$this->flavor = $flavor;
	$this->size = abs($size); // avoid negative size
	}
	public function getName() { return $this->name; }
	public function getFlavor() { return $this->flavor; }
	public function getSize() { return $this->size; }
}
/**
* Cookie service delivers cookies, offers some ways to select specific types of cookies
*
*/
class CookieService {
	protected $cookies = array();
	/**
	* Add a cookie to the collection
	* name is used as identifier, thats not the best choice
	* but it’s ok for the example
	*
	* @param Cookie $cookie
	*/
	public function add(Cookie $cookie) {
		$this->cookies[$cookie->getName()]=$cookie;
	}
	/**
	* Generic method to check which objects fit the spec
	*
	* @param Specification $spec
	*/
	private function filter(Specification $spec) {
		$result=array();
		reset($this->cookies);
		foreach($this->cookies as $name=>$cookie) {
			if($spec->isSatisfiedBy($cookie)) {
				$result[]=$cookie;
			}
		}
		return $result;
	}

	public function getLargeCookies() {
		$spec = new SmallCookieSpecification();
		$spec = $spec->_not();
		return $this->filter($spec);
	}
	public function getSmallChocolateCookies() {
		$spec = new SmallCookieSpecification();
		$spec = $spec->_and(new ChocolateCookieSpecification());
		return $this->filter($spec);
	}
	public function loadDummyData() {
		$this->add(new Cookie(‘Granny\’s classic’,‘chocolate’,60));
		$this->add(new Cookie(‘Modern Jumbo’,‘moca,chocolate’,180));
		$this->add(new Cookie(‘Kitchen Sink’,‘macadamia,cranberrie’,90));
		$this->add(new Cookie(‘Vanilla Cloud’,‘vanilla’,120));
		$this->add(new Cookie(‘Chocolate chip’,‘coconut,chocolate’,160));
	}
}

class SmallCookieSpecification extends AbstractSpecification {
	public function isSatisfiedBy($obj) {
		return $obj->getSize() < 100;
	}
}

class ChocolateCookieSpecification extends AbstractSpecification {
	public function isSatisfiedBy($obj) {
		return stristr(strtolower($obj->getFlavor()),‘chocolate’) !== FALSE;
	}
}

/**
* Client code
*/
$service = new CookieService();
$service->loadDummyData();
echo ‘
’;
var_dump($service->getLargeCookies());
var_dump($service->getSmallChocolateCookies());
echo ‘
’;

more information by E.Evans and M.Fowler

So maybe you already know the situation , your granny is going to bake cookies and you think of how they gonna taste – so cookie is our main-object and the different additional spices and other options which refine the taste of the cookies are the decoration for it. The cookies, pardon main-objects, are fine without the decoration but they’re much better with and the best thing is that you’re able to combine the decorations… yummy

So that’s how this would look like more technically:

stract class Cookie {
    protected $flavor;
    public function __construct($flavor) {
        $this->flavor=$flavor;
    }
    abstract public function descripeFlavor();
}

class GrannysCookie extends Cookie {
    public function descripeFlavor() {
        echo ‘
Granny baked a cookie which has a taste of ’;
        echo $this->flavor;
    }
}

abstract class CookieDecorator extends Cookie {
    protected $cookie;
    public function __construct(Cookie $cookie) {
        $this->cookie = $cookie;
    }
    //abstract public function descripeFlavor();
}

class FreshCookieDecorator extends CookieDecorator {
    public function descripeFlavor() {
        $this->cookie->descripeFlavor();
        echo ‘ which smells fresh from the oven’;
    }
}

class CrumbleCookieDecorator extends CookieDecorator {
    public function descripeFlavor() {
        $this->cookie->descripeFlavor();
        echo ‘ it has tasty crumbles ’;
    }
}

$cookie = new GrannysCookie(‘chocolate’);
$cookie->descripeFlavor();

$crumbleCookie = new CrumbleCookieDecorator($cookie);
$crumbleCookie->descripeFlavor();

$freshCookie = new FreshCookieDecorator($cookie);
$freshCookie->descripeFlavor();

$freshAndCrumbledCookie = new FreshCookieDecorator($crumbleCookie);
$freshAndCrumbledCookie->descripeFlavor();

additional Information