Vorteile OOP - konkrete Beispiele?

[Forumsgast]

Hallo,

ich arbeite schon mehr als 5 Jahre mit PHP und habe mich bislang immer erfolgreich dagegen "gewehrt" selber OOP zu schreiben ... ich kann mich halbwegs durch OOP-Anwendungen durchhangeln ... aber mehr auch nicht.

Das hängt in den meisten Fällen einfach damit zusammen, daß ich nach wie vor keinen wirklichen Nutzen darin erkennen kann. Gerade sitze ich an einem Formular, welches mit Symfony erstellt worden ist, welches ich anpassen soll.

Das Auffinden der diversen Dateien, die hier was definieren, da was konfigurieren, wieder woanders etwas validieren und durch x-Methoden schleifen ... das macht mich etwas ratlos, warum da nicht ein einfaches

<input type="text">

gereicht hätte?

Außer, daß es natürlich schön abstrahierter Code ist und wahnsinnig lange dauert, "mal eben schnell" was ändern zu wollen - wo sind die Vorteile davon?

Ich lasse mich gerne überzeugen, aber ein, zwei Stunden sich durch eine OOP-Variante zu klicken, um evtl. ein neues Formularfeld hinzuzufügen, validieren zu lassen und in eine Email mit aufzunehmen ... ginge das nicht auch einfacher?

Das Formular ist hier natürlich ein Beispiel - aber es verdeutlicht vielleicht, was ich meine.


Danke schonmal

Mark

[Forumsgast]

Mit so einfachen Beispielen kann man OOP nicht zufriedenstellend argumentieren.
OOP ist für große Anwendungen gedacht, die sich stetig weiterentwickeln und von vielen verschiedenen Leuten entwickelt, supported und benutzt werden.

Das wäre so, wie den Nutzen eines Differentialgetriebes zu erklären und als Gegenbeispiel einen Pferdekarren zu benutzen. Es geht einfach nicht "einfach".

Wenn dich das Thema wirklich interessiert, bist du am besten damit bedient, ein Buch darüber zu lesen.

Das Problem ist, dass du von einer konkreten Fragestellung ausgehst, OOP aber eine Ebene darüber aufgehängt ist. OOP ist zu aller erst eines: ein Konzept. Eine Vorgehensweise, wie man ein Programm strukturiert. Da gehts garnicht um das konkrete machen, sondern erstmal um den Schritt davor: Das darüber nachdenken.

Du redest bei OOP nicht mehr von einzelnen Dateien oder bestimmten Funktionen, vielmehr von Aufgabenbereichen, Anwendungen oder Templates. Es ist einfach ein sehr unterschiedlicher Denkansatz, den man wie gesagt nicht "mal eben so" argumentieren kann.

Denk mal so drüber nach: Du sollst Facebook entwickeln. Das ist alles PHP. Sowas kriegst du nicht mit einfachem PHP/HTML und ein bisschen JS hin. Da braucht man Konzepte, die erweiterbar sind. Und das ist nunmal nur OOP. Du kannst dein HTML/PHP-Zeug nicht einfach erweitern um neue Funktionen. Klassen schon.

PS: Zum konkreten Fall mit Symfony: Der Vorteil von Symfony ist genau der, dass du dich eben NICHT darum kümmern musst, wie das Formular später angezeigt wird. Du musst nur die Geschäftslogik anpassen. Das Design zieht es von ganz alleine nach. So gesehen hat man (wenn man sich darin auskennt) mit einer OOP-Applikation deutlich weniger Arbeit als mit einer klassischen. Dass es dir so schwer fällt ist nicht die Schuld von OOP, sondern von deinem Unwissensstand dieser Technologie gegenüber.

[Forumsgast]

In der OOP wird nicht nur in Funktionen gedacht sondern auch in Methoden und Klasse. Durch die Klassen lassen sich Funktionssammlungen realisieren. Ein Klasse kann dabei bestimmte Objekte darstellen (Beispiel: User, File, Group, usw.). Für jedes "Ding" kann man eine Klasse erstellen und über Methoden und Eigenschaften verwalten bzw. darstellen. Dieses "Ding" lässt sich nur sehr schwer ohne OOP realisieren.

Es kann dabei wie du schon bemerkt hast recht schnell unübersichtlich bzw. zu ungewohnten Code-Blöcken kommen. Doch dadurch wird die Flexibilität und Dynamik der Klassen erhalten. Für jede kleinste Aktion wird eine bestimmte Methode verwendet. In der richtigen Abfolge bilden diese einen bestimmten Ablauf.

OOP macht wie ApoY2k schon bemerkt hat nur Sinn in großen Anwendungen welche ständig erweitert werden sollen oder von mehreren Entwickelt werden. So kann jeder Entwickler eine eigene Klasse entwickeln welche später in einem dritten Script aufgerufen werden können.

Für kleine Anwendungen macht OOP natürlich wenig Sinn da der Aufwand zu groß wäre.

[Forumsgast]

OOP macht auch Sinn für einfachste Anwendungen, schon wegen der Datenkapselung. Es müssen nicht immer die Objekte vom Typ 'Eierlegende-Woll-Milch-Sau' sein. Als Beispiel fallen mir z.b. die Mailer-Klassen (PHPMailer,Swiftmailer...) ein.

[Forumsgast]

Für kleine Anwendungen macht OOP natürlich wenig Sinn da der Aufwand zu groß wäre.

Kleine Anwendung => Kleiner Aufwand ?
Große Anwendung => Größerer Aufwand ?

Der Nutzen von OOP ist von Beginn an da, unabhängig von der Größe?
Mit der Zunahme der Größe "kann" OOP (Design-abhängig) seinen Nutzen steigern?

[Forumsgast]

OOP macht nur Sinn wenn es um große Anwendungen geht. Wenn man drei Funktionen und eine Ausgabe hat wäre OOP übertrieben, es sei denn das Ganze soll noch größer werden.

Ich denke OOP macht nur Sinn wenn man wirklich mehrere Dinge (Beispiele: User, File, usw.) hat und diese ordentlich darstellen möchte. Der Sinn der OOP steckt ja schon im Begriff selbst. Objekt Orientiert Programmierung: Die Dinge User, File wären die Objekte.

[Forumsgast]

OOP macht nur Sinn wenn es um große Anwendungen geht. Wenn man drei Funktionen und eine Ausgabe hat wäre OOP übertrieben, es sei denn das Ganze soll noch größer werden.

Welches ernsthafte Projekt hat solch einen geringen und statischen Umfang oder unterliegt im gesamten Lifecycle nicht einem Change-Request oder findet in anderen Projekten keinerlei Wiederverwendung?

[Forumsgast]

das macht mich etwas ratlos, warum da nicht ein einfaches

<input type="text">

gereicht hätte?

Speziell auf diese Frage geantwortet: Mit OOP lässt sich halt ein abstrakter, wiederverwendbarer Ansatz modellieren, der später nur noch zusammenkonfiguriert werden muss, während Du from Scratch immer wieder neu die selbe Aufgabe implementierst.
In einer Anwendungsumgebung hängen halt viele Dinge zusammen: Formulare mit Templates, Formulare mit Validierung, Formulare und Validierung mit Request-Typ und -Daten, Request-Daten mit dem PageControlling usw. Templates sind ein Teil eines globalen Viewkonzepts usw. Die Stärke von OOP entsteht gerade im Zusammenspiel von einzelnen Komponenten, weil OOP eine Schnittstelle der Einzelteile modellieren und garantieren kann.

Selbst in einem plain implementierten Beispiel:

$label = array ('text' => 'Bemerkung');
if (isset ($_POST['submit'])) {
  if (empty ($_POST['text']) || strlen ($_POST['text']) < 3) {
    $message = 'invalid: ' . $label['text'];

    ?><form>
  <label for="text"><?php echo $label['text']; ?></label><input  id="text" name="text">
  <input  type="submit" name="submit" value="<?php echo htmlspecialchars ($_POST['text']); ?>">
</form><?php
  }
}
else {
?><form>
  <label for="text"><?php echo $label['text']; ?></label><input  id="text" name="text">
  <input  type="submit" name="submit">
</form><?php
}

Hast Du bereits eine Menge
+ Abhängigkeiten:
- 'text' als name-Attribut, als Requestschlüssel, als Label-Schlüssel
- id-indung des Labels an das Form-Element
+ Code-Duplizierung:
- ebenfalls 'text', im Prinzip müsste man diese "Konstante" in eine Variable auslagern. Dann hat man die Variable als Codeduplikat...
- Überhaupt den ganzen Aufbau, sobald man mehr als ein Form pro App hat
+ Boilerplate:
- if (!empty &&..)
- echo htmlspecialchars ()

Und richtig blöde wirds, wenn Du Programmlogik und Aussehen aufteilst, also bspw. das Form als Template anlegst. Dann ziehst Du nämlich die Abhängigkeiten von name-Attribut/Arrayschlüssel und Action-Type/Requesttype auseinander und Codeänderung heißt immer, an mehreren Stellen im System schrauben zu müssen.

[Forumsgast]

Ich lasse mich gerne überzeugen, aber ein, zwei Stunden sich durch eine OOP-Variante zu klicken, um evtl. ein neues Formularfeld hinzuzufügen, validieren zu lassen und in eine Email mit aufzunehmen ... ginge das nicht auch einfacher?

Das nennt sich Lernkurve. Wenn dus einmal kannst erstellst du damit ein Formular inkl. Validierung, Filterung, Fehlerhandling, CSRF Schutz und weiß der Geier was in 5 Minuten.

PS: ja es wäre einfacher gegangen. Wie sagt man so schön... RTFM!

[Forumsgast]

PS: ja es wäre einfacher gegangen. Wie sagt man so schön... RTFM!

ach, das steht im PHP-Manual ?

Gib mir doch mal den Link zur entsprechenden Seite.

So viel ich weiß wird im Manual nirgends der Vorteil der OOP erläutert.

Ach so, Du meinst das Symphony-Manual ?

Dann bist aber auch nicht einfacher und schneller am Ziel.

[Forumsgast]

ach, das steht im PHP-Manual ?

Mir wäre neu das die Symfony Forms jetzt offizieller Bestandteil von PHP sind. Ich mein damit die Dokumentation von Symfony... speziell das da: http://symfony.com/doc/current/book/forms.html
Statt 2 Stunden rumklicken wären 30 Minuten lesen wohl schneller und einfacher gewesen.

[Forumsgast]

OOP ist nicht grunsätzlich schneller, jedoch kannst du sehr viele Komponenten wiederverwenden, d.h. du hast am Anfang einen größeren Aufwand wenn du bestimmte Dinge implementieren willst wie z.B. eine komplette Formularverwaltung mit Validierung, verschiedenen Inputtypen etc. Danach gehts dann aber ziemlich flott, du bekommst dann enorm schnell Formular zustande die zum einen konsistent in deren Funktionalität sind und sehr wahrscheinlich keine Bugs enthalten (da du die Komponente ja schonmal geschrieben und hoffentlich damals getestet hast). Außerdem sparst du dir ne Menge nervige Copy&Paste arbeit.

Du musst dich da einfach mal ins Thema einarbeiten und mal was damit machen. Dann wirst du schon selbst merken wie angenehm manche Dinge zu lösen sind wenn du auf Klassen bzw. Objekte zurückgreifen kannst.

[Forumsgast]

Statt 2 Stunden rumklicken wären 30 Minuten lesen wohl schneller und einfacher gewesen.

sorry, hab erst jetzt kapiert was Du meinst.

[Forumsgast]

Ich persönlich nutze OOP auch um „Objekte“ zu separatisieren.

Zwei Beispiele, da ich das gerade nicht erklären kann:

$auto = array('marke' => 'xxx', [...]);
$auto2 = array([...]);

echo 'Auto 1 hat die Marke '. (isset($auto['marke']) ? $auto['marke'] : 'N/A') .'<br />';
 echo 'Auto 2 hat die Marke '. (isset($auto 2['marke']) ? $auto2['marke'] : 'N/A') .'<br />'; 

Und

$auto1 = new Auto('Ferrari');
$auto2 = new Auto('...');

echo $auto1->getMarke();
echo $auto2->getMarke(); 

Dabei spart man sich, „tausende“ Berechnungen im Code durchzuführen, und hat die alle intern in einer Methode in einer Klasse; dort sind auch die Variablen untergebracht und man muss sich über die Eindeutikeit der Variablennamen keine sorgen machen

Scheint noch keiner erwähnt zu haben

[hts]

... um „Objekte“ zu separatisieren.

Was ist denn das?

Dein Beispiel war jetzt auch nicht so toll:

function getMarke(array $auto)
{
  return isset($auto['marke']) ? $auto['marke'] : 'N/A';
}