© saicle/Shutterstock.com
Kolumne: Quality Time

Kolumne: Quality Time


Mit dem Buchstaben D erreichen wir die letzte Folge der aktuellen Serie über die SOLID-Prinzipien [1] nach Robert C. Martin. Falls Sie die ersten Teile der Serie zu diesen essenziellen Regeln des objektorientierten Softwaredesigns verpasst haben: Kein Problem, wir halten die Artikel unter [2] bis [5] zum Nachlesen für Sie bereit.

Das „Dependency Inversion Principle“ (D) beschreibt eine der wichtigsten Grundlagen der objektorientierten Anwendungsentwicklung: das Verstecken von Komplexität hinter der Fassade von Abstraktionen. Der Text des Prinzips gliedert sich in zwei Teile, die grob umrissen Folgendes besagen: a) Module auf höheren Ebenen sollten keine Abhängigkeiten auf Module niedrigerer Ebenen haben, sondern beide sollten von Abstraktionen abhängen. b) Abstraktionen sollten nicht von Implementierungsdetails abhängen, sondern die Details von der Abstraktion.

Wie so oft hilft ein praktisches Beispiel, um diesen theoretischen Zusammenhang besser zu erläutern (Listing 1).

Listing 1

class NewsLoader { public function __construct(GoogleNewsService $newsService, Logger $logger ) { $this->newsService = $newsService; $this->logger = $logger; } public function fetchNews( $offset = 0, $limit = null ) { // ... $this->logger->log( 'Fetched news.' ); // ... $this->logger->writeToFile(); } }

Die kleine NewsLoader-Klasse verwendet einen News-Service, um Nachrichten zu laden (fetchNews()) und einen Logger. So weit, so schön, so einfach. Problematisch ist allerdings, dass die Klasse nicht von abstrakten Konzepten abhängt, sondern von konkreten Implementierungen: Statt eine abstrakte NewsService-Klasse zu verlangen, wird die konkrete Realisierung auf Basis einer Google-Schnittstelle benötigt. Beim Logger sieht die Situation anders, aber nicht weniger schlimm aus. Zwar wird hier augenscheinlich eine Instanz von einem abstrakten Konzept Logger erwartet. Sehen Sie sich aber die zweite der gezeigten Codezeilen, in denen der Logger verwendet wird, an, ist das Problem zu erkennen: Der Aufruf der Methode writeToFile(), mit der scheinbar das letztendliche Schreiben der Log-Nachrichten auf die Festplatte angestoßen wird, spiegelt ganz klar ein Detail der Datei-Logger-Implementierung wider und gehört nicht zum abstrakten Konzept Logger. Dies wird insbesondere klar, wenn man sich alternative Implementierungen des Logger-Konzepts vorstellt: Ein DatabaseLogger oder ein GraylogLogger werden bestimmt nicht „in eine Datei“ schreiben.

Es liegt also zum einen eine direkte Abhängigkeit a...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang