OOP: Aufteilung der Aufgaben innerhalb einer Anwendung

[Blaubart]

Tach.

Du bist also der Meinung, dass OoP im Interpreterumfeld (nicht kompilierend) also _keinen_ Overhead darstellt?

Nein, bin ich nicht. Ich bitte Dich lediglich darum, Dein schwammiges "das dauert dann..." z. B. mit Beipielen oder Meßdaten aus der Praxis zu quantifizieren. Entweder ist der Overhead durch OOP in Produktivsystemen relevant (dann wäre Dein Einwand gerechtfertigt und hilfreich) im Vergleich zum Rest oder nicht. Du implizierst durch Deine Aussage ersteres.

Wenn man nun die Klassendefinitonen erst noch durch den Interpreter jagen muss, kostet das nochmals Rechenzeit.

Du bekommst keine zusätzliche Funktionalität zum Nulltarif. Nicht bei PHP und auch sonst nicht. Das ist auch überhaupt nicht der Punkt. Die Frage ist, in welchem Verhältnis der zusätzliche Aufwand zum bisherigen Aufwand und zum Nutzen steht. Und auch die absoluten Zahlen sind interessant: Wenn bspw. die Verabeitung eines Datensatzes mit Methode A 5 ms dauert und mit Methode B dreimal so lange, die anschließende Übertragung des Ergebnisses aber mit 100 ms zu Buche schlägt und der Benutzer obendrein erst ab Wartezeiten über 500 ms ungeduldig wird, ist der Overhead einfach irrelevant und auch tragbar, wenn aus Methode B bspw. ein verständlicheres, besser wartbares und erweiterbares Programm resultiert.

Die OoP war schon zu Assemblerzeiten …

(Überrascht mich nicht, daß das jetzt wieder kommt.)

… benutzbar und hat dem Programmierer (teilweise) die Arbeit erleichtert. Aber man erkannte damals noch sehr gut, dass sie erheblich mehr Speicherplatz und auch mehr Taktzyklen schluckt.

Ja. Na und? Siehe oben. Möchtest Du lieber Deine Webanwendungen in Assembler schreiben, um auf jeder Plattform das Optimum² an Performance und Speichernutzung herauszuholen¹? Diese Herangehensweise hat nach wie vor ihre Berechtigung in einigen Bereichen. Die üblichen Webanwendungen, die z. B. in PHP geschrieben werden, gehören mit Sicherheit nicht dazu. Wieder eine Frage des Verhältnisses (s. o.). Bei solchen Anwendungen sind eine vernünftige Struktur, durchdachte Algorithmen³ und die Wartbarkeit ein wesentliches Kriterium. Und wenn jemand dies durch den Einsatz von OOP in PHP verbessert sieht, solltest Du schon mehr als ein "das dauert dann..." ins Feld führen, um den zusätzlichen Overhead als Gegenargument geltend zu machen.

--

¹ Abgesehen mal davon, daß allein das Schreiben in Assembler überhaupt keine bessere Performance garantiert als mit compiler-/interpretergeneriertem Code aus einer Hochsprache mit tausendundeins Abstraktionebenen und Konstrukten, die dem Menschen beim Verstehen und Schreiben des Codes unterstützen sollen.

² Zur Optimierungsthematik, die jedes Mal in Deinen Beiträgen zu diesem Thema mitschwingt, sage ich nur folgendes: Optimiere nicht aus Prinzip an irgendetwas herum, sondern nur dann, wenn es wirklich Performanceprobleme gibt.

³ häufig viel effektiver als Instruktionengeschubse und das Feilschen um jeden Prozessortakt und jedes Byte auf Assemblerebene