Programmierer neigen ja dazu, möglichst viele Probleme selbst lösen zu wollen. Man bekommt es mehr oder minder mit in die Programmierer-Wiege gelegt und fängt bald an, statt nur kleineren Problemen den Garaus zu machen auch komplexe Probleme zum tausendsten Mal neu zu lösen.
(Nur mal so als Offtopic zwischen drin: Ich hab gerade festgestellt, das es eigentlich gar keinen Garaus gibt. Wohl nur in dieser einen einzigen Redewendung… Weder Wikipedia noch der Duden wissen Bescheid.)
Aber wie dem auch sei: Die besten Programmierer sind die faulsten. Sie adaptieren bekannte Problemlösungen für ihre Projekte und delegieren Probleme weiter an andere Anwendungen, Frameworks oder Bibliotheken statt das Rad zum millionsten Mal neu zu erfinden.
Welche Arten der Delegierung gibt es und wann sind sie sinnvoll anzuwenden?
Ein kurzer Überblick macht klar, was ich meine:
- Applikations-Delegierung: Es gibt eine Anwendung, die besser geeignet ist, ein Problem zu lösen, als die Anwendung, in der man gerade entwickelt. Meist gibt es eine API oder Schnittstelle um die betreffende Applikation anzusprechen. Klassisches Beispiel: Die Datenbank.
- Bibliotheks-Delegierung: Auch sehr verbreitet - hier werden Teilaufgaben an externe Klassen und Implementierungen abgegeben. Die Bibliotheks-Delegierung umfasst oft nur einzelne kleinere Bestandteile einer Applikation.
- Framework-Delegierung: Immer öfter bildet ein Framework die Architektonische Basis einer Applikation. Hier werden die Grundelemente der Applikation im großen Stil abstrakt vorgegeben und je nach Bedarf abgeleitet. Oft ist eine Framework-Delegierung umfassender als die reine Bibliotheks-Delegierung und wegen Bemühungen in der Abwärtskompatibilität wesentlich einfacher zu updaten.
Bevor Du also eine Lösung neu implementierst, mache Dir erst einmal Gedanken, ob nicht jemand vor Dir das selbe Problem gelöst und implementiert hat. Bei Frameworks helfen die API-Dokumentation und Tutorials weiter, einzelne Bibliotheken und Klassen sollten so übersichtlich sein, das man u.U. gar keine Doku lesen muss.
Häufig ist die klassische DB-Anbindung bei PHP Projekten bereits eingerichtet. Was oft vergessen wird, ist die Tatsache, dass eine Datenbank mehr als nur Datensätze filtern bzw. anzeigen und einfügen kann. Eine Datenbank kann rechnen, vergleichen und validieren - und ist sogar mit der PHP-Standard-Schnittstelle synchron angebunden! Nicht umsonst gibts den Spruch:
“LET THE DB DO THE JOB!”
Jetzt wirds persönlich! Stell Dir diese Fragen, um zu sehen, ob Du vielleicht etwas verbessern kannst, was das Delegieren von Problemlösungen betrifft:
- Lässt Du die Datenbank sortieren oder machst Du das lieber mit PHP Code?
- Hast Du eine eigene Bibliothek für das Ansprechen der Datenbank implementiert, oder nutzt Du eine Standardklasse aus einem Framework oder dem PEAR?
- Nutzt Du fertige PHP Applikationen wie Wordpress als Blog oder phpMyAdmin als Datenbankoberfläche? Oder neigst Du dazu, so etwas lieber selbst zu bauen?
- Benutzt Du einen Standard-Mailer oder benutzt Du lieber jedes Mal die mail-Funktion von PHP mit Standard-Headern für Textmails?
- Setzt Du ein fertiges CMS ein (egal ob kommerziell oder nicht) oder magst Du keine Kompromisse und programmierst selbst eines?
- Schon mal ein schickes Forum selbst gebaut?
- Einen Wildcard-Zugriff aufs Dateisystem hast Du auch schon implementiert?
- Du hast Angst vor Regulären Ausdrücken?
- Ich hoffe, Du kannst was mit Design Pattern (auf Deutsch: Entwurfsmuster) anfangen!
- Aber Du benutzt bestimmt die Datenbank, um effizient zu Suchen und zu Finden, oder?
Macht delegieren immer Sinn? Naja, es ist wie immer. Man muss schon bei dem einen oder anderen Projekt Abstriche machen. Oft gibt es keine passende Lösung und eine Adaptierung wäre zu aufwendig.
Apropos Adaptierung: Statt eine Standard-Bibliothek in die Tonne zu treten, weil nicht exakt das geliefert wird, was Du suchst, macht eine Adapterklasse Sinn! Du extendest die bestehende Klasse und fügst die Funktionen hinzu, die Du noch vermisst! Dann hast Du schon mal die halbe Arbeit gespart.
Das Klasseninterface passt beim besten Willen nicht in das Schema deiner Anwendung? Dann extende wieder die bestehende Klasse und mappe auf die Ursprungsfunktionen deine eigenen. So hast Du im Hintegrund total transparent eine Thirdparty-Klasse angebunden und trotzdem Dein Lieblingsinterface!
Objektiv gesehen hat man beim Einsatz von Standardkomponenten ein geringeres Risiko, was Angriffe und Bugs angeht. Die werden (hoffentlich meist) schnell bereitgestellt und können einfach drüberkopiert werden. Die Entwickler achten bei der Bereitstellung von Bibliotheken, Frameworks und Applikationen zum Glück oft auf die Abwärtskompatibilität und ergänzen Interfaces höchstens.
Immer dran denken: Es ist ein riesiger Kraftakt, Sicherheitsupdates und Bugfixes für seine eigenen Implementierungen bereitzustellen. Zeitnah. Und nur die wenigstens machen es - die meisten implementieren und vergessen ihre Projekte sofort wieder.
