Hallo Lug-DDler!
Leider konnte ich zu dem Vortrag von Thomas nicht erscheinen. Dafür habe ich mir das Material im Netz angeschaut.
Und es ergab sich für mich nun die Frage ob sich denn der Vergleich LAMP <-> Zope ungefähr so ist wie Pascal <-> Delphi.
Vor allem was das Objektorientierte angeht.
Ich habe zwar mal gelernt objektorientiert zu programmiern, aber irgendwie nervt der ganze Overhead, der dabei entsteht. Konstruktoren, Destruktoren, Pseudo-Klassen, etc.pp. Außerdem muß ich mir mehr Gedanken machen, wie mein Gebilde letztendlich mal aussehen soll. Nicht, das ich mir sonst keine Gedanken mache, aber ich kann mit "normaler" Programmierung einfach drauf loshacken und habe relativ schnell ein Ergebnis, welches ich dann Schritt für Schritt erweitern kann, je nachdem wie mir die Ideen kommen.
Nun habe ich demnächst ein paar größere Sachen vor (eine Kombination aus Bilddatenbank, Webarchiv, Artikelarchiv, Linksammlung und Dokumentsammlung) und stehe vor der Überlegung die Sache in LAMP zu machen (alles schön einzeln, das man auch Zwischenergebnisse sieht) oder mich in Zope einzuarbeiten.
Nachdem, was ich in Thomas Vortragsunterlagen gesehen habe, scheinen mir beide Lösungen geeignet, nur das mir das objektorientierte nicht so liegt. Das ich damit nicht der einzige bin, sondern auch prominentere Leute (ct 5/02 S.192) sowas sagen, hat mich etwas beruhigt. Sonst bekommt man immer irgendwie den Eindruck vermittelt, das "Objektorientiert" etwas besseres wäre.
Wie seht ihr das? Wo liegen die Vorteile der objektorientierten Programmierung, gerade auch bei Web-Anwendungen?
Bert
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday 03 March 2002 12:01, Bert Lange wrote:
Leider konnte ich zu dem Vortrag von Thomas nicht erscheinen. Dafür habe ich mir das Material im Netz angeschaut.
Und es ergab sich für mich nun die Frage ob sich denn der Vergleich LAMP <-> Zope ungefähr so ist wie Pascal <-> Delphi.
Vorsicht: ich kenne Zope nicht, also beziehen sich meine Kommentare auf das Allgemeine weiter unten.
Vor allem was das Objektorientierte angeht.
Ich habe zwar mal gelernt objektorientiert zu programmiern, aber irgendwie nervt der ganze Overhead, der dabei entsteht. Konstruktoren, Destruktoren, Pseudo-Klassen, etc.pp.
Wenn es nervt, bist Du entweder einer der wenigen, die sehr komplexe Strukturen im Kopf behalten kann (wenn auch noch ohne Kopfschmerzen zu bekommen wuerde ich gerne den Trick von Dir lernen) oder Du hast es noch nicht richtig gelernt.
Außerdem muß ich mir mehr Gedanken machen, wie mein Gebilde letztendlich mal aussehen soll. Nicht, das ich mir sonst keine Gedanken mache, aber ich kann mit "normaler" Programmierung einfach drauf loshacken und habe relativ schnell ein Ergebnis, welches ich dann Schritt für Schritt erweitern kann, je nachdem wie mir die Ideen kommen.
Wow! Dieses Prinzip funktioniert nur bis ungefaehr 5000Zeilen (in C, 1000 in Tcl, 300 in Bash, 1500 in PHP).
Auch bei modularen oder gar linearen Programmen sollte man etwas Design machen, bevor man "loshackt". Das lernt man uebrigens, wenn man seine ersten drei Projekte, in der Region 10000-Codezeilen aufwaerts, gegen die Wand gefahren hat (nach Moeglichkeit zwei davon mehrfach reprogrammiert).
Nun habe ich demnächst ein paar größere Sachen vor (eine Kombination aus Bilddatenbank, Webarchiv, Artikelarchiv, Linksammlung und Dokumentsammlung) und stehe vor der Überlegung die Sache in LAMP zu machen (alles schön einzeln, das man auch Zwischenergebnisse sieht) oder mich in Zope einzuarbeiten.
Soweit ich weiss wurde Zope doch speziell dafuer entworfen. Da wuerden also schon einige Mannjahre Arbeit und Hirnschmalz reingesteckt. Das sollte man doch nutzen!
Nachdem, was ich in Thomas Vortragsunterlagen gesehen habe, scheinen mir beide Lösungen geeignet, nur das mir das objektorientierte nicht so liegt. Das ich damit nicht der einzige bin, sondern auch prominentere Leute (ct 5/02 S.192) sowas sagen, hat mich etwas beruhigt. Sonst bekommt man immer irgendwie den Eindruck vermittelt, das "Objektorientiert" etwas besseres wäre.
Ich nehme an, Du meinst dieses Zitat von D.E.Knuth: "Die Idee hat mir sofort gefallen, [....] Ich mag die Idee von Modulen und Klassen, aber irgendwie gefaellt sie mir doch nicht so sehr, dass ich sie in meinen eigenen Programmen fuer noetig halten wuerde."
Knuth hat die Ausrede 64 zu sein. Welche hast Du? ;-)
Im Ernst: OOP ist eine Programmiertechnik, die ihre Vor- und Nachteile hat: +steigert die Uebersichtlichkeit +besser wart-/aenderbar +besser erweiterbar +Code kann (nahezu unveraendert) von einem Projekt zum naechsten transportiert werden (im Fachjargon: Wiederverwendbarkeit) +der Code kann meistens Klassenweise getestet werden - -sehr lange Designphase noetig (allerdings gibt es keinen Bruch zwischen Design und Implementation, ob viel Design negativ ist wagen auch viele zu bezweifeln...) - -der Code ist meist langsamer als vergleichbarer linearer Code (Je nach Anwendung teilweise bis Faktor 2 oder 3)
Kurzgefasst: OOP unterstuetzt die Programmierung von besser wartbarem und uebersichtlicherem Code, wird dabei jedoch langsamer als gut optimierter linearer Code. Egal welches Paradigma Du anwendest: sich selbst in den Fuss schiessen und dabei noch den ganzen Code verhunzen geht immer.
Wie seht ihr das? Wo liegen die Vorteile der objektorientierten Programmierung, gerade auch bei Web-Anwendungen?
Wie auch bei anderen Applikationen: in der Kapselung. Web-Anwendungen neigen dazu sich sehr schnell aendern zu muessen. Neue Seiten kommen hinzu, andere verschwinden, das Layout wird andauernd geaendert, der Inhalt aendert sich und damit auch die Anforderungen.
Programmierst Du das linear (Perl, PHP, Python ohne OOP und Zope, etc.pp) dann musst Du bei jeder neuen Seite das Ganze Teil neu aufsetzen, inklusive Authentifikation, Session-Tracking, etc.pp. Bei Layout-aenderungen gehst Du alle Seiten durch und guckst wo was geaendert werden muss. Das wird schnell sehr aufwaendig, wenn die Datenstrukturen wachsen und der Code kompliziert wird.
OOP (PHP mit Objekten, Zope, etc.) macht sich am Anfang natuerlich wesentlich aufwaendiger, dafuer wird es dann aber immer schneller und leichter (jedenfalls wenn man schon etwas geuebt ist im OO-Design, am Anfang gibt es immernoch ein paar Schluckaufs, wenn man sein Design ueberarbeiten muss). Wird eine Seite hinzugefuegt sieht der Code (PHP) bei mir meist so aus: - ----- <? include 'inc/loadallobjects.php' //check parameters //... $page=new Page($HTTP_VARS["page"]);
if(!$page->hasaccess($user,"admin")){ header("Location: home.php"); exit; } ?> <html> <title>Admin <? print($page->getname()) ?></title> <body> <h1>Admin <? print($page->getname()) ?></h1>
<form action="pageadmdo.php" method="POST"> <.....> <input type="text" name="pname" value=<? print("\"".page->getname()."\"") ?>>
<input type="submit"> </form>
</html> - -----
Der ganze Code, der ueberall gleich ist versteckt sich in loadallobjects.php, dort wird die User-authentifikation gemacht und gleich ein $user- und ein $session-Objekt gefuellt, die Datenbank wird geoeffnet und wichtige Daten gelesen, und so weiter.
$page=new Page(...) erzeugt ein Seitenobjekt, das so nebenbei alle wichtigen Daten zusammenholt, checkt wie die Zugriffsrechte aussehen, und solche Sachen, wie Renderingfunktionen ($irgendeinformat zu HTML) fuer verschiedene Teile des Inhalts oder Pruefroutinen fuer verschiedene Szenarien (z.B. Zugriffsrechte: hasaccess(...)) enthaelt.
Will ich nun die Authentifizierung aendern, dann aendere ich nur die Klassen User und Group (alle anderen fragen ja User oder Group). Will ich auf eine andere Datenbank umsteigen (z.B. PostgreSQL), dann aendere ich DB. Will ich das Layout von Seitenueberschriften aendern, dann kommt Page dran.
Ausserdem hat es den Vorteil, dass man immer wieder die selben Klassen fuer die selben Standardaufgaben benutzen kann. Man muss den Code nicht erst umstaendlich aus linearen Files heraus-sezieren. (Ich benutze z.B. immer die selbe Authentifikationsklasse.)
Konrad
- -- "I can give you one advice. If you see a Neo: do the same as we do - run!" -- Agent Jones
Hi Konrad!
Danke für Deine umfangreiche Antwort, werden mal sehen:
On Sun, Mar 03, 2002 at 03:19:30PM +0100, Konrad Rosenbaum wrote:
Und es ergab sich für mich nun die Frage ob sich denn der Vergleich LAMP <-> Zope ungefähr so ist wie Pascal <-> Delphi.
Vorsicht: ich kenne Zope nicht, also beziehen sich meine Kommentare auf das Allgemeine weiter unten.
Hmm, na ich auch noch nicht ;-)
Ich habe zwar mal gelernt objektorientiert zu programmiern, aber irgendwie nervt der ganze Overhead, der dabei entsteht. Konstruktoren, Destruktoren, Pseudo-Klassen, etc.pp.
Wenn es nervt, bist Du entweder einer der wenigen, die sehr komplexe Strukturen im Kopf behalten kann (wenn auch noch ohne Kopfschmerzen zu bekommen wuerde ich gerne den Trick von Dir lernen) oder Du hast es noch nicht richtig gelernt.
Naja, ich denke gelernt schon, aber wenig angewendet. Trick -> siehe nächster Absatz.
Außerdem muß ich mir mehr Gedanken machen, wie mein Gebilde letztendlich mal aussehen soll. Nicht, das ich mir sonst keine Gedanken mache, aber ich kann mit "normaler" Programmierung einfach drauf loshacken und habe relativ schnell ein Ergebnis, welches ich dann Schritt für Schritt erweitern kann, je nachdem wie mir die Ideen kommen.
Wow! Dieses Prinzip funktioniert nur bis ungefaehr 5000 Zeilen (in C, 1000 in Tcl, 300 in Bash, 1500 in PHP).
Hab gerade mal nachgeschaut: Java 400 C 600 Pascal 1000 PHP 1000 Und da liegt nämlich der Trick. Meine Projekte sind einfach nicht größer. Und Deine Zeilenzahlen nehme ich Dir glatt ab, da brauch ich mich nicht wundern, das mir OOP etwas überflüssig vorkommt.
Auch bei modularen oder gar linearen Programmen sollte man etwas Design machen, bevor man "loshackt". Das lernt man uebrigens, wenn man seine ersten drei Projekte, in der Region 10000-Codezeilen aufwaerts, gegen die Wand gefahren hat (nach Moeglichkeit zwei davon mehrfach reprogrammiert).
Siehe oben. Aber in diesen Regionen würde ich vorneweg auch ein paar Schnittstellen definieren, damit auch mehrere dran arbeiten können.
Nun habe ich demnächst ein paar größere Sachen vor (eine Kombination aus Bilddatenbank, Webarchiv, Artikelarchiv, Linksammlung und Dokumentsammlung) und ...
Soweit ich weiss wurde Zope doch speziell dafuer entworfen. Da wuerden also schon einige Mannjahre Arbeit und Hirnschmalz reingesteckt. Das sollte man doch nutzen!
Naja, aber PHP/MySQL ist ja auch für sowas gedacht, oder eher doch nicht?
Ich nehme an, Du meinst dieses Zitat von D.E.Knuth: "Die Idee hat mir sofort gefallen, [....] Ich mag die Idee von Modulen und Klassen, aber irgendwie gefaellt sie mir doch nicht so sehr, dass ich sie in meinen eigenen Programmen fuer noetig halten wuerde."
Knuth hat die Ausrede 64 zu sein. Welche hast Du? ;-)
Das ich noch keine 64 bin? ;-) Aber OOP gibt es ja auch nicht erst seit gestern...
Im Ernst: OOP ist eine Programmiertechnik, die ihre Vor- und Nachteile hat: +steigert die Uebersichtlichkeit
Jein. Ich durfte mal ein Stück Java debuggen, da bestand eine Funktion aus 300 Zeilen, in denen die Datenbank ordentlich durcheinander gebracht wurde...
+besser wart-/aenderbar +besser erweiterbar
Jein.
+Code kann (nahezu unveraendert) von einem Projekt zum naechsten transportiert werden (im Fachjargon: Wiederverwendbarkeit)
Hmm. Wie oft braucht man das? Und wie oft wird es wirklich angewendet? Ich schaue dann kurz in dem alten Projekt nach und suche mir die 5 oder lass es 10 Codezeilen raus, die ich brauche und baue mir 'ne neue Funktion oder so draus. Das alte Projekt, wird deswegen trotzdem nicht mehr verändert.
+der Code kann meistens Klassenweise getestet werden
Ja.
- -sehr lange Designphase noetig (allerdings gibt es keinen Bruch zwischen
Design und Implementation, ob viel Design negativ ist wagen auch viele zu bezweifeln...)
Genau, das meinte ich mit "ich muß mir so ziemlich alles vorneweg überlegen".
- -der Code ist meist langsamer als vergleichbarer linearer Code (Je nach
Anwendung teilweise bis Faktor 2 oder 3)
Geschwindigkeit spielt inzwischen eher eine untergeordnete Rolle bei mir. Meines Erachtens führen schnellere Prozessoren hauptsächlich dazu, das bloat entsteht...
Kurzgefasst: OOP unterstuetzt die Programmierung von besser wartbarem und uebersichtlicherem Code, wird dabei jedoch langsamer als gut optimierter linearer Code. Egal welches Paradigma Du anwendest: sich selbst in den Fuss schiessen und dabei noch den ganzen Code verhunzen geht immer.
Schön gesagt...;-)
Programmierst Du das linear (Perl, PHP, Python ohne OOP und Zope, etc.pp) dann musst Du bei jeder neuen Seite das Ganze Teil neu aufsetzen, inklusive Authentifikation, Session-Tracking, etc.pp. Bei Layout-aenderungen gehst Du alle Seiten durch und guckst wo was geaendert werden muss. Das wird schnell sehr aufwaendig, wenn die Datenstrukturen wachsen und der Code kompliziert wird.
Nein, muß ich nicht. Spätestens wenn ich merke, das ich irgendeine Funktionalität zum dritten Mal in einem Projekt programmiere, wird das Ding in eine Funktion ausgelagert. Egal ob Layout, Auth, DB-Init. Aber solange wie sich z.B. das Layout nicht ständig wiederholt, kann ich es so lassen wie es ist.
Wird eine Seite hinzugefuegt sieht der Code (PHP) bei mir meist so aus:
[Code snipp] [Erklärung snipp]
Das kann ich auch alles ohne OOP machen...
Ausserdem hat es den Vorteil, dass man immer wieder die selben Klassen fuer die selben Standardaufgaben benutzen kann. Man muss den Code nicht erst umstaendlich aus linearen Files heraus-sezieren. (Ich benutze z.B. immer die selbe Authentifikationsklasse.)
Siehe oben. Das mache ich einmal und dann habe ich auch eine Funktion die wiederverwertbar ist.
Trotzdem nochmal vielen Dank für Deine ausführlichen Erläuterungen. Ich glaube der Punkt mit der Zeilenzahl ist entscheidend (zumindest solange, wie man alleine hackt).
Bert
Once upon a time, I heard Bert Lange say:
Trotzdem nochmal vielen Dank für Deine ausführlichen Erläuterungen. Ich glaube der Punkt mit der Zeilenzahl ist entscheidend (zumindest solange, wie man alleine hackt).
Grundsätzlich kannst Du natürlich tun und lassen, was Du willst und dennoch, wenn Du fragst, empfehle ich Dir, ein bißchen in der Online- Doku von Zope rumzuschnüffeln. Wenn Du Dich schon für PHP/MySQL entschieden hast, ist das natürlich hirnrissig.
hej så länge.
On Sun, Mar 03, 2002 at 08:18:45PM +0100, Bert Lange wrote:
Im Ernst: OOP ist eine Programmiertechnik, die ihre Vor- und Nachteile hat: +steigert die Uebersichtlichkeit
Jein. Ich durfte mal ein Stück Java debuggen, da bestand eine Funktion aus 300 Zeilen, in denen die Datenbank ordentlich durcheinander gebracht wurde...
In den meisten Coding-Style Dokumenten kann man lesen, daß daß man irgendwas falsch macht, wenn eine Funktion/Methode über mehr als 2-3 Bildschirmseiten (a 25 Zeilen) geht. Siehe auch:
Egal welches Paradigma Du anwendest: sich selbst in den Fuss schiessen und dabei noch den ganzen Code verhunzen geht immer.
Programmierst Du das linear (Perl, PHP, Python ohne OOP und Zope, etc.pp) dann musst Du bei jeder neuen Seite das Ganze Teil neu aufsetzen, inklusive Authentifikation, Session-Tracking, etc.pp. Bei Layout-aenderungen gehst Du alle Seiten durch und guckst wo was geaendert werden muss. Das wird schnell sehr aufwaendig, wenn die Datenstrukturen wachsen und der Code kompliziert wird.
Nein, muß ich nicht. Spätestens wenn ich merke, das ich irgendeine Funktionalität zum dritten Mal in einem Projekt programmiere, wird das Ding in eine Funktion ausgelagert. Egal ob Layout, Auth, DB-Init. Aber solange wie sich z.B. das Layout nicht ständig wiederholt, kann ich es so lassen wie es ist.
Bei OO geht es weniger um die Kapselung/Modularisierung von Funktionen, als vielmehr um die Daten. Wenn Du in C eine Struktur benutzt, nimmst Du in C++ eine Klasse. Die macht das gleiche wie die Struktur + Du kannst die spezifischen Funktionen gleich mit reinpacken.
Eric
On Sun, Mar 03, 2002 at 12:01:17PM +0100, Bert Lange wrote:
Hallo Lug-DDler!
Leider konnte ich zu dem Vortrag von Thomas nicht erscheinen. Dafür habe ich mir das Material im Netz angeschaut.
Und es ergab sich für mich nun die Frage ob sich denn der Vergleich LAMP <-> Zope ungefähr so ist wie Pascal <-> Delphi.
Vor allem was das Objektorientierte angeht.
Ich habe zwar mal gelernt objektorientiert zu programmiern, aber irgendwie nervt der ganze Overhead, der dabei entsteht. Konstruktoren, Destruktoren, Pseudo-Klassen, etc.pp.
Du darst OOP nich mit C++ verwechseln. C++ macht mir auch keinen Spaß
Außerdem muß ich mir mehr Gedanken machen, wie mein Gebilde letztendlich mal aussehen soll. Nicht, das ich mir sonst keine Gedanken mache, aber ich kann mit "normaler" Programmierung einfach drauf loshacken und habe relativ schnell ein Ergebnis, welches ich dann Schritt für Schritt erweitern kann, je nachdem wie mir die Ideen kommen.
Die große Frage ist, ob du deine Daten in eine relationale oder in eine objektorientierte Datenbank stecken willst. Deinen Worten zufolge eher in eine relationale. Dann ist es eigentlich eher eine Frage der Syntax.
Die nächste Frage ist der Server. Die meisten Provider bieten PHP an.
Wie seht ihr das? Wo liegen die Vorteile der objektorientierten Programmierung, gerade auch bei Web-Anwendungen?
Das Problem ist die Datenbank. Wenn du eine relationale Datenbank verwendest, brauchst du für die objektorientierte Programmierung ein OR-Mapping. Das ist Fehleranfällig, so dass ich eher zu Scripten raten würde.
Die Scripte kannst du in ZPT, DTML (siehe Vortrag) oder PHP schreiben.
thomas
Hi Thomas!
On Mon, Mar 04, 2002 at 07:17:09PM +0100, Thomas Guettler wrote:
On Sun, Mar 03, 2002 at 12:01:17PM +0100, Bert Lange wrote:
Ich habe zwar mal gelernt objektorientiert zu programmiern, aber irgendwie nervt der ganze Overhead, der dabei entsteht. Konstruktoren, Destruktoren, Pseudo-Klassen, etc.pp.
Du darst OOP nich mit C++ verwechseln. C++ macht mir auch keinen Spaß
Das ist klar. Aber auch bei Java und TurboPascal gibt es diese IMO "überflüssige" Tipparbeit.
Die große Frage ist, ob du deine Daten in eine relationale oder in eine objektorientierte Datenbank stecken willst. Deinen Worten zufolge eher in eine relationale. Dann ist es eigentlich eher eine Frage der Syntax.
Bisher habe ich noch nie mit einer OO-Datenbank gearbeitet. Von daher ist mir auch das Konzept dieser Datenbanken noch nicht geläufig.
Die nächste Frage ist der Server. Die meisten Provider bieten PHP an.
Spielt bei mir keine Rolle, da alles nur in meinem "Intranet" laufen soll.
Das Problem ist die Datenbank. Wenn du eine relationale Datenbank verwendest, brauchst du für die objektorientierte Programmierung ein OR-Mapping. Das ist Fehleranfällig, so dass ich eher zu Scripten raten würde.
Das Problem hatte ich bisher nur im Hinterkopf und noch nicht so richtig formuliert. Mit dem Mapping hast Du recht. Ich habe mir immer überlegt, warum ich in OO machen soll, wenn meine Daten doch nur in relationalen Datenbanken liegen (und dort dann noch über mehrere Tabellen verteilt).
Ich habe gestern mal das Tutorial von Zope durchgearbeitet (nachdem es sich irgendwann doch überreden ließ sich zu installieren). Und ich muß sagen, was ich gesehen habe hat mir schon ganz gut gefallen. Zumal mir immer noch die Möglichkeit bleibt einzelne Projektteile mittels PHP zu realisieren und das ganze miteinander zu verzahnen. (Jetzt will ich noch Zope überreden auf Port 81 zu laufen.)
Danke auch für Deine Antwort! Bei Problemen mit DTML werd ich mich sicher auch mal an Dich wenden.
Apropos DTML: So richtig schön finde ich es noch nicht, das liegt aber daran, das mcedit die PHP-Skripte mit Syntaxhighlighting versieht und der Browser noch nicht.
Bert
Danke auch für Deine Antwort! Bei Problemen mit DTML werd ich mich sicher auch mal an Dich wenden.
Du bekommst schneller eine Antwort wenn du an eine Liste schreibst.
Apropos DTML: So richtig schön finde ich es noch nicht, das liegt aber daran, das mcedit die PHP-Skripte mit Syntaxhighlighting versieht und der Browser noch nicht.
DTML gefällt mir auch nicht ZPT ist besser.
Viel Spaß beim lernen und entdecken, thomas
lug-dd@mailman.schlittermann.de
-
Bert Lange -
Eric Schaefer -
konrad.rosenbaum＠t-online.de -
Stefan Berthold -
Thomas Guettler