ahja das hatten wir doch schonmal....
ist ein netter spruch aber du unterschätzt die dynmaik bei grossen projekten. da gilt fast ausnahmslos wartbarkeit > perfomance. performance ist eine grösse die mann von aussen bestimmen kann, wartbareit leider nicht. und wir reden hier noch nicht mal von teamarbeit. ausserdem sollten optimierungen immer als letztes passieren weil ansonsten die gefahr besteht probleme zu lösen die am ende gar keine sind.

erm sorry aber das is nun wirklich kein argument : schlechter code bleibt schlechter code egal ob du das nun prozedural, oop oder als hybrid machst. zu dem beispiel mit der db klasse : ist doch super wenn du das doppelt so schnell hinbekommen hast, verstehe nicht ganz was das mit oop an sich zu tun hat.

gruss
Sike

Mister Ad

OOP ist kein Selbstzweck. Ich hatte die Klasse komplett auf MySQL ausgelegt und nur die Methoden implementiert, die man benötigt, wenn das Verfahren fix ist. Komplett für MySQL deshalb, weil es reine Unkenntnis der Unterschiedlichkeit von SQL Servern ist, wenn man glaubt, es reichte aus, für sein Simpel-SQL nur den Servertyp zu wechseln.

Bezüglich des ursprünglichen Themas:
da auch PHP5 mit Objekten nicht sonderlich fix hantiert, käme ich nie auf die Idee, allen Schnodder als Objekt zu deklarieren. Es sieht zwar chique aus, bringt aber absolut keinen Speed.

Beispiel:
ich hole mit der Methode getOne($sql) der DB-Klasse einen Datensatz als assoziatives Array ab und übergebe es komplett der Methode assign() der Templateklasse. Das ist eine Zeile Scripttext. Die Templateklasse pellt sich mit foreach() durchs Array und weist mit str_replace() jeder Templatevariablen den Wert zu.

Würde ich das auf Objektbasis veranstalten, müßte ich ca. 50-100 Zeilen mehr Quelltext tippern und das Script würde mit Sicherheit wesentlich langsamer agieren.

Ich setze also OOP nicht um jeden Preis ein sondern ich verwende es da und so, wie es mir Zeit und Arbeit spart.

Na klar. Den Spruch kennt jeder Angler und jeder Fisch. <ggg>
Nein, aber Du überschätzt möglicherweise den Sachverstand dessen, der das Projekt erstellt hat.

Genau das ist falsch. Ein gutes Projekt muß von vornherein auf Performanz ausgelegt werden. Dann entfällt in der Regel irgend welcher zeitaufwendiger Schnulli, der entweder unwichtig ist oder effizienter gelöst werden kann.

Falsch. Ein lahmes Script ist auch dann Mist, wenn es schnell "gewartet" werden kann.

Teamarbeit hat nur dann Zweck, wenn sie auf Modulebene stattfindet. Sonst geht das meist so ab wie mit den vielen Köchen, die den Brei verderben.

Nein, weil optimierte Algorithmen und Verfahren in der Regel Probleme von vornherein vermeiden.

Falls Du aber meiner Meinung bist, daß die Projektleiter in der Regel überbezahlte Schwätzer und keine "Seniorprogrammer" sind, dann würde ich das schon als didaktischen Erfolg verbuchen. Ich selbst verwende viel Zeit und viel Papier für die reine Projektplanung, weil ich schreibfaul bin und keine Lust habe, Scripte mehrfach umzuschreiben, um ihnen "Beine zu machen".

ich glaube wir finden da nicht zusammen. alle punkte die du aufgezählt hast sehe fast ausnahmslos genau andersrum (:

gruss
Sike

ps : http://c2.com/cgi/wiki?PrematureOptimization

Das liegt möglicherweise daran, daß ich aus leidvoller und langjähriger Erfahrung spreche. Jut, meinen Problemanalytiker hatte ich zwar schon 1969 im Anschluß an die Berufsausbildung in der DDR gemacht, aber was mir heutzutage als Projekt u/o Projektleiter über den Weg gelaufen ist, war größtenteils berufsunfähig.

naja so knapp 15 jahre erfahrung habe ich auch. scheint nur recht unterschiedlich gelaufen zu sein. (:

gruss
Sike