Objektorientierte Programmierung: Wo macht das richtig Sinn?

[Bursti]

Hallo Forum,

ich oute mich mal als Dinosaurier: Ich programmiere seit Jahren ständig PHP (und davor auch anderes), bin mit der objektorientierten Programmierung aber bisher noch nicht warm geworden. Ein paar Anläufe habe ich gemacht, weiß also zumindest grob wie's geht, aber der tiefere Sinn hat sich mir -- in Bezug auf typische PHP-Anwendungen -- noch nicht erschlossen.

Nach meinem Verständnis macht ein Objekt doch vor allem dann Sinn, wenn ich anschließend mehrere Instanzen oder Ableitungen der definierten Klasse benötige. Oder wenn ich Daten oder Methoden so kapseln will, dass Programmierer abgeleiteter Klassen sie nicht überschreiben können o.ä.

Wenn ich mir aber die Standard-Lehrbeispiele aus den Programmierbüchern ansehe, dann ist das eigentlich nirgends so richtig der Fall. Lieblingsbeispiel scheint ein Warenkorb für einen Shop zu sein. Solche Dinger habe ich für den praktischen Einsatz schon gebaut und sehe keinen wirklichen Vorteil darin, sie als Objekt anzulegen. Ein Kunde hat nun einmal nur einen Warenkorb, die Daten liegen in Sitzungsvariablen und die Funktionen tun ihre Arbeit auch ohne in ein Objekt gesteckt zu werden.

Nun sind Lehrbuchbeispiele natürlich notwendigerweise einfacher gestrickt. Mir ist klar, dass komplexe Projekte mit großen, möglicherweise verteilten Entwicklerteams die Vorteile eines objektorientierten Ansatz nutzen können.

Deshalb meine konkrete Frage an diejenigen unter euch, die objektorientiert arbeien: In welchen Fällen seht Ihr da Vorteile und in welchen ist es eigentlich wurscht?

Danke schonmal!

Bursti

[phil]

Hi Bursti.

Deshalb meine konkrete Frage an diejenigen unter euch, die objektorientiert arbeien: In welchen Fällen seht Ihr da Vorteile und in welchen ist es eigentlich wurscht?

Ich nutze es immer.

Vorteile:

• leichter zu ergänzen
• leichter zu warten
• leichter zu kapseln
• Übersichtlichkeit
• Vereinfachtes Arbeiten im Team
• Wiederverwertung von Code

Prozedual nur noch wenn ich mal kurz ein kleines Skript basteln möchte um ein paar DB-Daten von A nach B zu transportieren und der Query dafür einfach 56789 Zeilen lang wäre. Ich mach es dann schnell mit mehreren Requests, erspart ein wenig Denkarbeit und man braucht es ja nur einmal.

Nutze bitte die SuFu, es gibt 45678 Diskussionen zu diesem Thema.

Lg, phil

[Peter Nack]

Hi Phil,

na, aber bitte nicht die "substantiierte Betrachtung" der signifikanten Nachteile vergessen!

SCNR ;-p

MfG
Peter

[karsten76]

Hallo Peter,

ich habe mir den anderen Thread mal angeschaut und finde die meisten Betrachtungsweisen zu komplex. Die Beschreibung dieses Buchs vermittelt mir den Eindruck, dass hier unbedingt ein provokatives Thema gefunden werden sollte um ein Buch zu verkaufen. Den Sinn von Objektorientierung hat Herr Orlik aber nicht verstanden.

Ich denke der ursprüngliche Ansatz von OOP ist es dem Programm-Code Struktur und Organisation zu verleihen.
Was an Maschinen-Code herauskommt bestimmt der Compiler und hat mit OOP nichts zu tun.

OOP vereinfacht das Programmieren indem es der menschlichen Denkweise entgegen kommt, schliesslich leben wir in einer Welt von Objekten. OOP vereinfacht es, große Projekte mit vielen Modulen und Bibliotheken zu organisieren und ist eigentlich nur eine, meiner Meinung nach sehr effiziente, Krücke für den Softwareentwickler. Ich habe mit C, C++ programmiert und arbeite jetzt mit C#. Allein die Intellisense-Unterstützung (IDE-abhängig) in der Objektorientierung ist Gold wert. Man stelle sich vor, aus tausenden von C-Methoden des API muss die eine benötigte gefunden werden (meistens haben die auch noch unmögliche Namen). Im Gegensatz dazu werden die Methoden bei C++ und C# in Objekten und Namespaces organisiert und sind durch sinnvolle Namensgebung leicht auffindbar.

Und noch etwas anderes. C ist keine objektorientierte Sprache, kennt aber doch die Definition von Strukturen, das heißt, dass der Speicher als Objektblock zugeteilt wird, entweder auf dem Stack oder im
dynamischen Speicher. Damit wurden auch hier schon Grundlagen zur Objektorientierung gelegt.

Was neuere Bestrebungen zur sogenannten Funktionalen Programmierung angeht sehe ich nicht, dass die Objektorientierung damit aufgegeben wird. Vielmehr wird diese erweitert und bereichert für effizienten Code auf Mehrkern-Prozessoren.

MfG

[hotti]

hi,

Deshalb meine konkrete Frage an diejenigen unter euch, die objektorientiert arbeien: In welchen Fällen seht Ihr da Vorteile und in welchen ist es eigentlich wurscht?

Es macht Sinn, wenn sich das _Ergebnis_ als Objekt modellieren lässt. Und wenn, dann muss OOP auch konsequent genutzt werden. Beispiel: URL einer Webseite als Objekt. Das lässt sich gut modellieren und die Eigenschaften wie

Last-Modified
 Title
 Description
 Author
 CSS
 JS
 Language
 Charset

werden sozusagen konzentriert. Konsequent heißt: Es gibt für jede Einzelseite Eigenschaften, die zentral abgelegt sind und nicht etwa in Form von Ausnahmeregelungen, die mal hier, mal da notiert sind. Dabei ist es unerheblich, wo diese Zentraldaten stehen, das kann eine Textdatei, XML-Datei oder auch eine DB sein. Es wird sehr sinnvoll sein, für einen URL als Objekt objektabhängige Methoden zu haben, z.B. Funktionen zum

Erzeugen eines Objekts aus der Projektverwaltung heraus
 Zuweisen der Eigenschaften
 Dateitransfer
 Staging (Präsentation)

Daneben wird es sicher auch einige Objektunabhängige Funktionen geben und unterschiedliche ObjektMethoden zum Bestücken eines Objekts mit Eigenschaften. Es macht sicher Sinn, die Default-Attribute eines Objekts in den Konstruktor zu schreiben, insbesondere bei Teamarbeit sieht da jeder, was geht.

Die Kapselung infolge OOP führt zu einheitlichen Prozessen und klar abgegrenzten Schnittstellen. Die Sinnfälligkeit an Polymorphie und Vererbungsgeschichten muss im Einzelfall erwogen werden.

Shopsystem: Den Warenkorb würde ich nun gerade nicht als Objekt ansehen, denn gerade der ist schwer zu modellieren, weil die Bedürfnisse des Kunden sehr vielfältig sein können. Aber die Seite, den Shop selbst würde ich auf jeden Fall objektorientiert Programmieren. Ich hab mal einen einfachen Shop geschrieben (nicht OOP), da ging es nur um eine Produktklasse, und siehste: Da haben wir schonmal die Klasse(n) ;-)

Wann OOP keinen Sinn macht: Wenn die Programmiersprache als Objekt betrachtet wird und nicht das was dabei herauskommen soll.

Hotti