Wir kennen es sicher alle: Wir haben irgendein Objekt und wollen dessen Status oder einen bestimmten Wert setzen oder abfragen. Was passiert sicher in 95% aller Fälle? Es wird ein String- oder Integer-Wert gesetzt oder verglichen. Aus meiner Sicht nicht besonders elegant und erst recht nicht sicher, da der Wert unnötig oft überprüft werden muss.

Mit Enums haben wir den Vorteil, dass wir bestimmte Werte vorgeben können und auch nur diese zu Verfügung stehen. Da wir unter PHP nur “normale” Klassen verwenden können, haben wir dadurch immer automatisch einen bestimmten Typen.

Wir wollen nun den Status eines Benutzers in unserem System definieren und legen uns dazu folgende Klasse mit den erforderlichen Werten an.

<?php
class UserStatus extends Custom_Enum
{
  const ACTIVE    = 1;
  const NOTACTIVE = 2;
  const DELETED   = 3;
}

Damit können wir unseren Benutzern einen eindeutigen Status setzen.

<?php
class User
{
  public function setStatus(UserStatus $status)
  {
    // ..
  }
}

$user = new User();

$status = new UserStatus();
$user->setStatus($status->active());

Durch das Type-Hinting können wir schon bei der Parameterübergabe den richtigen Objekttypen sicherstellen und müssen darauf später nicht mehr extra prüfen.

Die Klasse Custom_Enum funktioniert mit Reflektion und etwas PHP-Magie und ist bislang erst nur ein grober Entwurf. Ein paar Überprüfungen und eine bessere Fehlerbehandlung wären dann noch notwendige Maßnahmen.

<?php
abstract class Custom_Enum
{
  private $_constants;  // array
  private $_index;  // string

  public function  __construct()
  {
    $rc = new ReflectionClass($this);
    $this->_constants = $rc->getConstants();
  }

  public function __call($method, $args)
  {
    if (preg_match('/^is([a-zA-Z]*?)$/', $method, $matches)) {
      return $this->is($matches[1]);
    }
    $this->set($method);
    return $this;
  }

  public function __toString()
  {
    return (string)$this->getValue();
  }

  public function set($index)
  {
    $this->_index = strtoupper($index);
    return $this;
  }

  public function is($index)
  {
    return strtoupper($index) == $this->_index;
  }

  public function getValue()
  {
    return $this->_constants[$this->_index];
  }
}

Ich finde das schon wesentlich besser als lose String- oder Integerwerte auszutauschen, aber vielleicht geht es ja noch besser und sicherer? Eure Ideen, Kritik, Fragen oder was auch immer sind dann in den Kommentaren gut aufgehoben. Also keine Scheu und diskutiert mit!

Es gibt aber auch Fälle, in denen die magische Methode __call() den Code lesbarer machen kann und gleichzeitig eine Menge Schreibarbeit einspart.

Stellen wir uns einfach mal vor, wir hätten ein Model mit 20 Werten und wollen es anhand eines bestimmten Feldes laden.

<?php
$model->load($id);  // lädt das Model mit Defaultkey = $id, oder

$model->load('Daniel', 'name');  // Feld 'name' = 'Daniel'

Letzteres ist durchaus gut zu lesen und lädt bestenfalls auch die richtigen Daten. Mit __call() lässt sich das ganze ohne viel Aufwand noch etwas dekorieren, so dass wir das Model dann so laden können:

<?php
$model->loadByName('Daniel');

Nun könnte man entweder für alle 20 Felder die jeweiligen Methoden schreiben, oder eine Art Template mit __call() und eines RegEx erstellen und den Aufruf einfach deligieren.

<?php
class Custom_Model
{
  public function __call($method, $args)
  {
    if (preg_match('/^loadBy([a-zA-Z]*?)$/', $method, $matches))
      return $this->load($args[0], $matches[1]);
    }
    // ...
  }
}

Der Vorteil ist ganz klar die eingesparte Tipparbeit und eine übersichtlichere Klasse, da wir alleine für diese Funktionalität 20 Methoden weniger im Code haben. Jedoch ist auch der Nachteil nicht außer Acht zu lassen. Weil die Methoden nur virtuell existieren, sind sie z.B. für die IDE unsichtbar und sind daher auch für neue Entwickler nicht sofort erkennbar.

Es bleibt also wieder dem eigenen Geschmack überlassen, für welchen Weg man sich entscheidet.

Und schon wieder die Frage, was kann unsere Klasse dann mehr? Oder warum machen wir das?

Oftmals haben wir Objekte, die eine gewisse Menge identischer Methoden benötigen, jedoch nicht aus einer Vererbungslinie stammen.

Durch die Plugins können wir dann quasi Funktionen an unsere Objekte dran kleben und nutzen. Diesen Code müssen wir nur einmal schreiben, haben auch nur eine Stelle im Code zu pflegen und können dadurch sicherstellen, dass alles gleich funktioniert.

So erweitern wir nun also zuerst wie gewohnt unser Custom_Model um ein paar neue Methoden und Eigenschaften.

<?php
class Custom_Model implements Custom_Model_Interface
{
  // ...
  protected $_plugins;

  public function registerPlugin() {}
  public function unregisterPlugin() {}
  // ...
}

Und das Interface für die Plugins.

<?php
interface Custom_Model_Plugin_Interface {}

Beim Speichern der Plugins kommt wieder die Klasse SplObjectStorage zum Einsatz, welche wir ja schon bei der Implementierung des Obeservers verwendet haben. Demnach ist es auch nicht überraschend, dass die Registrierung an die Abmeldung der Plugins sehr einfach wird.

public function registerPlugin(Custom_Model_Plugin_Interface $plugin)
{
  $this->_plugins->attach($plugin);
  return $this;
}

public function unregisterPlugin(Custom_Model_Plugin_Interface $plugin)
{
  $this->_plugins->detach($plugin);
  return $this;
}

Die Models müssen das Interface Custom_Model_Plugin_Interface implementieren. Dieses Interface ist lediglich ein Flag- oder Marker-Interface, d.h. es schreibt keine Methoden vor.

Jetzt noch eine kleine Änderung an der Methode __call() und wir können schon mit dem Beispiel experimentieren.

public function __call($method, $args)
{
  // Magie für die Getter & Setter

  foreach($this->_plugins as $plugin) {
    if(method_exists($plugin, $method)) {
      array_unshift($args, $this);
      return call_user_func_array(array($plugin, $method), $args);
    }
  }

  // Fehlerbehandlung
}

Durch __call() können wir unsere Plugin-Methoden so nutzen, als gehörten sie direkt zum Objekt. Die Art wie die Plugins verwendet werden  hat Vor-, aber auch Nachteile.

Die Liste der Plugins wird der Reihe nach durchlaufen und die erstbeste passende Methode wird aufgerufen. Auch die Getter oder Setter könnten wir nicht mehr überschreiben. Wenn das alles jedoch gewollt ist, dann lässt sich das aber auch mit wenigen Handgriffen erweitern.

Nun aber mal was praktisches zum Anschauen: Angenommen wir haben eine Model-Klasse mit Abhängigkeit zu anderen Objekten.

<?php
class Book extends Custom_Model
{
  protected $_id;
  protected $_title;
  protected $_ownerId;
}

Nun wollen wir nicht nur die ID des Besitzers erfahren, sondern auch das Objekt das bekommen können. Dafür spendieren wir ein Plugin.

<?php
class GetOwnerPlugin implements Custom_Model_Plugin_Interface
{
  public function getOwner($sender)
  {
    $id = $sender->getOwnerId();

    // lade User-Objekt $owner anhand der $id

    return $owner;
  }
}

Auf die Fehlerbehandlung habe ich an der Stelle mal verzichtet, sollte jedoch unbedingt stattfinden.

<?php
$book = new Book();
$book->registerPlugin(new GetOwnerPlugin());
$book->setOwnerId(42);
$owner = $book->getOwner();

Spätestens hier fällt sicher nicht nur mir auf, dass das Konzept noch Lücken hat. Theoretisch kann es sein, dass zu verschiedenen IDs ein User-Objekt nachgeladen werden soll (getAuthor(), getModifier(), getLastVisitor()…) und dann bräuchten wir sämtliche Methoden in unserem Plugin oder verschiedene Plugins.

Dann hätten wir aber auch wieder mehrfachen Code und nichts gewonnen. Daher werde ich die Pluginschnittstelle noch etwas aufbohren und das Ergebnis dann in einem meiner nächsten Artikel vorstellen.

Viele Methoden sind mit __call() implementiert und das hat die Nachteile, dass z.B. die Codecompletion, Reflection, automatische Dokumentation oder die Navigation in der IDE ausgehebelt werden.

Zum Glück können wir das ja zum Teil in vererbten Klassen wieder abfangen, ohne die ursprünglichen Klassen umschreiben zu müssen, z.B. weil wir die fremden Libraries zwecks späterer Updates nicht verändern wollen.

<?php

class A
{
  public function __call($method, $args)
  {
    echo __METHOD__ . ' ' . $method;
  }
}

class B extends A
{
  public function machWas()
  {
    parent::machWas();
  }
}

$b = new B();
$b->machWas();

Die Methode B::machWas() delegiert den Aufruf an die magische Methode, wobei sich das Verhalten nach außen nicht verändert, jedoch alles andere wieder funktionieren wird.

Aber welche Vor- und Nachteile haben denn nun die einzelnen Einstellungen?

“Lass es uns doch einfach halten”, “Das macht doch viel mehr Arbeit” oder “Mehr soll dieses Objekt nie können” und “Unsere Designer kennen das doch nur so” sind oft die Argumente warum die Eigenschaften public sein sollten.

Persönlich bin ich immer für eine saubere Datenkapselung und Verwendung von Zugriffsmethoden.

Zunächst ist es richtig, dass die Programmierung der Zugriffsmethoden mehr Arbeit macht, als einfach eine öffentliche Variable zu verwenden. Viele IDEs, z.B. Eclipse können diese Methoden aber auch automatisch generieren, so dass wirklich nur noch wenige Mausklicks nötig sind.

Viele andere Sprachen bieten die Typisierung von Variablen standardmäßig an, so dass man sich dort schon weitestgehend darauf verlassen kann welcher Typ vorliegt. PHP zum Beispiel bietet das (bislang) nicht und wir müssen uns selber darum kümmern.

Das schützt uns aber auch noch nicht davor, dass statt dem geforderten Objekttyp ein NULL-Wert gesetzt ist und wir mit einem Methodenaufruf einen Laufzeitfehler auslösen. Solche Anforderungen können wir dann in unseren Zugriffsmethoden umsetzen.

Wird einer Set-Methode ein NULL-Wert übergeben, so können wir entsprechend darauf reagieren und eine Exception werfen.

Ebenso können wir auch der Get-Methode eine nützliche Logik implementieren. Ist die Eigenschaft beim Methodenaufruf noch nicht gesetzt, können wir an dieser Stelle z.B. ein (Null-)Objekt erzeugen, einen bestimmten Wert aus der Datenbank laden oder einfach einen Standardwert zurückgeben.

Oftmals ergibt sich auch die Anforderung, auf Veränderungen an einem Objekt reagieren zu müssen. Dafür bietet sich das Observer/Beobachter-Entwurfsmuster an.

Die Beobachter müssen über eine Veränderung benachrichtigt werden und auch das funktioniert über die Zugriffsmethoden. Würden wir zu einem späteren Zeitpunkt feststellen, dass wir das Objekt beobachten müssen und dafür eine nachträgliche Veränderung der Schnittstelle erforderlich ist, bringt das meist sehr viel Arbeit und potentielle Fehlerquellen mit sich, da alle Stellen im Programm überarbeitet werden müssen, an denen das Objekt verwendet wird.

Es gibt natürlich auch immer wieder Situationen, die öffentliche Eigenschaften verlangen oder in denen die Handhabung einfacher wird, z.B. weil schon 150 Templates damit arbeiten und nicht extra angepasst werden sollen.

Verschiedene Sprachen bieten dafür Möglichkeiten an, um direkte Zugriffe auf Objekteigenschaften an Zugriffsmethoden zu delegieren.

Bei PHP ab Version 5 sind das die sogenannten Magischen Methoden oder Interceptor-Methoden __get() und __set().

Alles in allem haben wir bei der Programmierung unserer Klassen etwas mehr Aufwand, aber dafür weniger Stress, wenn sich unsere Anwendung in eine Richtung weiterentwickelt, die wir heute noch nicht vorhersehen können.