Sinn und Zweck von OOP in einer Web-Anwendung

[Gast_1]

Ich verstehe nicht in welcher Form man sinnvoll OOP für eine Webanwendung verwendet.
Ich habe mir für eine private Anwendung ein System aus Include-Dateien programmiert, die je nach Anforderung der vorhergehenden Seite aufgerufen und abgearbeitet werden. Seit geraumer Zeit frage ich mich aber wie ich dieses System sinnvoll in ein Framework von Klassen umwandeln kann.

Mir fällt nichts ein!

Zwar könnte ich in meiner kleinen Anwendung ohne viel Aufwand:
* die Inculde-Dateien in Klassen umwandeln,
* sie an geeigneter Stelle (z.B. ebenfalls als Inculde) in das Programm einbinden,
* bei Bedarf ein Objekt erzeugen
* und via entsprechenden set() Methoden parametrieren.
Nun kommt aber der Haken: Das mach ich doch jetzt schon und wie ich meine sogar viel effektiver!

In meiner Anwendung habe ich:
* eine Reihe von Variablen als Schnittstelle definiert,
* weise diesen einen Wert zu
* und lade ein Software-Modul als Include in dem die geforderte Funktionalität programmiert ist.
Mein Code ist übersichtlich, da ich die Funktion der Seite ausgelagert habe und nur die Steuerung in der Hauptseite verblieben ist. Er ist wiederverwendbar, da ich häufig verwendetet Programmteile wiederum in kleine Include-Module verpackt habe. Die Wartung aller Inculdes ist leicht, da sie ebenfalls sehr kompakt und übersichtlich gehalten sind. Und ich lade diese nur bei Bedarf und müll mir nicht den Rechner-Speicher mit Klassen zu, die ich im Programmverlauf vielleicht nicht brauche.

Wo ist der Gewinn durch Klassen? Brauch ich wirklich den ganzen OOP-Overhead in einer Web-Anwendung.

Ich habe nichts gegen OOP, ich habe diese Art des Programmierens in meiner Diplomarbeit sehr zu Schätzen gelernt. Damals handelte es sich aber um eine Anwendung in der viele Funktionen in einander gegriffen haben und mir die definierten Schnittstellen von Klassen in dem verwendeten Framework das Leben deutlich erleichtert haben. Aber in einer Webanwendung die eigentlich von oben nach unten geradlinig verläuft sehe ich keinen Gewinn durch OOP.

Habe ich da was übersehen?

[Xafford]

Ja, Du hast was übersehen: OOP ist eine Option, keine Pflicht.<br />
<br />
Wenn Du meinst, deine Anwendung läuft prozedural besser, als objektorientiert, dann lasse sie prozedural

[Gast_1]

Ich programmiere so aus Hobby und nur um mal so ein paar Sachen auszuprobieren. Das OOP keine Verpflichtung ist, ist doch klar. Ich hab ja auch geschrieben, dass ich sehr wohl auch Fälle kenne in denen OOP sinnvoll ist.
Aber wie sieht denn ein Framework für eine Webseite überhaupt aus? Ich sehe keinen Nutzen für OOP in einer solchen Anwendung. Kennt da jemand eine schönen, kleines Beispiel wo OOP mal in einer Webseite angewendet wird

[Xafford]

Ich kann Dir ein schönes Beispiel nennen, bezieht sich allerdings auf PHP5, da mit 4 so nicht unbedingt möglich.
Angenommen Du stellst auf einem Shared Host ein proprietäres Framework in From von vorkompilieren PHP-Dateien zur Verfügung, daß Kunden für ihre Zwecke nutzen können (Stichwort Anwendungsserver), und Du willst nicht, daß jeder Zugriff auf fest definierte Schnittstellen der Klassen hat, aber nicht auf die komplette Funktionalität, z.B. eine bestimmte Datenbankklasse, die ganz fest definierte Werte aus der Datenbank zurück gibt um mit diesen weiter zu arbeiten. Nehmen wir ferner an, Du willst den Leuten nicht direkt Zugriff auf die Datenbank geben oder auf alle Felder der Datenbank, dann könntest Du dies in Klasen mit public, private und protected kapseln, so daß nur bestimmte Schnittstellen für die Leute verfügbar sind, die auch mehrere Änderungen der Implementierung überleben.
<br /<<br />
Ein weiteres Beispiel: Du hast mehrere verschiedene abgeleitete Klassen für eine Basisklasse, nehmen wir mal ein konkretes Beispiel:<br />
Form, definiert mit den Eigenschaften Koordinaten X, Y als Basisklasse<br />
Jetzt leitest Du mehrere Formen davon ab:<br />
Kreis mit der Eigenschaft Radius R<br />
Quadrat mit der Eigenschaft Kantenlänge a<br />
Rechteck mit den Eigenschaften Seitenlängen a, b<br />
<br ><br />
Nun willst Du für die geometrischen Formen eine Methode
Flaeche() definieren, die die Flaeche zurück gibt. jetzt kommt das Problem der Namensräume. Wenn Du dies prozedural löst und in einem Script mehrere Formen verschiedener Art handelst, dann wird es uübersichtlich, Du muß fü rjede neue Form die globale Funktion Flaeche() verändern, um eine Fallunterscheidung vorzunehmen. Dies ist weder elegant, noch zukunftssicher, zudem fehleranfällig.
Operierst Du mit Klasse, so hat jede abgeleitete Klasse ihren eigenen Namensraum und ihre eigene Methode Flaeche(), diese methode ist fest an das Objekt gebunden. Arbeitest Du im Hauptscript mit Formen, so mußt Du nicht wissen welche Form Du gerade nutzt wenn Du nur die Flaeche wissen willst, da jede Insanz über <i>Objekt</i>-&gt;Flaeche() seine Flaeche zurück liefert.<br />
Brauchst Du irgendwann in der Zukunft eine Form Elipse, so kannst Du, ohne bestehende Klassen oder Funktionen ändern zu müssen, diese implementieren.<br />
Dies klingt jetzt recht praxisfern, aber übertrage dies Beispiel nun mal auf eine Userverwaltung, in der Du mehrere Arten user hast (Guest, User, Administrator), die einiges gemeinsam haen (Username, Emailadresse, IP, etc). Dann wird das Ganze eventuell einleuchtender.<br />
<br />
Nehmen wir noch ein praktisches Einsatzgebiet für OOP: Teamwork. Wenn Du an einem größeren Projekt mit vielen Leuten zusammenarbeitest, dann wirs Du um OOP auch dankbar sein, den Du kannst deine Funktionalitäten kapseln, kannst Funktionen bereitstellen, Funktion und Implementierung trennen und mußt nur die Schnittstellen definieren und dokumentieren, zudem ist die Gefahr, daß dein Code, den eines anderen Entwicklers beeinflußt dadurch minimieren.<br />
Stell Dir nur mal vor, Du un dein anderer Entwickler definieren in einer Bibliothek zufällig die gleiche Variable, beide Bibliotheken werden innerhalb eines Scriptes genutzt. Was denkst Du wie lange man suchen muß, um diesen Fehler zu entdecken (es könnte ja auch gewolt sein, daß diese variablen identische Namen haben)?<br />
<br />
OOP ist kein Selbstzweck, es ist ein Hilfsmittel wenn dies angebracht ist. Allerdings muß ich sagen, daß die OOP-Funktionalität in PHP meiner meinung nach sehr schwach ist. Dabei meine ich weniger den Umfang der Unterstützung, als die Art. gerade in PHP4 fehlt da einiges, was wirklich sinnvoll gewesen wäre wie z.B. Destruktoren, public/private/protected, Exceptions