Weblog - kronn.de

Objektorientierung im Webbereich

Jeder Entwickler kennt das Problem: Eigentlich möchte man anfangen, erste Ergebnisse sehen und Erfolg haben (Anm.: stark verkürzte Darstellung). Aber so läuft die Welt selten. Jedes größere Projekt erfordert Planung.

Den Umfang, den die Vorabplanung einnimmt, kann man schlecht vorhersagen. Ich konnte mir bisher nur sicher sein, dass so oder so zu wenig vorab geklärt wird. Größtenteils dürfte es an der Unerfahrenheit der Beteiligten liegen.

Jede Veränderung nach der Vorplanung resultiert in zigtausend kleinen Patches, die erstmal das Problem lösen aber dadurch das nächste Problem sind. Meine Antwort auf dieses Problem, dass Projekte komischerweise während der Enwicklung weiterwachsen, war bisher, regelmäßig Pausen für die komplette Neuformulierung und Neustrukturierung des Codes einzuplanen.

Dieser Ansatz ist natürlich anstrengend und in höchstem Maße ineffizient.
Also anders. Besser.

h3. geplante Programmierung

Ich gebe zu, dass ich bis vor kurzem noch nicht mit dem Konzept der Objektorientierung im Webbereich klar kam. OOP schien die Lösung für 80% meiner Probleme zu sein, aber ich konnte mir das Konzept nur im Desktopbereich sinnvoll vorstellen. Dass es anders möglich ist, beweist die Realität, in der es WebApps gibt, die objektorientiert funktionieren.

(Wem OOP nichts sagt, sei an die Wikipedia verwiesen: „Objektorientiere Programmierung“:http://de.wikipedia.org/wiki/Objektorientierte_Programmierung)

Kern der Objektorientierung ist aus meiner Sicht, dass ich eine Klasse von Objekten einmal definiere, mit Variablen (genannt Eigenschaften) versehe und die entsprechen Funktionalitäten als Methoden einbaue (wenn wir Vererbung hier erstmal außen vor lassen). Alle neue Objekte sind dann nur Instanzen dieser Klasse. Der Geschwindigkeitsvorteil, der daraus entsteht, dass eine bereits definierte Klasse mehrfach aufzurufen ist, ist in Skriptsprachen besonders wichtig.
In Desktopprogrammen ist es auch garnicht so schwer, da alle Daten bereits beim Programmstart in die entsprechenden Objekte gegossen werden können. Da erstelle ich einfach so viele Objekte wie nötig. Da die zugrundeliegenden Klassen bereits im Speicher vorliegen geht es recht schnell. Es entsteht so gut wie kein Overhead, nur der Datenzugriff kostet ein wenig Zeit.

In einer PHP-Umgebung lade ich allerdings niemals alle Daten bei einem Seitenbesuch. Das wäre Wahnsinn, da PHP-Skripte bei *jedem Seitenaufruf* komplett neu durchlaufen werden. Caching ist ja, da Zend Technologies das kommerziell vertreibt, erstmal nicht vorhanden (Anm.: Das ist „nicht die ganze Wahrheit“:http://www.php.net/manual/en/ref.apc.php). Sessions, die beispielsweise Variablen halten können, weichen dies ein wenig auf, verändern am Prinzip der Einmaligkeit der Ausgaben aber nichts.

Trotzdem bietet OOP auch für den Webbereich etwas. Auf den ersten Blick sind PHP-Klassen nämlich einfache und übersichtliche Funktionssammlungen und alleine dadurch schon sehr praktisch. Die daraus resultierende Wiederverwendbarkeit zeigt sich zwar erst mit der Menge der Projekte, aber das wird jeder selbst erfahren. Mein Tipp: *Versucht Abläufe so abstrakt und parametisierbar wie möglich zu coden*. (Da das für jeden Programmierer selbstverständlich sein sollte, ist das mehr ein Erinnerungszettel für mich.)

Vererbung, eine weitere wesentlichen Eigenheit von Klassen, ist da schon ein wenig mächtiger. Ich weiß, ein paar Absätze weiter oben wollte ich das noch nicht beachten. Aber wie das so ist… Für PHP-Hacker lautet das Stichwort „extends“:http://www.php.net/extends. Unterteilt man die Methoden (Funktionen) einer Klasse intelligent oder wenigstens pragmatisch auf mehrere Klassen, die hierarchisch voneinander abhängig sind, sind Erweiterungen auf verschiedenen Ebenen der Verzweigung einfach möglich. Das vereinfacht dann wiederum die Wiederverwendbarkeit und hilft, die Programmabläufe weiter zu abstrahieren.

Zu theoretisch? Naja, dann eben…

h3. praktisch formuliert

Wenn man beispielsweise ein CMS schreibt, dass an verschiedenen Stellen Templatetags verwendet, könnte man einerseits diese Templatetags als Methoden zu der entsprechenden Klasse hinzufügen und weiterhin die gemeinsamen, allgemeineren Methoden in eine extra Klasse schreiben, die dann

* zentral dokumentiert wird,
* zentral erweitert werden kann,
* zentral als Datei gespeichert wird.

Diese zentral definierten (und natürlich sauber dokumentierten) Methoden stehen dann allen daraus abgeleiteten Klassen zur Verfügung. OOP kann also, durch Vererbung, zu folgenden Effekten führen:

* konsistente Dokumentation
* einfache Erweiterungen
* Speicherplatz wird effizient genutzt

Dass man außerdem Fehler (z.B. Ausgabefehler, die aus Templatetags resultieren) theoretisch nur noch an einer Stelle ausbessern muss, ist ein kleiner, aber wesentlicher Punkt. Schön ist auch, dass man die gleichen Templatetags, wenn wir das Beispiel weiterführen wollen, in einem anderen Projekt leicht weiterverwenden können. Vielleicht benötigen wird dafür auch die gleiche Datenzugriffsklasse und ggf. weitere vorhergehende Klassen, aber grundsätzlich ist die Klasse weiterverwendbar. Inklusive der Dokumentation und Fehlerbehandlung.

Abgelegt in: Code
Veröffentlicht am 04.09.2005 um 20:59
Dauerhafter Link zu "Objektorientierung im Webbereich"

  • bernie

    1 oder 2 Worte zum Fehlerbehandlungskonzept ?

  • Erwartest du noch ein paar Worte zur Fehlerbehandlung von mir oder möchtest du welche loswerden, _bernie_?

    Ich meinte die klasseninterne Fehlerbehandlung, also der Umgang mit falschen oder fehlerhaften Dateneingaben.

    Wenn du etwas hinzufügen möchtest, leg einfach los.

  • bernie

    On Error goto Hell

  • Klasse Artikel gefällt mir wirklich gut. Werde deinen Blog mal im Auge behalten. Wünsche einen guten und vor allem gesunden Rutsch ins neue Jahr 2006

Diese Internetseite wurde von Wordpress zusammenebastelt und besteht aus geprüftem XHTML und CSS.
Das hat viele Vorteile.

Weitere Seiten mit ähnlichen Vorteilen preisen gutes Webdesign an oder enthalten Texte.
So ist das Leben eben.
© Kronn/2003-2005

Mein Server hat, nebenbei gesagt, 0,292 Sekunden benötigt, das hier zu fabrizieren.
War aber nicht böse gemeint.


Fatal error: Uncaught Error: Call to undefined function set_magic_quotes_runtime() in /var/www/K1054131198/docroot/kronn.de/etc/counter/counter.php:61 Stack trace: #0 /var/www/K1054131198/docroot/kronn.de/weblog/wp-content/themes/kronn/footer.php(19): include() #1 /var/www/K1054131198/docroot/kronn.de/weblog/wp-includes/template.php(688): require_once('/var/www/K10541...') #2 /var/www/K1054131198/docroot/kronn.de/weblog/wp-includes/template.php(647): load_template('/var/www/K10541...', true) #3 /var/www/K1054131198/docroot/kronn.de/weblog/wp-includes/general-template.php(76): locate_template(Array, true) #4 /var/www/K1054131198/docroot/kronn.de/weblog/wp-content/themes/kronn/single.php(31): get_footer() #5 /var/www/K1054131198/docroot/kronn.de/weblog/wp-includes/template-loader.php(74): include('/var/www/K10541...') #6 /var/www/K1054131198/docroot/kronn.de/weblog/wp-blog-header.php(19): require_once('/var/www/K10541...') #7 /var/www/K1054131198/docroot/kronn.de/weblog/index.php(17): require('/var/www/K10541...') #8 {main} in /var/www/K1054131198/docroot/kronn.de/etc/counter/counter.php on line 61