Query Object [PoEEA]

Posted: June 20th, 2008 | Author: | Tags: , , , , , | Comments Off

Maybe you remember the Specification Pattern I explained some weeks ago. It enabled a easy and intuitive searching within large object-collections. A drawback of my example was that I stored the objects in the memory. This can be really ineffective if you want a single object out of hundreds, because you have to create all of them to see which one fits the specification.
Normally you want to limit the number of objects and you also don’t store large datasets in memory. The idea of the Query Object pattern is that it enables a usage, comparable to the specification pattern, for objects which are persisted in a database. The benefit is that it creates a query to exclude objects which won’t satisfy your needs and therefore you wont mess up the memory anymore.
Once you have a query-object in place you should not get in touch with SQL anymore because it can encapsulate SQL completely, at least if you also have some kind of data mapping (coming soon), which is a great benefit for everyone who is not so familiar with SQL. (But don’t forget, regarding performance, SQL-optimization is a very important thing).

So what we need for the Query Object in first place is a object, I’ll use the Cookie out of the specification pattern post again. Then we need criteria-objects which hold the information for a single criteria, (determined by “database-field”, “operator” and “value”) and we also need the Query Objects itself to wrap up the SQL-querying and the object creation somehow.

A very simple example could look like this:




interface Critera {
public function getWhereClause();
}

class CookieCriteria implements Critera {

private $operator,$field,$value;

protected function __construct($operator,$field,$value) {
$this->operator=$operator;
$this->field=$field;
$this->value=$value;
}

public function getWhereClause() {
return implode(” “,array($this->field,$this->operator,$this->value));
}

public static function matches($field,$value) {
return new CookieCriteria(“LIKE”,$field,‘”‘.$value.‘”‘);
}

public static function greaterThan($field,$value) {
return new CookieCriteria(“>”,$field,$value);
}
}

class CookieFinder {
protected $criterias;

public function addCriteria(Critera $criteria) {
$this->criterias[] = $criteria;
}

public function generateSQL() {
$sql = “SELECT * FROM cookies”;

if(sizeof($this->criterias)) {
$where=array();
reset($this->criterias);
while(list(,$criteria)=each($this->criterias)) {
$where[] = $criteria->getWhereClause();
}
$sql.= sizeof($where)?” WHERE “.implode(” AND “,$where):“”;
}
return $sql;
}

public function find() {
$collection = array();
if(!$result = mysql_query($this->generateSQL())) {
throw new Exception(mysql_errno());
}
while($row = mysql_fetch_assoc($result)) {
$collection[] = new Cookie($row['name'],$row['flavor'],$name['size']);
}
return $collection;
}
}


Possible client code could look like this:
$finder = new CookieFinder();
$finder->addCriteria(CookieCriteria::matches(“name”,“Granny%”));
$finder->addCriteria(CookieCriteria::greaterThan(“size”,100));
$cookies = $finder->find();

We just pick up the Query Object, add one or more criteria and ask it to create the objects which fit them.

So this example is not as powerful as the one I used for the Specification pattern, but it should be a easy task to create some kind of “nested criteria objects”.
Query objects normally make use of data-mapping so that you can handle various classes, stored in different tables/databases, with a single and generic Query Object. This also enables to avoid SQL-Injection, since you’re able to validate the fields and values before you sent them to your database, also some kind of database abstraction would be possible.
With the “Query Object by example“, which requires to build up a single object which is used as blueprint for the required objects, exists another flavor of this pattern which is very handy to use and more descriptive.
But no matter which flavor you prefer, Query Objects bring some real benefits when you’ve to handle complex datasets – for smaller projects the effort might be to much so be careful where you use it.

Plugin [PoEAA]

Posted: June 5th, 2008 | Author: | Tags: , , , | Comments Off

I’m sure you’re pretty often in the situation that you have to switch something depending on the context you’re currently in. For example most people change their eating habits before summer – I also do :P

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 :P 

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

Prototype [GoF]

Posted: May 28th, 2008 | Author: | Tags: , , | Comments Off

Imagine a cookie-oven which produces tasty cookies with chocolate crumbles. How do you ensure that the 1000th cookie still has the same taste as the first?
You might think that this is an easy task – just write down the recipe and follow the described steps…you know the result in real life – the 1000th cookie normally tasts like the 1st but you always had the “overhead” to read the recipe and go through the steps again and again.
In OOP it’s much easier to follow the recipe just instantiate a new Object and there you go… no matter if it’s the 1st or the 1000th – it’ll always taste look similar.
But the “recipe-overhead” is still there in a way and especially when you have larger objects whose construction is time-consuming you might want to somehow get rid of it. And that’s where a Prototype can help you out – you just create the first Cookie Object and then you use the handy magic method __clone to create new objects.
Instead of just using __clone the pattern suggests a class (some kind of a factory-class) so that you can also encapsulate the creation of the objects (and also possible adjustments you might want to make after the creation/clone).

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();
}

Singelton [GoF]

Posted: May 23rd, 2008 | Author: | Tags: , , , | Comments Off

Tis pattern is a very well know and a often discussed one.

Explaining it the tasty way: let’s say you have exactly one well know place where you store all your cookies and whenever you need one you can easy point to that place. Normally that’s really comfortable because whatever you do with it, you don’t have to search some place where you can find a cookie, you just go to that single “cookie tin” (or wherever you store cookies) and put a new cookie into it ;)

In modern OOP the singleton is not very popular, Eric Evans simple calls it anti-pattern. It makes it much harder to test your software and normally the user of the class, not the class itself, should know how many instances are needed.

But nevertheless for small applications it’s very comfortable to use it in some situations and as long as you’re also familiar with the drawbacks I think it’s ok to consider using it….

So the example shows a cookie tin and how to use it and by the way it also implements some kind of lowlevel registry by using the PHP5 magic methods, but that’s another story ;) 

/**
* CookieTin a.k.a Singleton object
* we want to force our application
* to hold exactly one CookieTin object
*/
class CookieTin {
	private $_cookies=array();

	/* generic singleton part start*/

	private static $_instance=NULL;
	// prevent instatiation from the outside
	private function __construct() { }

	// prevent cloning
	private function __clone() {}

	public static function getInstance() {
		if(!self::$_instance) {
			self::$_instance = new self();
		}
		return self::$_instance;
	}
	/* generic singleton part end */

	/* registry part start */
	public static function __set($key,Cookie $value) {
		echo “call setter\n”;
		self::$_instance->_cookies[$key] = $value;
	}

	public static function __get($key) {
		echo “call getter\n”;
		return self::$_instance->_cookies[$key];
	}

	public static function __isset($key) {
		echo “call isset\n”;
		return isset(self::$_instance->_cookies[$key]);
	}

	public static function __unset($key) {
		echo “call unset\n”;
		unset(self::$_instance->_cookies[$key]);
	}
/* registry part end */
}
/**
* Dummy Cookie
*/
class Cookie {
	public $name,$flavor;
}

$tin = CookieTin::getInstance();
if(!isset($tin->granniescookie)) {
	$tin->granniescookie = new Cookie();
	$tin->granniescookie->name=“Grannies chocolate wonder”;
	$tin->granniescookie->flavor=“chocolate”;
}

CookieTin::getInstance()->granniescookie->flavor = “chocolte chips”;

var_dump($tin);
unset(CookieTin::getInstance()->granniescookie);
var_dump($tin);

The really important things happen in the last lines where the CookieTin is accessed statically and this change also (as you will see yourself) is reflected in the local instance if the $tin.