nicht angemeldet
Moin!
D - Dependency Inversion Principle: Dahinter verbirgt sich u.A. das, was als Dependency Injection bekannt ist. Wenn eine Klasse eine weitere Klasse für Unteraufgaben benötigt, soll es diese Klasse nicht selbst instanziieren, sondern sich von außen hereinreichen lassen.
Ich dachte, es wäre ebenfalls ein Grundsatz von OOP, dass eine Klasse oder allgemein ein Benutzer einer Klasse möglichst wenig über deren „Inneres“ wissen müssen sollte. Wie verträgt sich dies mit dem Grundsatz, in der Klasse benötigte Instanzen per DI mitzugeben, statt in der Klasse selbst zu erzeugen? Sollte ich nicht optimalerweise gar nicht wissen müssen, wie Unteraufgaben innerhalb der Klasse gelöst werden?
Dass ein Benutzer nicht wissen soll, wie eine Aufgabe konkret erledigt wird, nennt man Abstraktion. Er muss lediglich die Voraussetzungen schaffen und dann die Aufgabe ausführen lassen.
Nun ist aber keine Abstraktion der realen Welt vollkommen hermetisch.
Beispielsweise ist HTTP eine Abstraktion zum Zugriff auf Webseiten. Man kann in PHP problemlos file_get_contents("http://de.selfhtml.org/") ausführen und dadurch so tun, als wäre die HTML-Seite eine schlichte Textdatei. Die Abstraktion erfordert lediglich, dass man den Namen kennt (hier also die Adresse), und mit dieser Voraussetzung dann die Aktion ausführt ("Datei lesen").
Isoliert für sich betrachtet ist an der Abstraktion nichts böses, aber man sollte sich an dieser Stelle eben doch verdeutlichen, was technisch tatsächlich passiert: Es wird eben gerade NICHT auf eine lokale Datei auf der Festplatte des Webservers zugegriffen, sondern über ein potentiell unzuverlässiges Netzwerk mit möglicherweise hohen Latenzen und niedrigen Bandbreiten auf einen entfernten Server.
Wenn man also sein Programm so schreibt, als würde man davon ausgehen, dass dieser Lesezugriff immer so funktioniert, wie mit einer lokalen Datei, dann wird man sich in den Situationen, in denen das Netzwerk mal unzuverlässig funktioniert, gewisse Probleme einhandeln, weil man nicht darauf geachtet hat, dass hier eine nicht garantiert vorhandene Ressource genutzt wird.
Auf der anderen Seite verschenkt man unter Umständen auch Optimierungspotential. Denn während es beim Zugriff auf lokale Dateien auf einer einzigen Festplatte nicht wirklich optimal ist, viele Dateien parallel zum Lesen zu öffnen, ist ein paralleler Zugriff auf entfernte Netzressourcen sogar sehr gut geeignet, um das Lesen zu beschleunigen, weil viel Zeit mit Warten durch die Netz-Latenzen verschenkt wird.
Abstraktion ist also gut, weil es die unnötigen Details einer Aufgabenerledigung versteckt. Aber Abstraktion sollte nie als Blackbox verstanden werden, in die man nicht hineingucken darf. Im Gegenteil, man sollte sich für die Interna durchaus interessieren, um zu verstehen, welche Nutzungsarten eventuell besser sind, als andere.
Beispielsweise ist PHP als Sprache eine Abstraktion und Blackbox. Man benutzt PHP, ohne sich um die innere Funktionsweise Gedanken machen zu müssen. Aber wenn man weiß, wie PHP intern funktioniert, kann man es eventuell besser anwenden.
Dasselbe gilt für Datenbanken. Man kann Datenbanken benutzen, ohne wissen zu müssen, wie z.B. die Daten intern abgespeichert werden und wie das Schreiben und Lesen funktioniert. Aber wenn man sich dafür interessiert, wird man beispielsweise feststellen, dass bei MySQL die MyISAM-Tabellentypen viel langsamer beim parallelen Lesen und Schreiben sind, als die InnoDB-Tabellentypen. Rein auf SQL-Ebene ändert sich aber absolut nichts.
Und kommt es nicht auch zu einer Kollision damit,
- Ich bin auch kritisch eingestellt gegenüber der Strategie, schon sehr viel im Konstruktor auszuführen. Da Objekte üblicherweise erst einmal erstellt werden, und eventuell nie benutzt werden, zumindest nicht in allen Aspekten, sollte man die Dinge, die nicht zwingend zur Lebensfähigkeit des Objekts gehören, möglichst erst dann ausführen, wenn es tatsächlich notwendig ist.
denn wenn die Instanz einer für Unteraufgaben benötigten Klasse von außen herein gereicht wird, wird sie ja ebenfalls in jedem Fall erzeugt – auch wenn sie vielleicht nie benötigt wird.
Als Beispiel will ich eine Datenbanktabelle auslesen, programmiere mir dafür ein Objekt als Repräsentation der Tabelle, und dieses Objekt benötigt einen Datenbankconnector, um die Abfragen durchführen zu können.
Mein Tabellenobjekt benötigt zwingend einen Datenbankconnector, ansonsten kann es nicht funktionieren. Es gibt auch keine Möglichkeit, mit einem Default-Datenbankconnector zu arbeiten, denn welche Zugangsdaten soll man dafür nehmen? Also ist das ein Parameter im Konstruktor meines Tabellenobjekts, und damit kommuniziere ich dem Benutzer: Wenn du ein Tabellenobjekt haben willst, musst du einen Datenbankconnector haben.
Dieser Datenbankconnector muss also instanziiert werden. Und an DIESER Stelle ist es jetzt ein Unterschied, ob das Instanziieren einfach nur die im Konstruktor übergebenen DB-Zugangsdaten wegspeichert, oder ob auch noch gleich die Verbindung zur Datenbank hergestellt, die Zeichencodierung gesetzt und eine intern geführte DB-Statistik aktualisiert wird.
Ebenso ist es ein Unterschied, ob das Tabellenobjekt den Datenbankconnector seinerseits einfach nur intern wegspeichert, oder ob schon im Konstruktor die ersten Datenbankabfragen gestartet werden. Eventuell kann das Objekt ja das Datenbankschema auslesen und sich aufgrund dieser Informationen intern vorkonfigurieren - was auf den ersten Blick vielleicht nicht schlecht klingt, andererseits aber bedeutet, dass beim Bootstrapping der Applikation für jedes Tabellenobjekt, das instanziiert wird, dann mindestens ein Request an die Datenbank geht. Bei hundert Tabellen in der DB und hundert Tabellenobjekten in der Applikation, die alle beim Bootstrapping instanziiert werden, sind das hundert SQL-Queries mit immer denselben Ergebnissen und ohne die Gewissheit, dass auch wirklich alle Tabellenobjekte benutzt werden.
- Sven Rautenberg