Kolumne: Quality Time

Von Operationen am offenen Herzen: Das Open Close Principle
Kommentare

In diesem zweiten Teil der Quality-Time-Serie zu den SOLID-Prinzipien nach Robert C. Martin [1] – alias Uncle Bob – geht es logischerweise um das „O“ in der Abkürzung. Haben Sie den ersten Teil der Serie verpasst? Kein Problem, wir haben ihn online unter [2] zum Nachlesen bereitgestellt.

PHP Magazin

Die Kolumne „Von Operationen am offenen Herzen“ von Tobias Schlitt ist erstmalig erschienen im PHP Magazin 5.2012

Das Open Close Principle, von dem das „O“ in SOLID herrührt, sagt grundsätzlich Folgendes aus: Es soll immer möglich sein, Softwarekomponenten wie Klassen und Module zu erweitern, ohne bestehenden Code verändern zu müssen. Die Hauptmotivation hierfür ist, dass bereits produktiv verwendeter Code als relativ stabil angesehen werden kann, insbesondere wenn extensiver Gebrauch von automatisierten Tests gemacht wird. Änderungen an diesem Code bringen aber immer das Risiko neuer Fehler mit sich, die im ungünstigsten Fall das ganze System beeinträchtigen. Aber ich möchte gar nicht in trockene Theorie verfallen, sondern wie üblich das Prinzip lieber an einem konkreten Beispiel erläutern (Listing 1).

Listing 1
class UserGateway
{
  public function loadUser( $userId )
  {
      $userData = Database::getInstance()->query( '...' );
      return $this->createUserFromResult( $userData );
  }
  public function storeUser( User $user )
  {
      $userInsert = $this->createInsertQuery( $user );
      Database::getInstance()->query( $userInsert );
  }
  //...
}

In diesem Beispiel sehen Sie die rudimentäre Klasse UserGateway, die in einem Projekt verwendet werden könnte, um Benutzerdaten aus der Datenbank zu laden und selbige zu speichern. Der Bequemlichkeit halber verwendet die gezeigte Implementierung das in der PHP-Welt immer noch sehr beliebte Singleton-Anti-Pattern. Neben vielen weiteren Problemen, die man sich damit einhandelt, nimmt man sich selbst jegliche Chance, Erweiterungen der aufgerufenen Database-Klasse einzuführen, ohne entweder deren Code anzufassen oder den Code, der die Klasse verwendet. Es wird also immer eine „Operation am offenen Herzen“ benötigt.

Sollen beispielsweise die ausgelösten Datenbankanfragen geloggt werden, muss das entweder durch Patchen der query()-Methode geschehen oder durch das Einführen einer setInstance()-Methode, mit der die Singleton-Instanz gegen ein Objekt einer anderen Klasse ausgetauscht wird. Damit ist dann auch der Traum vom echten Singleton dahin. Schlimmer wird es noch, wenn zum Beispiel zukünftig unterschiedliche Datenbankinstanzen in verschiedenen Modulen verwendet werden sollen.

Die Lösung dieses Dilemmas liegt an dieser Stelle in der einfachen Vermeidung des Singleton. Stattdessen geben Sie die Database-Instanz von außen in den UserGateway hinein und können so später einfach eine neue Implementierung des gleichen Interface, eine Ableitung oder Dekoration von Database verwenden, ohne den Code beider Klassen zu verändern (Listing 2).

Listing 2
class UserGateway
{
    private $database;

    public function __construct( Database $database )
    {
        $this->database = $database;
    }
    public function loadUser( $userId )
    {
        $userData = $this->database->query( '...' );
        return $this->createUserFromResult( $userData );
    }
    public function storeUser( User $user )
    {
        $userInsert = $this->createInsertQuery( $user );
        $this->database->query( $userInsert );
    }
    // ... 
}

Natürlich ist dieses Anwendungsbeispiel des Open Close Principle nur eines von vielen. Generell gilt es, bei der Entwicklung darauf zu achten, dass einzelne Elemente des Gesamtsystems immer einfach austauschbar bleiben. In einer idealen Welt kommen Sie so eines Tages an den Punkt, wo einmal geschriebener Code höchstens noch zur Fehlerbehebung verändert werden muss.

Natürlich muss, wie so oft im realen Leben, diese ideale Welt mit einer vernünftigen Portion Skepsis betrachtet werden. In wie weit die strikte Einhaltung des Open Close Principle Sinn ergibt, hängt ganz vom individuellen Projekt ab – und eine entsprechende Balance aus Purismus und Pragmatismus zu finden, stellt keine leichte Aufgabe dar. Klar sollte an dieser Stelle jedoch sein, dass das Prinzip in jedem Fall für Infrastrukturkomponenten einen essenziellen Mehrwert darstellt.

Tobias Schlitt ist Diplominformatiker (Uni) und arbeitet seit 1999 in professionellen Webprojekten auf Basis von PHP. Als Open-Source-Enthusiast beteiligt er sich an verschiedenen Communityprojekten. Tobias ist Mitgründer der Qafoo GmbH (http://qafoo.com), die Entwicklungsteams dabei unterstützt, hochqualitative Websoftware zu entwickeln. Dazu zählen unter anderem Consulting und Training zu Qualitätssicherungsprozessen und professionellem Software-Engineering.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -