Methoden statt Variablen
Ein Punkt, der mich beim Zend Framework irritiert hat, war die Klasse Zend_Db_Table_Abstract.
Ich musste dort einen Tabellennamen in eine Variable schreiben. Klingt
eigentlich ganz normal, aber was passiert, wenn man das vergisst? Der
Fehler tritt erst auf - meist mit einer Fehlermeldung, die nur aussagt,
dass das Query falsch sei -, wenn man versucht ein Query an die
Datenbank zu schicken. Ist das robust? Ich bezweifle es. Dieses
Verhalten gefällt mir einfach nicht, da man, wenn einem der Fehler
nicht sofort auffällt, erstmal suchen muss. Also einfach eine
Überprüfung implementieren, die eine Exception wirft, wenn man keinen
Tabellennamen angegeben hat? Auch eine Möglichkeit, aber nur
wirkungsvoll, wenn man beschreibt, wie man den Fehler beheben kann.
Denn ein Einsteiger wird nicht sofort wissen, was er falsch gemacht hat.
Um diesem Problem zu begegnen, benutze ich für diese meist statischen Werte abstrakte Methoden. Ein kurze Gegenüberstellung soll zeigen, was ich damit eigentlich meine:
// vorher (keine Fehlermeldung, wenn $_name nicht gesetzt ist!)
class Table extends Zend_Db_Table_Abstract
{
protected $_name = 'foobar';
}
Und jetzt meine robuste Variante:
abstract class Table_Abstract
{
/**
* Returns the name of the table.
*
* @return string
*/
abstract public function getName ();
}
class Table extends Table_Abstract
{
public function getName ()
{
return 'foobar';
}
}
Wenn die Methode nicht implementiert ist, kommt ein Fatal Error, der besagt, dass die Methode getName
nicht implementiert ist. Der Entwickler schaut also, was diese Methode
können muss: Sie muss den Namen der Tabelle zurückgeben. Implementiert,
es funktioniert!
Der Vorteil dieses Ansatzes liegt ganz klar auf dem Zwang, den Namen
der Tabelle in irgendeiner Weise zu setzen. Der Name kann natürlich
auch variabel zurückgegeben werden, z.B. aufgrund des Klassennamens.
Durch Implementieren der abstrakten Methode ist es möglich, eine
Implemtierung für dynamische Rückgabewerte direkt am richtigen Ort
auszuführen.