Es sei noch einmal wiederholt: Man kann alle diese Arten von Modifikationen vornehmen, ohne daß man sich den Rest des Codes anschaut. Diese Idee hört sich für einige Leser alarmierenderweise vertraut an. Es ist das Rezept für Spaghetti-Code.

Das objektorientierte Modell macht es einfach, Programme durch Hinzufügen der benötigten Funktionalität zu schreiben. Dies bedeutet oft, daß es einen strukturierten Weg zum Schreiben von Spaghetti-Code bereitstellt. Das ist nicht notwendigerweise schlecht, aber auch nicht notwendigerweise gut.

Viel Code ist Spaghetti-Code, und das wird sich wahrscheinlich auch nicht so schnell ändern. Für Programme, die sowieso Spaghetti geworden wären, ist das objektorientierte Modell wenigstens für eines gut: Es ist strukturiertes Spaghetti. Aber für Programme, denen dieses Schicksal anderenfalls erspart geblieben wäre, sind objektorientierte Abstraktionen eher gefährlich als nützlich.

Was haltet ihr davon? Abgesehen vom Hinweis, kein OOP zu benutzen, wo es nicht hingehört, ist das doch nur (verzeihung) unnötiges Geflame eines Funktionalprogrammierers?

Ansonsten versteh ich sein Argument nicht. Aber wnn man ein Programm irgendwo aendert, ohne zumindest die grobe Gesamtstrutkur zu verstehen, sondern sich nur auf "seine Aufgabe" konzentriert, laeuft man sicher Gefahr, am urspruenglichen Design des Programmes "vorbeizuprogrammieren" und den Code dadurch zu verschlechtern.

OOP verringert die Gefahr, Spaghetti-Code zu schreiben einfach dadurch,
daß der Entwickler (je nach Sprache) gezwungen wird, Interface und Implementation voneinander zu trennen.

Durch OOP erhöht sich aber das Risiko, Ravioli-Code zu schreiben, nämlich dann,
wenn die Klasseneinteilung und Verschachtelung allzu feinkörnig wird. Es
entsteht dann eine Vielzahl von Klassen mit tiefen Vererbungs-Pfaden, bei
denen man nicht mehr so leicht erkennt, was in den Methoden der Klassen
eigentlich genau passiert, nämlich meist zu wenig: Zu viel Interface und
zu wenig Methode.

Gruß

Viel Code ist Spaghetti-Code

aha...

Haette der Threadstarter sich etwas mehr mit PG auseinandergesetzt, haette er festgestellt, dass PG statt CLOS zu benutzen, propagiert, Daten in Closures zu kapseln und somit ein OO-System nachzubilden (beschreibt er in vielen Essays, s.a. Hackers & Painters | ISBN: 0596006624).

Haette der Threadstarter sich etwas mehr mit PG auseinandergesetzt, haette er festgestellt, dass PG statt CLOS zu benutzen, propagiert, Daten in Closures zu kapseln und somit ein OO-System nachzubilden ...

er schlägt damit vor, prinzipiell viel freier als mit OO (im sinne von "klassen haben ISA und HASA und nur das") zu sein, aber alle OO-features auch zu haben?

Doktor Prokt schrieb:

Haette der Threadstarter sich etwas mehr mit PG auseinandergesetzt, haette er festgestellt, dass PG statt CLOS zu benutzen, propagiert, Daten in Closures zu kapseln und somit ein OO-System nachzubilden ...

er schlägt damit vor, prinzipiell viel freier als mit OO (im sinne von "klassen haben ISA und HASA und nur das") zu sein, aber alle OO-features auch zu haben?

Man kann mit Closures tatsaechlich erstaunlich viel abbilden (zB auch Vererbung, und Metaklassen).

jemand, der "yes" als variablenname benutzt ist aber schon irgendwie fragwürdig.