Ist die Klassische OOP gescheitert?

[Niesi]

...
Es geht vor allem darum, dass man mit OOP halt nicht so gut Strukturieren kann, gerade bei sehr großen Projekten, soll es angeblich schnell unübersichtlich werden, dass habe ich auch bei meinen Projekten schon bemerkt... und es geht auch um das Vererben... Methoden soll man einfach hinzufügen.
Z.B. du hast eine Eigenschaft, die einen bestimmten Datentyp hat, nun möchtest du den Datentyp ändern, dass geht nicht so einfach und ist auch nicht unbedingt vorgesehen.
....

Hallo, eigentlich suche ich was ganz anderes, aber dieses Thema finde ich so interessant - vor allem die Behauptung, dass die OOP "gescheitert" sei - dass ich einfach nachfragen muss:

Diese Behauptung verstehe ich nicht - was wäre denn besser?

Zurzeit arbeite ich an einem Programm, welches Zahnradstufen berechnet, sowohl die Geometrie als auch die Tragfähigkeit. Das ist ein recht umfangreiches Fachgebiet, also wird auch das Programm entsprechend umfangreich - besonders, weil ich zusätzlich bereits vorhandene Datensätze (die als Textfiles vorliegen) einlesen und ausgeben lassen will und muss.

Ich muss jetzt gestehen: ohne OOP kann ich mir das fast gar nicht vorstellen, oder besser ausgedrückt: das Programm würde noch viel "größer" (vom Quelltext her länger) und vor allem viel komplizierter werden. Jetzt kann ich z. B. ein Zahnrad als Klasse definieren und mir davon die im Programm benötigten Zahnräder als Objekte kreieren. Wenn ich außerdem spezielle Zahnräder brauche, dann definiere ich die als Erben des "Grundzahnrads" und füge die speziellen Eigenschaften und Methoden hinzu. Z. B. ist ein Hohlrad mit Innenverzahnung eben so ein "spezielles" Zahnrad, welches vom außenverzahnten Stirnrad schon mal alle grundlegenden Eigenschaften und Methoden geerbt hat.

Oder ein Stirnradgetriebe: die Klasse stellt alle notwendigen Grundlagen bereit, die muss ich nie wieder anfassen. Und ein mehrstufiges Getriebe erbt alles und bekommt nur das notwendige hinzu.

Mich interessiert einfach: was wäre die Alternative zu OOP?

[pluto]

Diese Behauptung verstehe ich nicht - was wäre denn besser?

Steht alles in diesem Thread drin, lies ihn dir in ruhe durch. Es sind einfach Erkenntnisse der letzten Jahre, die zu dieser Aussage geführt haben.

Ich muss jetzt gestehen: ohne OOP kann ich mir das fast gar nicht vorstellen, oder besser ausgedrückt: das Programm würde noch viel "größer" (vom Quelltext her länger) und vor allem viel komplizierter werden.

Es geht um die Vererbung. Dadurch wird ein Projekt sehr schnell unübersichtlich. Rust z.b. Arbeitet mehr mit "Generics". Dort kann man nicht von einer Klasse ableiten sondern, es wird eine Methode hinzugefügt. Ist ein anderer Ansatz, von den die Rust Entwickler überzeugt sind, dass das wohl die Zukunft ist bzw. der bessere Ansatz.

Generics wird natürlich auch von FPC unterstützt, jedoch ist Object Pascal ein alte Sprache, Rust ist eine recht neue Sprache, wo viele neue Erkenntnisse eingeflossen sind.
Von einigen anderen Sprachen, darunter war auch Pascal.
Jedoch geht es hier natürlich nicht um Pascal oder Rust, sondern allgemein um die Aussage, dass die Klassische OOP gescheitert ist.

Jetzt kann ich z. B. ein Zahnrad als Klasse definieren und mir davon die im Programm benötigten Zahnräder als Objekte kreieren. Wenn ich außerdem spezielle Zahnräder brauche, dann definiere ich die als Erben des "Grundzahnrads" und füge die speziellen Eigenschaften und Methoden hinzu. Z. B. ist ein Hohlrad mit Innenverzahnung eben so ein "spezielles" Zahnrad, welches vom außenverzahnten Stirnrad schon mal alle grundlegenden Eigenschaften und Methoden geerbt hat.

In "alten" sprachen, nach dem bisherigen Modell wird das so gemacht. Schau dir mal die LCL an, wie viele Klassen und klassen schichten es dort gibt...

Mich interessiert einfach: was wäre die Alternative zu OOP?

Alternative wäre eine Methoden einfach zu einer Klasse hinzuzufügen, nicht von ihr abzuleiten. Ich kenne mich mit Generics, Praktisch nicht aus, aber ich meine, dass geht schon in die Richtung.

[Niesi]

Hallo Michael,

also, ich habe mich jetzt mal mit dem Thema etwas eingehender beschäftigt - und bin zu der Erkenntnis gelangt, dass mir zurzeit nichts WIRKLICH besseres geboten werden kann als die OOP.

Schade eigentlich, aber so ist es nun einmal.

Witzig fand ich die Beschreibung der funktionalen Programmierung anhand eines Beispiels mit der Funktion zur Kreisringflächenberechnung: wo da der Vorteil gegenüber z. B. Pascal sein soll, erschließt sich mir nicht. Was ist an

Code: Alles auswählen

 
function RingArea(r1, r2: extended): extended;
begin
  Result := (r1*r1-r2*r2)*pi;
end; 
 

komplizierter als das, was unter https://de.wikipedia.org/wiki/Funktionale_Programmierung als Beispiel gebracht wird?

Was ich auch nicht verstehe: warum ist Pascal eine "alte" Sprache? Zugegeben, es gibt sie schon lange - aber das ist mit der deutschen Sprache auch so, die gibt es noch sehr viel länger. Trotzdem benutzen wir sie munter weiter und drücken auch komplizierteste Vorgänge in dieser uralten Sprache aus, die sich ja auch durchaus weiterentwickelt.

Das sehe ich bei Pascal genauso: es gibt Pascal schon sehr lange, es entwickelt sich immer weiter und ist absolut auf der Höhe der Zeit, was die Programmierung angeht.

Die Leute, die immer nur nach immer neuen Sprachen und was weiß ich schauen, sind doch die Leute, die nie was fertig bekommen und dafür nach der Ausreden suchen. Letztendlich ist die Programmiersprache nicht das, was gute oder schlechte Software ausmacht, sondern der Algorithmus sowie die Personen, die aus diesem Algorithmus eine Software erstellen.

OOP ist nicht gescheitert, sie ist im Moment das Zuverlässigste und Beste, um große Projekte zu verwirklichen und später zu warten.
Und ObjectPascal ist für mich die beste, übersichtlichste sowie zuverlässigste (und schönste) Möglichkeit, damit sinnvoll Software zu entwickeln.

[pluto]

also, ich habe mich jetzt mal mit dem Thema etwas eingehender beschäftigt - und bin zu der Erkenntnis gelangt, dass mir zurzeit nichts WIRKLICH besseres geboten werden kann als die OOP.

Klar, mache ich ebenso. Das ist meistens so, man weiß, dass es bessere Alternativen gibt und nutzt sie nicht aus verschiedenen Gründen.

Was ich auch nicht verstehe: warum ist Pascal eine "alte" Sprache? Zugegeben, es gibt sie schon lange - aber das ist mit der deutschen Sprache auch so, die gibt es noch sehr viel länger.

Pascal stammt von Anfang den 1970(https://de.wikipedia.org/wiki/Pascal_(P ... iersprache)), rust z.b. ist eine neue Programmier Sprache von 2006 soweit ich weiß.
Alles entwickelt sich weiter. Das nennt sich Fortschritt. Ich denke, die Ansichten, von Rust, werden wohl früher oder später auch in anderen Programmiersprache eingearbeitet werden, was nicht immer eine gute Idee ist, aber so entwickelt sich die Programmier Sprachen weiter.

Klar kann man das heutige Pascal nicht mit dem Vergleichen von 1970. Aber in über 30 Jahre, wurden viele Konzepte und Ideen ausprobiert und im Prinzip sind sie in Rust eingeflossen.
Einiges diese Ideen, sind natürlich auch in Pascal eingeflossen z.b. gab es die OOP nicht immer für Pascal, sie kam erst später hinzu. Andere Sachen, z.b. Erweitere Records, kamen noch sehr viel später hinzu(Wobei der nutzen, eher Fragwürdig ist), genau wie mit den TypHelpern.

Ich hoffe jedenfalls, dass nicht alle gute Entwickler zu Rust übergelaufen sind und das sich Pascal weiter Entwickeln wird.

Das sehe ich bei Pascal genauso: es gibt Pascal schon sehr lange, es entwickelt sich immer weiter und ist absolut auf der Höhe der Zeit, was die Programmierung angeht.

Nein, Pascal ist noch nicht auf die die Höhe der Zeit, viele Konzepte in neueren Programmiersprachen sind noch nicht eingebaut, z.b. dass Klassen Erweitert werden können ohne Ableitung.
Zirkulärer Unit Aufruf wird immer noch als Fehler angesehen. Um nur zwei Beispiele zu nennen.

Ich nutzte Pascal aus anderen Gründen:
- Einfachere Syntax
- Klar Strukturiert
- BEGIN und END um Blöcke zu bilden
- Keine Zuweisungen in Vergleichen
- Klare Orte für Variablen, kein durcheinander wie z.b. in c
- kein Break in Case Anweisungen nötig
- Wegen der Lazarus IDE, habe bisher noch keine bessere gefunden.
- Weil es viele Infos, auch inzwischen in DEUTSCH gibt.

Pascal ist zwar alt, aber hat gegen über Rust aus meiner Sicht doch Vorteile. Rust Ändert sich ständig, ich finde kaum Brauchbare Dokus in Deutsch,
Bald jedoch gibt es eine erste Stabile Version...

Die Leute, die immer nur nach immer neuen Sprachen und was weiß ich schauen, sind doch die Leute, die nie was fertig bekommen und dafür nach der Ausreden suchen.

Nein, so ist es nun auch wieder nicht, ich kenne z.b. jemanden, der kennt wohl so zimlich alle Programmiersprachen, die es so gibt und der bekommt durchaus auch Sachen Fertig und Arbeitet wie wir alle an mehreren Projekten. Ich, denke solche Leute gibt es noch mehr. Auch hier im Forum kenne ich ein paar, die ich dazu zählen würde.

Letztendlich ist die Programmiersprache nicht das, was gute oder schlechte Software ausmacht, sondern der Algorithmus sowie die Personen, die aus diesem Algorithmus eine Software erstellen.

Auch diese Ansicht ist zu Einfach: Klar, jemand mit mehr Erfahrung, schreibt auch besseren Code, es kommt aber letztendlich auf den Kompiler an und auf die Optimierungen.

OOP ist nicht gescheitert, sie ist im Moment das Zuverlässigste und Beste, um große Projekte zu verwirklichen und später zu warten.

Ich habe auch nicht gesagt: Die ganze OOP ist gescheitert sondern nur "Das Konzept", des Vererbens.

Und ObjectPascal ist für mich die beste, übersichtlichste sowie zuverlässigste (und schönste) Möglichkeit, damit sinnvoll Software zu entwickeln.

Das wird leider von vielen anders gesehen. Dem bekannten vom Verein z .b. kann ich bisher nur mit mühe von Pascal überzeugen, weil er damit schon mal eine ganze Zeit Lang Programmiert hat und es sehr viel besser kennt als ich, allerdings nicht das Pascal von heute sondern vielleicht sind seine Erfahrungen auch schon über 10 Jahre alt.

[m.fuchs]

Nein, so ist es nun auch wieder nicht, ich kenne z.b. jemanden, der kennt wohl so zimlich alle Programmiersprachen, die es so gibt

Das ist Unfug, niemand kennt alle Sprachen und schon gar nicht so gut dass er beurteilen könnte welche "die Beste" ist. Der Vergleich von Programmiersprachen ist auch sehr, sehr selten das Kriterium für den Einsatz einer Sprache bei einem neuen Projekt.

[pluto]

Das ist Unfug, niemand kennt alle Sprachen und schon gar nicht so gut dass er beurteilen könnte welche "die Beste" ist

Hätte ich den Satz kennzeichnen müssen, dass es im Übertragenden Sinn gemeint ist?
Klar kann keiner alle Programmier sprachen kennen, aber es gibt Leute, die können nun mal sehr viele und deutlich mehr als 10 Stück.

Es gibt auch Personen, die können über 25 gesprochene Sprachen sprechen und lesen und verstehen. Da habe ich von zwei Zwillingen gehört, die das können.
Die können auch innerhalb von wenigen Tagen eine neue Sprache lernen.

Der Vergleich von Programmiersprachen ist auch sehr, sehr selten das Kriterium für den Einsatz einer Sprache bei einem neuen Projekt.

Das ist natürlich auch wieder war. Es gibt aber Programmier Sprachen, die sich nun mal für alles eignen.

In einem Arduino-Forum habe ich diesen Satz gelesen und finde ihn richtig:
Programmiersprachen sind keine Religionen.

D.H. deshalb muss man sich nicht Streiten und aufeinander "einhauen"
(Vorsicht: wieder im Übertragenden Sinn gemeint).

Es gib nun mal neue Erkenntnisse, die sich in über 30 Jahren Entwicklung gezeigt haben.
Früher gab es vielleicht nur ASM, später wurden die höheren Programmiersprachen Entwickelt. Dabei zeigten sich, bei jeder neuen Programmiersprache auch neue Erkenntnisse.
Warum gibt es dann heute so viele Programmiersprachen, aus den man wählen kann?
(Rhetorisch gemeint)

Ich frage mich, warum fällt es vielen schwer zu verstehen, dass die Vererbung von Klassen nun mal keine gute Idee ist und immer wieder zu Problemen führt und dann heißt es immer: Da ist ein Fehler in der Klassenstruktur oder auch beim Zirkulären Unit Aufruf: Da ist ein Fehler in der Code-Struktur.
Jedoch werden andere Sachen wie TypHelper oder erweitere Records eingebaut ohne da sie einen erkennbaren mehr Wert haben.

Vielleicht geht es aber auch in einigen fällen darum, die Tradition zu waren...

[m.fuchs]

Programmiersprachen sind keine Religionen.

Genau, aber:

Ich frage mich, warum fällt es vielen schwer zu verstehen, dass die Vererbung von Klassen nun mal keine gute Idee ist

Warum versuchst du dann mit fanatischem Eifer Leute davon zu überzeugen, dass Vererbung EVIL sei?

[pluto]

Warum versuchst du dann mit fanatischem Eifer Leute davon zu überzeugen, dass Vererbung EVIL sei?

Ich sage nicht, dass die "BÖSE" ist... Außerdem ist der Titel auch als Frage zu verstehen...Ich nutzte weiterhin die Vererbung, weil es in "Object Pascal", derzeit auch keine Alternative gibt.
Es ändert sich auch nichts. Ob man nun dran glaub oder nicht dran glaubt. Ich habe nur auf die Art und weiße reagiert wie geantwortet wurde, den Ton hasse ich nämlich.
Einfach zu sagen: Das ist Blödsinn oder das ist Quatsch, ohne zu sagen, warum das Blödsinn ist, es geht immer dabei: Ein Beispiel zu liefern.

Ich behaupte die Vererbung ist keine gute Idee, die meisten sagen: Das ist Blödsinn, aber warum meint ihr, die Vererbung ist ein Sinnvolles Konzept

Leider haben nur Praktisch ein oder zwei Personen das auch wirklich verstanden. So ist das wohl gekommen, dass ich meine Ansicht "verteidigen" musste.
Das eine ist dann zum anderen gekommen. Wie das immer so ist.
Bei den meisten Antworten, hat der Nutzer scheinbar die "Frage" falsch verstanden und es als "Jammern" interpretiert und es einfach abgelehnt und es als Blödsinn abgetan, wie in etwa der Kirche: Was wir nicht verstehen, kann es nicht geben, daher lehnen wir es ab(egal was).

Ich habe auch deutlich gemerkt, dass sich einige scheinbar Persönlich angegriffen gefühlt haben. Wenn man zwischen den Zeilen liest, kann dieser Eindruck entstehen.
Ich wollte natürlich niemanden Persönlich angreifen.

[Niesi]

Es gib nun mal neue Erkenntnisse, die sich in über 30 Jahren Entwicklung gezeigt haben.
Früher gab es vielleicht nur ASM, später wurden die höheren Programmiersprachen Entwickelt. Dabei zeigten sich, bei jeder neuen Programmiersprache auch neue Erkenntnisse.
Warum gibt es dann heute so viele Programmiersprachen, aus den man wählen kann?
(Rhetorisch gemeint)

Ich frage mich, warum fällt es vielen schwer zu verstehen, dass die Vererbung von Klassen nun mal keine gute Idee ist und immer wieder zu Problemen führt und dann heißt es immer: Da ist ein Fehler in der Klassenstruktur oder auch beim Zirkulären Unit Aufruf: Da ist ein Fehler in der Code-Struktur.
Jedoch werden andere Sachen wie TypHelper oder erweitere Records eingebaut ohne da sie einen erkennbaren mehr Wert haben.

Vielleicht geht es aber auch in einigen fällen darum, die Tradition zu waren...

Die Verebung ist in meinen Augen absolut sinnvoll, jedoch wie alles in der Welt: sie muss vernünftig und sinnvoll genutzt werden. Aber allein schon dadurch, dass ich z. B. Grafikobjekte von einer Klasse ableiten kann, die dann alle die Eigenschaften x und y haben, so dass ich dann alle Grafikobjekte in Objektlisten jederzeit auf die richtige Position bringen kann, ist die Vererbung eine der besten Entwicklungen, die mir untergekommen sind. x und y sind hier nur Beispiele, bei mir sind es eher so Zahnräder. In jedem Fall ist das "voll geil".

Und nun lass mich doch mal bitte wissen, was neuere Programmiersprachen bislang für Vorteile gebracht haben? Ich will hier gar nicht bezweifeln, dass es welche gibt und auch nicht, dass Weiterentwicklung unbedingt notwendig ist: aber wer die Behauptung aufstellt, dass die Vererbung in der OOP gescheitert ist, der sollte auch zeigen können, warum oder was so viel BESSER ist, dass sie als gescheitert gelten kann. Und nun komm nicht wieder mit RUST - wenn es so toll wäre, dann wäre der Hype darum größer. Vielleicht so groß, wie der Hype dereinst um Turbo Pascal war. Die Programmiersprache ist nicht DAS entscheidende, es sind die Leute, die damit "sprechen" ...

PS: Nein, ich nicht. Also persönlich angegriffen. Fühle ich mich nicht. Ich finde nur OOP mit Vererbung gut
PPS: Ich hoffe sehr, Du auch nicht. Denn hier geht's um die Sache, nicht um persönliches.

[pluto]

Und nun lass mich doch mal bitte wissen, was neuere Programmiersprachen bislang für Vorteile gebracht haben?

- Klassen, werden nicht Vererbt sondern Methoden werden hinzugefügt

- Bessere Fehler Behandlung, dadurch das man vieles zum teil 4 mal schreiben muss, weiß der Compiler sehr genau was gemeint ist.
Am Anfang einer Funktion steht immer die Fehler Behandlung, was soll gemacht werden, wenn es ein Fehler gibt und wie soll darauf reagiert werden?

- Erzeugt Sicheren Code

- Viele Probleme werden direkt beim Kompilieren erkannt und angemeckert.
Variablen werden per Standard erst mal als nicht veränderbar markiert. Sind aber keine "Const". Ist etwas verwirtend.

- Sinnvollere Compilier Meldungen mit Beispielen, wie es zu Fehler XY kommen kann.

- Bessere Optimierungen(erzeugt kleineren Code der Effektiver läuft)

[Lemmy]

Warum versuchst du dann mit fanatischem Eifer Leute davon zu überzeugen, dass Vererbung EVIL sei?

Ich sage nicht, dass die "BÖSE" ist... Außerdem ist der Titel auch als Frage zu verstehen...Ich nutzte weiterhin die Vererbung, weil es in "Object Pascal", derzeit auch keine Alternative gibt.
....
Einfach zu sagen: Das ist Blödsinn oder das ist Quatsch, ohne zu sagen, warum das Blödsinn ist, es geht immer dabei: Ein Beispiel zu liefern.

Sagt Dir Composition over inheritance was? https://en.wikipedia.org/wiki/Compositi ... nheritance oder wenns auf Deutsch sein soll: http://openbook.rheinwerk-verlag.de/oop ... 05_001.htm (Private Vererbung vs. Delegation)

Im Prinzip geht es darum: Du musst eine Menge an Instanzen einer Klasse verwalten. Dazu kann man eine LIste verwenden:

Code: Alles auswählen

 
type
  TMyList = class (TObjectList)
    property Item[index: Integer]: TMyObject read GetItem write SetItem;
  end;
 

TMyList erbt dabei alles von TObjectList. Zugriffsmethoden für die Items werden dabei neu implementiert um einen Typecast zu machen. ALlerdings erbt TMyList auch alle anderen Methoden (obwohl evtl. nicht benötigt) von TObjectList.

Vorteil: weniger Code; Nachteil: Austausch von TObjectList mit einer anderen Liste nur schwer möglich.

Alternative: Komposition; Delegation,... ist eines der grundlegenden Prinzipien der OOP. Hier erbt TMyList nicht ovn TObjectList:

Code: Alles auswählen

 
type
  TMyList = class (TObject)
  private
    FList: TObjectList;
  public
    property Item[index: Integer]: TMyObject read GetItem write SetItem;
    .....
  end;
 

hier erbt meine Liste nicht von TObjectList sondern von TObject (oder einem anderen Basisobjekt) - verwendet intern aber eine TObjectlist für die Verwaltung. die notwendigen Methoden werden implementiert und nach außen gereicht (d.h. mehr Code notwendig). Vorteil: Ich muss nicht, wie beim Vererben, alle Methoden nach außen frei geben, d.h. das Interface wird deutlich übersichtlich. Über Assign/AssignTo kann man auch problemlos "Kompatibilittät" mit anderen TOBjectList implementieren. Dazu ist die Liste Typsicher, d.h. man kann verhindern dass andere als TMyObject-Instanzen azufgenommen werden (ja, das geht mit Generics "einfacher").


Als weiteren Punkt wie man es anders machen kann, möchte ich hier noch die Interfaces anbringen, die die Möglichkeiten von OOP nochmal deutlich erweitern. Allerdings würde das hier den Artikel etwas sprengen. Sollte Interesse bestehen, kann ich zu den Interfaces noch in einem gesonderten Artikel was zu schreiben.

Alles in Allem sehe ich aktuell keine Alternative zu OOP wenn man größere Projekte stemmen will. Ja ich weiß, hier gibt es auch einige, die genau das als Grund nehmen gegen OOP zu sprechen. OOP ist aber nur ein Teil des Werkzeugkastens. Da gibt es dann noch so viele andere Dinge zu beachten (Trennung von Verantwortlichkeiten (Seperation of Concerns),..., Techniken wie dependency injection) - und für wirklich größere Projekte kommen dann so Dinge wie Microservices und co für die Architektur noch dazu.

Rust kenne ich jetzt nicht. Und ich bin auch nicht gut genug um den Vorteil von funktionalen Sprachen zu verstehen . Die gibt es sicherlich in ganz bestimmten Anwendungsszenarien. OOP dagegen ist eher als Schweizer Offizierstaschenmesser zu verstehen (so was wie victorinox swisschamp xavt) - sehr vielseitig einsetzbar, aber auch unhandlich,ggf. schwerfällig, man kann es falsch einsetzen und in bestimmten Situationen unterlegen gegen spezialisierte Werkzeuge. Nicht mehr und nicht weniger.

[pluto]

Sagt Dir Composition over inheritance was? https://en.wikipedia.org/wiki/Compositi ... nheritance oder wenns auf Deutsch sein soll: http://openbook.rheinwerk-verlag.de/oop ... 05_001.htm (Private Vererbung vs. Delegation)

Nein noch nicht. Ich bin kein Informatiker.

Im Prinzip geht es darum: Du musst eine Menge an Instanzen einer Klasse verwalten. Dazu kann man eine LIste verwenden:

Richtig. Mache ich öfter.

TMyList erbt dabei alles von TObjectList. Zugriffsmethoden für die Items werden dabei neu implementiert um einen Typecast zu machen. ALlerdings erbt TMyList auch alle anderen Methoden (obwohl evtl. nicht benötigt) von TObjectList.

Das ist der Punkt. Es werden Methoden und Eigenschaften Vererbt, die vielleicht NIE genutzt werden.

Vorteil: weniger Code; Nachteil: Austausch von TObjectList mit einer anderen Liste nur schwer möglich.

Wie genau sieht bei dir ein Austausch aus?

Alternative: Komposition; Delegation,... ist eines der grundlegenden Prinzipien der OOP. Hier erbt TMyList nicht ovn TObjectList:

So mache ich es immer fast. Das ist dafür sogar ein Begriff gibt... nicht schlecht. fItems, ist bei mir unter public, wegen der gründen der Einfachheit,
Sinnvoller wäre es natürlich unter private.

hier erbt meine Liste nicht von TObjectList sondern von TObject (oder einem anderen Basisobjekt) - verwendet intern aber eine TObjectlist für die Verwaltung. die notwendigen Methoden werden implementiert und nach außen gereicht (d.h. mehr Code notwendig).

Richtig. Aber damit wird das Problem nicht 100% gelöst. TObjectList hat immer noch Methoden, die ich vielleicht nie in TMyList verwende.

Vorteil: Ich muss nicht, wie beim Vererben, alle Methoden nach außen frei geben, d.h. das Interface wird deutlich übersichtlich. Über Assign/AssignTo kann man auch problemlos "Kompatibilittät" mit anderen TOBjectList implementieren. Dazu ist die Liste Typsicher, d.h. man kann verhindern dass andere als TMyObject-Instanzen azufgenommen werden (ja, das geht mit Generics "einfacher").

Das ist natürlich war. Generics muss ich mir noch mal genauer anschauen, ich habe zwar am Anfang des Thread's gesagt, dass ich es nicht verwende, aber anschauen werde ich es mir aufjedenfall.

Als weiteren Punkt wie man es anders machen kann, möchte ich hier noch die Interfaces anbringen, die die Möglichkeiten von OOP nochmal deutlich erweitern. Allerdings würde das hier den Artikel etwas sprengen. Sollte Interesse bestehen, kann ich zu den Interfaces noch in einem gesonderten Artikel was zu schreiben.

Verstehe mich bitte nicht falsch. Ich verwende die OOP schon recht lange, auch wenn ich vielleicht nicht alle Konzepte kenne und verstehe, verwende ich ein groß Teil davon.
Interfaces habe ich ebenfalls noch nie verwendet, weil ich dadrin bisher einfach keine Vorteile gesehen habe, dazu wäre ein extra Thread natürlich Spannend.

Alles in Allem sehe ich aktuell keine Alternative zu OOP wenn man größere Projekte stemmen will. Ja ich weiß, hier gibt es auch einige, die genau das als Grund nehmen gegen OOP zu sprechen. OOP ist aber nur ein Teil des Werkzeugkastens. Da gibt es dann noch so viele andere Dinge zu beachten

Ich spreche ja auch nicht von der ganzen OOP. Die OOP hat schon vorteile, ich meine jetzt NUR die Vererbung. Bei dir klingt das fast so, dass die OOP ohne die Vererbung keine OOP wäre.

(Trennung von Verantwortlichkeiten (Seperation of Concerns),..., Techniken wie dependency injection) - und für wirklich größere Projekte kommen dann so Dinge wie Microservices und co für die Architektur noch dazu

Viele namen der Konzepte kenne ich nicht. Ich finde es dann immer überraschend, wenn mir jemand ein Namen von einem Konzept erklärt und ich damit sogar was Anfangen kann, weil ich es bereits angewendet habe.
Das ist wohl der Unterschied, zu jemanden der Informatik wirklich gelernt hat und es nicht nur das gelernt hat was er gerade braucht.

Rust kenne ich jetzt nicht. Und ich bin auch nicht gut genug um den Vorteil von funktionalen Sprachen zu verstehen . Die gibt es sicherlich in ganz bestimmten Anwendungsszenarien. OOP dagegen ist eher als Schweizer Offizierstaschenmesser zu verstehen (so was wie victorinox swisschamp xavt) - sehr vielseitig einsetzbar, aber auch unhandlich,ggf. schwerfällig, man kann es falsch einsetzen und in bestimmten Situationen unterlegen gegen spezialisierte Werkzeuge. Nicht mehr und nicht weniger.

Soweit würde ich jetzt nicht gehen. Aber wie du schon gesagt hast, es ist ein Werkzeug. Ich hoffe jedenfalls das die OOP in Object Pascal erweitert wird, früher oder später und das man auch Methoden von bestehen Klassen hinzugefügt werden können. Das würde jedenfalls ganz neue Strukturen ermöglichen.
Gerade bei größeren Projekten. Bei größeren Projekten habe ich immer das Problem, die Übersicht über die Klassen und Methoden zu behalten.

[m.fuchs]

Das ist der Punkt. Es werden Methoden und Eigenschaften Vererbt, die vielleicht NIE genutzt werden.

1.) Warum ist das schlimm?

2.) Wenn du das nicht möchtest: leite halt nicht ab und schreib selbst.

Ich verstehe noch immer dein Problem nicht.

[pluto]

1.) Warum ist das schlimm?

Nun, damit ist das nicht mehr OOP Konform(so wie ich es verstanden habe), sonst ist das natürlich kein Problem, wenn man es nicht als Problem ansieht.

2.) Wenn du das nicht möchtest: leite halt nicht ab und schreib selbst.

Gute Idee. In Objekt Pascal gibt es bisher kaum eine Möglichkeit nicht von einer Klasse abzuleiten um die OOP nutzen zu können.
Ich weiß, natürlich das es viele Konzepte gibt, die die Anzahl der Nötigen Vererbungen auf ein Minimum reduzieren.

Schau dir mal den Klassenbaum von der LCL an. Lazarus kann das ja inzwischen Visualisieren.
- Wie viele Schichten gibt es?
- Wie viele Klassen gibt es?
Die Fragen sind natürlich nur Rhetorisch gemeint.

Ich mache noch mal ein Beispiel, warum die Vererbung nicht Sinnvoll ist: Ich würde gerne die Klasse "TLSocket" von LNet erweitern um ein Beliebiges Feld. Sagen wir "Data". Data soll nun von TObject sein. Nun könnte ich einfach von TLSocket ableiten und ein Feld Data hinzufügen, kein Problem.
Bisher konnte ich noch nicht herausfinden, welche Methode ich von LNET anpassen muss, damit meine abgeleitete Klasse erstellt wird und eben nicht TLSocket.
Dabei ist LNET was die Anzahl der Klassen angeht noch recht übersichtlich. Vielleicht gibt es auch ein Event, welches ausgelöst wird, wo ich meine Klasse erstellen kann.
Damit meine ich sowas "TMyLSocket.create".

Bisher habe ich aber noch keine Beispiele gesehen, warum die Vererbung Sinnvoll ist. Wie gesagt: Ich kenne die Vererbung und nutze sie. Klar weiß ich, dass man dadurch wiederverwendbaren Code schreiben kann. Jedoch nur bis zu einem Gewissen grad.

Ich verstehe noch immer dein Problem nicht.

Ein Problem ist das eher nicht, sondern legendlich eine Frage. Vielleicht kam das auch falsch "rüber". So im nachhinein.
Wenn du das als Problem siehst, bitte: Wenn ein Projekt aus sehr vielen Klassen besteht, wie behält man da die Übersicht?
Wobei "sehr viel" natürlich dehnbar ist und für jeden was anders bedeuten kann.

Außerdem sehe ich bei der Vererbung auch, dass Problem, dass man Datentypen von einem Feld nicht ändern kann. Z.B. das Feld Value, könnte in KlasseA ein Integer sein und in KlasseB ein String. Sowas würde nur über Variant gehen oder über ein passenden Klassen Modell, welches aber etwas übertrieben wäre.
Die Sichtbarkeit von einer z.b. Methode kann nur in einer Richtung beeinflusst werden. Selten gibt es mehrfach Vererbung, wenn man sie braucht, heißt es: Schlechte Klassenstruktur.
Das geht in Object Pascal z.b. soweit ich weiß nur über Interface.

Sagen wir es so: Pferde Kutschen gibt es immer noch, früher wurden sie Oft verwendet um von A nach B zu kommen, heute sieht man sie deutlich seltener, warum? Weil es einen Fortschritt gab und eine Alternative Entwickelt wurde.
So sehe ich es auch bei der OOP. Auch die hat sich weiter Entwickelt. Ansichten die es vor über 30 Jahren gab, gibt es nicht mehr.
Wir verwenden immer noch die Grundstruktur, aber sie wurde angepasst. An neue Erkenntnisse.

In Gewisserweise kann man natürlich immer noch mit der Kutsche von A nach B fahren, aber wer macht damit schon längere Strecken und fährt damit mal eben 400 km oder so?

Versteht mich bitte nicht Falsch, ich möchte euch nicht von meinen Ansichten um jeden Preis überzeugen, aber ich möchte auch nicht das das als Blödsinn oder Quatsch abgetan wird.
Jeder soll das glauben was er möchte, Programmier Sprachen sind zwar keine Religionen, aber es gibt Religionsfreiheit(soweit ich weiß)

[BeniBela]

Ich hoffe jedenfalls das die OOP in Object Pascal erweitert wird, früher oder später und das man auch Methoden von bestehen Klassen hinzugefügt werden können. Das würde jedenfalls ganz neue Strukturen ermöglichen.

Dafür gibt es ja schon die class helper