Heute habe ich eine Artikel für euch, der mir besonders gefällt, weil er auf einfache Weise mehrere interessante Themen vereint. Und, wie sollte es auch anders sein, geht es wieder um unsere Models, um Entwurfsmuster und den Weltfrieden. *hust*
Bevor ich aber nun der Miss World 2010 die Scherpe streitig mache, fange ich lieber mal an…
Stellen wir uns mal vor, wir haben ein Meta-Model, welches verschiedene allgemeine Daten zu einem anderen Objekt speichern kann.
<?php
class MetaModel extends Custom_Model
{
protected $_ownerId;
protected $_creatorId;
protected $_modifierId;
protected $_createDate;
protected $_modifyDate;
// Weitere Felder und Getter/Setter
}
Die ersten drei Felder sind jeweils UserIds und die anderen zwei Datumswerte, die wir über gewöhnliche Getter und Setter verändern können. Damit können wir schonmal mit den Daten arbeiten, jedoch leider nicht objektorientiert navigieren.
Mit Navigation meine ich einen einfachen und für Menschen leicht lesbaren Zugriff auf die Objekte. Im Prinzip nur eine einfache Methodenverkettung.
<?php $ownerName = $object->getMeta()->getOwner()->getName();
Anders herum will ich vielleicht auch die Möglichkeit haben ein Datum als String oder als Objekt zu setzen und will ganz sicher nicht in jedem einzelnen Setter die Unterscheidung implementieren.
Die Lösung ist denkbar einfach. Wir lagern den benötigten Code einfach aus! Wer sich etwas mit Design Patterns beschäftigt, der erkennt sicher das Strategy Pattern wieder.
Als erstes definieren wir eine einfache Schnittstelle und bauen uns dannach einen “Accessor”.
<?php
interface Custom_Model_Access_Interface
{
public function get($value);
public function set($value);
}
<?php
class Custom_Model_Access_User implements Custom_Model_Access_Interface
{
/**
* @param int $value
* @return UserModel
public function get($value)
{
// UserModel laden ($value==ID)
}
/**
* @param mixed int|UserModel
* @return int (UserId)
*/
public function set($value)
{
// $value->getId() zurückgeben, wenn $value ein UserModel ist, sonst $value
}
}
Damit haben wir, wenn auch stark vereinfacht, die Logik ausgelagert und können sie nun in der Modelklasse nutzen. Für viele dieser Access-Objekte reicht eine Instanz aus, die wir am besten über eine einfache Factory erzeugen.
In unserem Model sieht das dann wie folgt aus.
<?php
class MetaModel extends Custom_Model
{
// ...
private $_accessUser;
public function init()
{
$this->_accessUser = Custom_Model_Access_Factory::singleton('User');
}
public function getOwner()
{
return $this->_accessUser->get( $this->getOwnerId() );
}
public function setOwner($owner)
{
return $this->setOwnerId( $this->_accessUser->set($owner) );
}
}
Nach diesem Muster würden nun auch die Methoden für creator und modifier geschrieben werden. An dieser Stelle wäre auch ein einfacher Cache möglich, damit das Objekt nicht bei jedem Aufruf erneut instanziiert werden muss.
Das Access-Objekt für das Datum könnte unter Umständen etwas umfangreicher werden.
Der Getter sollte uns ein Datums-Objekt zurückgeben anhand des in der Datenbank (oder wo auch immer) gespeicherten Werten, egal in welchem Format dieser vorliegt.
Der Setter auf der andern Seite könnte z.B. sämtlichen gängigen Datums-Objekte und Stringformate kennen und diese in das übliche Y-m-d H:i:s-Format übersetzen.
Zusammenfassend lässt sich festhalten, dass sich diese Technik für alle möglichen Bereiche geeignet ist, wenn man Objekte zu den Ids haben möchte oder auch Formate umwandeln will oder muss (Datum, IP-Adressen etc.).
Wenn euch noch etwas sinnvolles zur Verwendung einfällt oder einfach noch Fragen oder Kritik offen sind, dann freue ich mich über Kommentare.