nicht angemeldet
Sinn und Unsinn von OOP - Verständnisfrage?!?
Hallo,
ich programmiere hobbymäßig schon einige Zeit mit PHP. Ich habe auch schon einmal ein kleines PHP-Script gegen geringe Bezahlung für einen befreundeten Gecshäftsmann geschrieben.
Allerdings programmierte ich bisher immer prozedural. Wiederverwertbare Stücke Code packte ich in Funktionen, die entweder Teil des Gesamtscripts waren oder included wurden.
Objektorientierte Programmierung habe ich (bisher) noch nicht angewandt. Das liegt daran, dass ich den Sinn nicht ganz erkenne. Denn angenommen ich habe eine Klasse bla, die mir die Funktionen foo und baz zur Verfügung stellt.
Wieso sollte ich
$a = new bla;
$a->baz($parameter...)
schreiben, statt einfach die Funktionen baz und foo mit function zu definieren?
Was ist der tiefere Sinn hinter OOP. Ich verstehe es (noch) nicht, bitte helft mir!
Liebe Grüße,
Markus
-
-
Hello,
dazu empfehle ich
http://www.oszhdl.be.schule.de/gymnasium/faecher/informatik/oop/
und ich aus http://tut.php-q.net den Abschnitt über OOP. Außerdem solltest Du Dir die OOP-Abhandlung für PHP 5 von http://www.php.net anschauen. Dann wird Dir schnell klar, was OOP leisten kann. Bis zur Version PHP 4.x kann ich noch gut darauf verzichten.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
Alohajuchee,
das ist für mich fast wie eine Glaubensfrage. Es gibt nur wenige Anwendungsfälle, wo man sagen könnte prozedurale bzw. OO-Programmierung hätten die Nase vorn. Ich glaube in den meisten Fällen ist es die Entscheidung des Entwicklers, welchen Weg er geht.
Dennoch haben beide Techniken ihre Vor- und Nachteile. Bei OOP und PHP4 denke ich da vor allem an die Namensräume. Mittels Objekten ist es möglich, einen eigenen Namensraum für eine Bibliothek zu schaffen. Das heißt $a in Objekt "foo" ist nicht gleich $a in Objekt "bar". Das geht sonst in PHP nicht (PHP kennt nur den Namensraum von Funktionen und den globalen Namensraum).
Weiterhin kann man eine Klasse innerhalb eines Skriptes mehrfach instantiieren. Wenn ich z.B. eine Klasse für HTML-Tabellen habe, kann ich in einem Skript zwei oder mehr Tabellen-Objekte mit unterschiedlichen Eigenschaften erzeugen. Der große Vorteil ist hier einfach der, dass ein Objekt immer eine Bindung zwischen den Eigenschaften (Variablen) und Methoden (Funktionen) hat. Bei der strukturierten Programmierung gibt es diese Bindung nicht.
Mein unten referenziertes RessourceKit ist auch OOP geschrieben und ich bin der Ansicht, dass dies eine gute Entscheidung war, da es sich erstaunlich gut erweitern lässt und auch sehr flexibel (und ohne Namenskonflikte) in bestehende Projekte integrierbar ist.
viele Grüße
Achim Schrepfer--
http://reskit.speedesign.de/ - PHP-Bibliothek zum automatischen Erzeugen von HTML-Tabellen, -Formularen und -Baummenüs anhand von MySQL-Tabellen
Selfcode: sh:) fo:| ch:| rl:° br:> n4:{ ie:% mo:} va:| de:< zu:| fl:( ss:) ls:& js:|-
Hallo Achim,
das ist für mich fast wie eine Glaubensfrage. Es gibt nur wenige Anwendungsfälle, wo man sagen könnte prozedurale bzw. OO-Programmierung hätten die Nase vorn. Ich glaube in den meisten Fällen ist es die Entscheidung des Entwicklers, welchen Weg er geht.
Bei kleinen Programmen mag das so sein. Ein kleines Programm schreibt sich natürlich auch viel schneller, wenn man es einfach mal so runtertippt.
OOP hat vor allem den Vorteil, dass man Daten und Algoritmen sauber kapseln und somit Komplexität verstecken kann und dass man Codeteile wieder verwenden kann, ohne sie zu kennen. Von Vererbung abgesehen, lassen sich diese Dinge natürlich auch mit prozeduralen Sprachen einfach umsetzen.Dennoch haben beide Techniken ihre Vor- und Nachteile. Bei OOP und PHP4 denke ich da vor allem an die Namensräume. Mittels Objekten ist es möglich, einen eigenen Namensraum für eine Bibliothek zu schaffen. Das heißt $a in Objekt "foo" ist nicht gleich $a in Objekt "bar". Das geht sonst in PHP nicht (PHP kennt nur den Namensraum von Funktionen und den globalen Namensraum).
Das ist eigentlich nichts was mit OOP zu tun hätte. Module kennen die Programmiersprachen schon sehr lange.
Der größte Unterschied ist wohl die unterschiedliche Denkweise. OOP ist mehr ein Programmierkonzept auch wenn es natürlich angenehm ist, wenn die Sprache die Umsetzung dieses Konzeptes einfach macht.
Grüße
Daniel
-
Hello,
Bei kleinen Programmen mag das so sein. Ein kleines Programm schreibt sich natürlich auch viel schneller, wenn man es einfach mal so runtertippt.
OOP hat vor allem den Vorteil, dass man Daten und Algoritmen sauber kapseln und somit Komplexität verstecken kann und dass man Codeteile wieder verwenden kann, ohne sie zu kennen.Das trifft aber erst auf PHP ab Version 5 zu. Die OOP unter PHP <=4.x hat nur den Vorteil des abgegrenzten Namensraumes für Funktionen. bei der PP muss man dann eben allen Funktionen einen eindeutigen Präfix geben und die Variablen der Units/Include-Dateien konsequent in je einem eigenen Array verwalten. Das ist dann die "Billigmethode".
Ich finde leider den Link auf "alles was neu ist in PHP5 OOP" nicht wieder.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Hallo Tom,
Das trifft aber erst auf PHP ab Version 5 zu. Die OOP unter PHP <=4.x hat nur den Vorteil des abgegrenzten Namensraumes für Funktionen.
Wenn das tatsächlich alles ist, kann man kaum von OOP reden ;-)
Grüße
Daniel
-
Hallo Daniel,
Das trifft aber erst auf PHP ab Version 5 zu. Die OOP unter PHP <=4.x hat nur den Vorteil des abgegrenzten Namensraumes für Funktionen.
Wenn das tatsächlich alles ist, kann man kaum von OOP reden ;-)stimmt ;-) Ich meinte der Vorteil von OOP (oder das was Zend davon übrig gelassen hat *g*) liegt bei PHP4 ganz klar in den Namensräumen. Da PHP4 ein wirklich fettes Problem mit der Kapselung von Namensräumen und Modulen hat (gibt's quasi nicht).
Bei Deinem ersten Posting verstehe ich Deinen ersten Absatz nicht so ganz. Im Prinzip bestätigt das doch, was ich sagte: Es ist FAST eine Glaubensfrage und in den MEISTEN Fällen die Entscheidung des Entwicklers, welchen Weg er geht. Dass sich wiederverwendbare Software auch mit PP umsetzen lässt, habe ich ja auch in meinem Feature-Artikel geschrieben (http://aktuell.de.selfhtml.org/artikel/programmiertechnik/wiederverwendung/index.htm).
viele Grüße
Achim Schrepfer--
http://reskit.speedesign.de/ - PHP-Bibliothek zum automatischen Erzeugen von HTML-Tabellen, -Formularen und -Baummenüs anhand von MySQL-Tabellen
Selfcode: sh:) fo:| ch:| rl:° br:> n4:{ ie:% mo:} va:| de:< zu:| fl:( ss:) ls:& js:|-
Hallo Achim,
Ich denke, dass sich diese zerlegung in logische Einheiten, wie Du es in Deinem Artikel nennst, mit der objektorientierten Denkweise einfacher erreichen lässt. Von daher sehe ich OOP nicht als Glaubensfrage sondern schon als ein der rein prozeduralen Programmierung überlegenes Konzept.
Von Vererbung abgesehen, lassen sich diese Dinge natürlich auch mit prozeduralen Sprachen einfach umsetzen.
Damit meinte ich, man braucht keine objektorientierte Sprache, um diese Dinge umzusetzen. Das geht auch mit Modulen, Zeigern und Prozduren/Funktionen denen man immer als ersten Parameter das "Objekt" übergibt.
Perl macht das ja z.b so ähnlich, nur dass das ganze etwas versteckt und um Vererbung erweitert wurde.Grüße
Daniel
-
Hello,
Damit meinte ich, man braucht keine objektorientierte Sprache, um diese Dinge umzusetzen. Das geht auch mit Modulen, Zeigern und Prozduren/Funktionen denen man immer als ersten Parameter das "Objekt" übergibt.
Perl macht das ja z.b so ähnlich, nur dass das ganze etwas versteckt und um Vererbung erweitert wurde.Im Grunde besteht die OOP aus zwei wesentlichen Teilen:
- den Eigenschaften- und Methodenstrukturen
- dem Entwicklungssystem
Man kann auch unter Assembler OO-Strukturen aufbauen. Diese "zu Fuß" zu pflegen macht aber keinen Spaß. Also baut man sich Werkzeuge für die Codeerzeugung und -verwaltung. Und schon hat man die OOP der heutigen Form. Letztlich sind die Möglichkeiten einer OOPL immer auf die in ihrer Basisschicht verankerten Möglichkeiten beschränkt. Schlechte OOPL filtern z.B. die Methoden des OS stark aus oder erfinden eigene Methoden für Dinge, die im OS schon lange verankert sind. Man sollte also darauf achten, dass eine gute OOPL immer OS-unabhängige Kernmodule und als Ergänzung die OS-abhängingen Basismodule besitzt. Und die müssen dann auch noch "polymorph" zueinander passen, also die Möglichkeiten des einen OS möglichst nachvollziehbar und so ähnlich wie möglich auch für ein anderes abbilden.
Ich suche z.B. immer noch eine Bibliothek für PHP, die mandatory Locking unter Linux (auch bei verteilten Servern) ermöglicht. Für jeden Tipp wäre ich dankbar.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
-
-
-