Ist die Klassische OOP gescheitert?

[pluto]

Dafür gibt es ja schon die class helper

Dafür sind die da? Das man Klassen Methoden hinzufügen kann? Ah, gut zu wissen. Dann hätten sie ja doch einen Sinn...

[Niesi]

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

Verstehe ich nicht. Wieso vererbst Du dann? Es zwingt Dich doch niemand ...

Es gibt da dieses Beispiel mit dem Kreis und der Ellipse - mit der blödsinnigen Begründung, ein Kreis müsse von der Ellipse erben weil er auch eine sei.

Ein Kreis ist dadurch definiert, dass alle Punkte denselben Abstand zum Mittelpunkt haben. Also ist er schon mal keine Ellipse. Beides sind Grafikobjekte, können also von der tGrafikclass abgeleitet werden. Du KANNST den Kreis von einer Ellipse erben lassen - das ist dann ziemlich blöd von Dir.

DU bist es, der den Quelltext schreibt, nicht die Programmiersprache, nicht die OOP und nicht die Vererbung.

[m.fuchs]

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

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.

Nein, das hast du falsch verstanden. In OOP gibt es keine Forderung dass nur genutzter Code existieren soll. Das wäre eine Forderung des Clean Code. Gilt aber auch dort nur für selbst geschriebenen Code und nicht für genutzte Bibliotheken.

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.

Es geht im Bereich der Klassen sogar gar nicht. Minimum ist alles von TObject abgeleitet. Das ist aber nicht schlimm, denn das enthält den für die Verwaltung von Klassen und Objekten notwendigen Code. Den brauchst du also immer.
Betrachte eine Ableitung von TObject als nicht verschwendeten Code.

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.

Die Frage hat auch nicht viel mit dem Thema zu tun. Das ist als wenn ich sage, dass Betriebssysteme alle schlecht sind weil WIndows so kacke ist.
Du kannst doch nicht eine riesige Klassenbibliothek die sich erstens an einer anderen Bibliothek orientieren muss und zweitens auch noch eine Reihe von Betriebssystemen und GUI abdecken muss als Beispiel für das Scheitern eines Programmierparadigmas daher nehmen.

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.

Und wieder machst du dein Scheitern bei der Nutzung einer Bibliothek (verursacht durch fehlendes Verständnis dieser Bibliothek?) zu einem generellen OOP-Problem. Ist da wirklich OOP daran schuld? Wohl eher nicht.

Bisher habe ich aber noch keine Beispiele gesehen, warum die Vererbung Sinnvoll ist. Wie gesagt: Ich kenne die Vererbung und nutze sie.

Ich glaube beide Sätze widersprechen sich ein bisschen.

Wenn du das als Problem siehst, bitte: Wenn ein Projekt aus sehr vielen Klassen besteht, wie behält man da die Übersicht?

Das regelt die Architektur. Ist übrigens völlig egal ob OOP oder was anderes. Je größer eine Projekt, desto eher der Verlust der Kontrolle darüber.

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.

Ich sehe an Autos das Problem, dass sie keine Fahrräder sind. Dabei sind doch beides einfach nur Verkehrsmittel.

Die Sichtbarkeit von einer z.b. Methode kann nur in einer Richtung beeinflusst werden.

Das muss auch so sein, schließlich muss man sich ja darauf verlassen können, dass ein Child wie sein Parent verwendet werden kann.

Selten gibt es mehrfach Vererbung, wenn man sie braucht, heißt es: Schlechte Klassenstruktur.

DU schreibst weiter oben, dass du leicht den Überblick verlierst. Und dann forderst du Mehrfachvererbung und (an anderer Stelle) zirkuläre Units? Damit wird es doch noch unübersichtlicher.

Wir verwenden immer noch die Grundstruktur, aber sie wurde angepasst. An neue Erkenntnisse.

Ja, und? Dann ist doch alles gut wenn es modernisiert wird.

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ß)

Du sollst auch gerne daran glauben und niemand wird dich zwingen OOP mit Freepascal zu nutzen. Oder dass du bei dieser Sprache bleiben musst. Alternativen sind ja da.
Und wenn du damit besser klar kommst ist das doch wunderbar. Das ist nämlich auch ein Auswahlkriterium für Sprachen/Paradigmen. Derjenige der damit arbeitet muss sich damit auch wohlfühlen.
Aber trotzdem werde ich weiterhin antworten und die Probleme in der Argumentation gegen OOP benennen. Das macht eine Diskussion ja aus.

[pluto]

Verstehe ich nicht. Wieso vererbst Du dann? Es zwingt Dich doch niemand ...

Doch, wenn sie in der Klasse, von der ich Erbe vorhanden sind. Erbe ich sie, ob ich will oder nicht will...

Es gibt da dieses Beispiel mit dem Kreis und der Ellipse - mit der blödsinnigen Begründung, ein Kreis müsse von der Ellipse erben weil er auch eine sei.

So blöd ist es nicht, beides ist nun mal Rund.

Ein Kreis ist dadurch definiert, dass alle Punkte denselben Abstand zum Mittelpunkt haben. Also ist er schon mal keine Ellipse. Beides sind Grafikobjekte, können also von der tGrafikclass abgeleitet werden. Du KANNST den Kreis von einer Ellipse erben lassen - das ist dann ziemlich blöd von Dir.

Vielleicht. Genau das ist das Problem dabei... Das gleiche mit dem Quadrat und dem Rechteck.
Beides hat ecken, also muss es eine Gemeinsame klasse geben.

Nein, das hast du falsch verstanden. In OOP gibt es keine Forderung dass nur genutzter Code existieren soll. Das wäre eine Forderung des Clean Code. Gilt aber auch dort nur für selbst geschriebenen Code und nicht für genutzte Bibliotheken.

Aha, jedoch belegen diese Methoden, wenn auch Minimal Speicher, falls der Compiliere nicht genutzt Methoden überhaupt einkompiliert.

Es geht im Bereich der Klassen sogar gar nicht. Minimum ist alles von TObject abgeleitet. Das ist aber nicht schlimm, denn das enthält den für die Verwaltung von Klassen und Objekten notwendigen Code. Den brauchst du also immer.

Das ist klar, TObject ist das Fundament.

Betrachte eine Ableitung von TObject als nicht verschwendeten Code.

Natürlich nicht, es ist eine Notwendigkeit. TObject nimmt einen ja, viel arbeit ab, die man sonst bei jeder Klasse hätte.
Wenn ich es nicht wollte, würde ich records nehmen.

Die Frage hat auch nicht viel mit dem Thema zu tun. Das ist als wenn ich sage, dass Betriebssysteme alle schlecht sind weil WIndows so kacke ist.

Ah, dass liegt an Windows, auch wenn ich Linux nutze. Ich glaube, nicht das es an GDI+ bzw. GTK2 bzw. GTK3 oder QT liegt, dass die LCL so geworden ist, auf der anderen Seite, die LCL möchte ja Kompatibel sein zu Delphi und Delphi ist ja ausschließlich für Windows entwickelt worden.

Du kannst doch nicht eine riesige Klassenbibliothek die sich erstens an einer anderen Bibliothek orientieren muss und zweitens auch noch eine Reihe von Betriebssystemen und GUI abdecken muss als Beispiel für das Scheitern eines Programmierparadigmas daher nehmen.

Gut, dann schau dir GLScene an. Das ist eine sehr Umfangreiche Bibliothek. Im Prinzip kannst du auch schon das "HTML Panel" anschauen.

Und wieder machst du dein Scheitern bei der Nutzung einer Bibliothek (verursacht durch fehlendes Verständnis dieser Bibliothek?) zu einem generellen OOP-Problem. Ist da wirklich OOP daran schuld? Wohl eher nicht.

Sicher? Klar, der Autor von LNET hat sich was gedacht bei dem Klassen Design. Es muss jedoch eine Möglichkeit geben....

Ich glaube beide Sätze widersprechen sich ein bisschen.

Mag sein, ich habe vielleicht Informatik nicht Studiert, wie du oder andere hier, aber ich kann die OOP einsetzten und verstehe sie auch.
Klar, ist es nicht so einfach zu begründen, warum die Vererbung Sinnvoll ist. Klar, alles was Vorteile hat, hat natürlich auch Nachteile.

Das regelt die Architektur. Ist übrigens völlig egal ob OOP oder was anderes. Je größer eine Projekt, desto eher der Verlust der Kontrolle darüber.

Ah und dann kommt da wohl noch die Dokumention hinzu und UML Diagramme und der gleichen...

Ich sehe an Autos das Problem, dass sie keine Fahrräder sind. Dabei sind doch beides einfach nur Verkehrsmittel.

Guter Vergleich... jedoch wird an Flug-Autos geforscht, dass sind Autos, die auf der Straße fahren können, aber sie sollen auch Fliegen können.

DU schreibst weiter oben, dass du leicht den Überblick verlierst. Und dann forderst du Mehrfachvererbung und (an anderer Stelle) zirkuläre Units? Damit wird es doch noch unübersichtlicher.

Nicht unbedingt, jetzt muss ich mich immer verdrehen, damit ich die Struktur halbwegs übersichtlich hinbekomme.

Du sollst auch gerne daran glauben und niemand wird dich zwingen OOP mit Freepascal zu nutzen. Oder dass du bei dieser Sprache bleiben musst. Alternativen sind ja da.

Ich glaube, du hast den Punkt noch nicht so verstanden. Wenn ich die Vererbung wirklich so als Probleme ansehe, würde ich auf eine andere Sprache wechseln und kein ObjectPascal nutzen.

Ich wollte eigentlich nur über das Thema Diskutieren, dass haben viele jedoch völlig falsch verstanden. Sobald man so ein Thema anfängt oder was ähnliches: kommt früher oder später, nutzt doch was anders. Als ob es, nur das EINE geben kann.

Und wenn du damit besser klar kommst ist das doch wunderbar. Das ist nämlich auch ein Auswahlkriterium für Sprachen/Paradigmen. Derjenige der damit arbeitet muss sich damit auch wohlfühlen.
Aber trotzdem werde ich weiterhin antworten und die Probleme in der Argumentation gegen OOP benennen. Das macht eine Diskussion ja aus.

Ja, dass wäre vom Vorteil, aber achte auf den Ton dabei. Und auch hier wieder: Das ließ sich so, als ob ich gegen die gesammte OOP wäre.
Dabei geht es mir nur um einen gewissen Teil der OOP. Das ist der Punkt. Außerdem am Anfang vom Thread, war ich im Prinzip nicht gegen oder für die Vererbung sondern wollte nur darüber sprechen. Erst im Thread hat sich, dass anders entwickelt als erwartet.

[Niesi]

Verstehe ich nicht. Wieso vererbst Du dann? Es zwingt Dich doch niemand ...

Doch, wenn sie in der Klasse, von der ich Erbe vorhanden sind. Erbe ich sie, ob ich will oder nicht will...

Es gibt da dieses Beispiel mit dem Kreis und der Ellipse - mit der blödsinnigen Begründung, ein Kreis müsse von der Ellipse erben weil er auch eine sei.

So blöd ist es nicht, beides ist nun mal Rund.

Ein Kreis ist dadurch definiert, dass alle Punkte denselben Abstand zum Mittelpunkt haben. Also ist er schon mal keine Ellipse. Beides sind Grafikobjekte, können also von der tGrafikclass abgeleitet werden. Du KANNST den Kreis von einer Ellipse erben lassen - das ist dann ziemlich blöd von Dir.

Vielleicht. Genau das ist das Problem dabei... Das gleiche mit dem Quadrat und dem Rechteck.
Beides hat ecken, also muss es eine Gemeinsame klasse geben.

Also, ich denke, Du solltest Dir mal in Ruhe Gedanken machen, was das Vererben in der OOP bedeutet und was Du damit machen möchtest und was nicht. Denn Du weißt das nicht.

Einfach zu behaupten, die OOP sei wegen der Vererbung gescheitert, ohne einen einzigen wirklichen Grund zu nennen, halte ich für sehr dünn - sind ein wenig wie die Trauben, an die der Fuchs nicht rankommt.

Woher ich diese Überlegung nehme? Sieh Dir mal Deinen Kommentar zum Kreisbeispiel an: ein Kreis ist dadurch definiert, dass alle Punkte denselben Abstand zum Mittelpunkt haben. Dein Kommentar: "Ein bisschen ist er aber auch Ellipse, beide sind nun mal Rund."

Lieber Michael: eine Ellipse zeichnet sich dadurch aus, dass NICHT alle Punkte denselben Abstand zum Mittelpunkt haben. Sie ist auch nicht rund, sie ist oval. Das Problem ist, dass nicht logisch und präzise an die Sachen rangegangen wird. Auch beim Quadrat: ein Quadrat hat vier rechte Winkel und vier gleich lange Seiten - wenn eine Geometrie vier rechte Winkel und zwei verschiedene Seitenlängen hat, dann ist es kein Quadrat. Und kein Wesen dieses Universums kann mich dazu zwingen, einen Kreis von einer Ellipse abzuleiten. Genau wie beim Quadrat: niemand MUSS es von einem Rechteck ableiten! (Umgekehrt wäre es jeweils sinnvoll, aber das will natürlich wieder niemand wissen )

Und hör bitte auf, dauernd beleidigt zu sein: wenn Du diskutieren möchtest, musst Du bereit sein, andere Meinungen zu akzeptieren und allenfalls durch Argumente zu entkräften. Sonst macht das keinen Sinn.

[Timm Thaler]

eine Ellipse zeichnet sich dadurch aus, dass NICHT alle Punkte denselben Abstand zum Mittelpunkt haben. Sie ist auch nicht rund, sie ist oval. Das Problem ist, dass nicht logisch und präzise an die Sachen rangegangen wird...

Oder zu logisch. In der Mathematik wird nunmal abgeleitet: Der Kreis ist eine Sonderform der Ellipse, bei der beide Halbachsen gleich lang sind. Oder: Das Quadrat ist eine Sonderform des Rechtecks, bei dem alle Seiten gleich lang sind. Das Rechteck ist eine Sonderform des Parallelogramms, bei dem alle Winkel rechte Winkel sind. Das Parallelogramm ist eine Sonderform des Vierecks, bei dem gegenüberliegende Seiten gleich lang sind. Das Viereck hat vier Seiten und vier Winkel.

Das OOP aufgedröselt definierst Du erst Viereck: a,b,c,d,alpha,beta,gamma,delta => Parallelogramm: a=c,b=d,alpha=gamma,beta=delta => Rechteck: alpha=beta=gamma=delte=90° => Quadrat: a=b=c=d. Andererseits hast Du Rhombus aus Parallelogram: a=b=c=d => Quadrat: alpha=beta=gamma=delte=90°

Und dann willst Du ein Quadrat zeichnen: Box(x1, y1, x2, y2); Fertsch.

Das obige Beispiel mit den Zahnrädern ist geradezu ein Paradebeispiel zur Vererbung in der OOP, und da mag Vererbung sinnvoll sein. Kreis / Ellipse oder Vierecke sind auch gern gewählte Beispiele, aber hier zeigt sich, dass es eher kontraproduktiv ist, alles in OOP und Vererbung quetschen zu wollen. Für einen Kreis brauch ich Mittelpunktkoordinaten und Radius. Für eine Ellipse brauche ich Mittelpunkt, Halbachsen, eigentlich noch Winkel der Halbachse. Leite ich den Kreis davon ab, schleppe ich das sinnlos mit rum. Andererseits die Ellipse vom Kreis erweitern ist auch Quatsch, weil was soll ich dann mit dem Radius?

Und dazu kommt noch, dass Vererbung ja nur ein kleiner Teil der OOP ist.

[pluto]

Einfach zu behaupten, die OOP sei wegen der Vererbung gescheitert, ohne einen einzigen wirklichen Grund zu nennen, halte ich für sehr dünn - sind ein wenig wie die Trauben, an die der Fuchs nicht rankommt.

Das, dass immer noch falsch verstanden wird: ich meinte nicht die komplette OOP, sondern nur ein Teil der OOP. Die OOP besteht ja noch aus mehr, als nur die Vererbung.

Woher ich diese Überlegung nehme? Sieh Dir mal Deinen Kommentar zum Kreisbeispiel an: ein Kreis ist dadurch definiert, dass alle Punkte denselben Abstand zum Mittelpunkt haben. Dein Kommentar: "Ein bisschen ist er aber auch Ellipse, beide sind nun mal Rund."

Genau, darum geht es. Ein Viereck, hat nun mal 4 Ecken, genau wie ein Quadrat.

Lieber Michael: eine Ellipse zeichnet sich dadurch aus, dass NICHT alle Punkte denselben Abstand zum Mittelpunkt haben. Sie ist auch nicht rund, sie ist oval. Das Problem ist, dass nicht logisch und präzise an die Sachen rangegangen wird.

Das ist natürlich ein Argument. Im Allgemeinen wird es aber so gesehen, dass der Kreis, eine untermenge der Ellipse sein sollte, warum auch immer.

Auch beim Quadrat: ein Quadrat hat vier rechte Winkel und vier gleich lange Seiten - wenn eine Geometrie vier rechte Winkel und zwei verschiedene Seitenlängen hat, dann ist es kein Quadrat. Und kein Wesen dieses Universums kann mich dazu zwingen, einen Kreis von einer Ellipse abzuleiten. Genau wie beim Quadrat: niemand MUSS es von einem Rechteck ableiten!

Wenn jedoch eine Schul Aufgabe so gestellt ist, kannst du auch schlecht zum Lehrer sagen: Das ist so, Unfug und kann nicht aufgehen.

Und hör bitte auf, dauernd beleidigt zu sein: wenn Du diskutieren möchtest, musst Du bereit sein, andere Meinungen zu akzeptieren und allenfalls durch Argumente zu entkräften. Sonst macht das keinen Sinn.

Wo, beleidige ich denn? Das Problem ist eher, dass ihr mich beleidigt. Wenn man es genau nimmt und mich als "Dummkopf" da stellt. Nur, weil ich mit diesem Thema angefangen habe.
Wenn ich mir den Thread so anschaue, kann man zu diesem Schluss kommen. Bewusst, jedenfalls beleidige ich niemanden. Aber ich möchte auch nicht als Dummkopf da hingestellt werden.
Wer möchte das schon gerne? Ich habe meine Meinungen und ihr habt eure. Ich kann und möchte euch auch nicht vom Gegenteil überzeugen. Das kam auch völlig falsch rüber.

Wenn ihr beweise für diese neue Behauptung haben wollt, schaut euch in ruhe diesen Thread an, es gibt genügend Beispiele.
Ihr habt mich praktisch in eine Ecke getrieben, wo ich nur noch schwer oder gar nicht mehr raus komme.
Der Thread hat sich nun mal leider anders Entwickelt, als ich es erhofft hatte.

Ich denke, dass Sinnvollste wäre wohl, den Thread zu Schließen oder sogar zu löschen, bevor es noch schlimmer wird. Aus meiner Sicht, wurde der Anlass zu diesem Thread völlig falsch verstanden. So kam das eine zum anderen. Am Anfang war es auch wie gesagt, nicht MEINE Überzeugung, dass die Vererbung gescheitert ist, sondern es war legendlich ein Punkt, den ich "gehört" habe.

Daher noch mal meine Bitte: Diesen Thread zu schließen oder sogar zu löschen, hier kommt nichts mehr Sinnvolles. Scheinbar kann ich mein Standpunkt auch nicht mehr Klarstellen, weil immer noch von der ganzen OOP gesprochen wird. Dabei meine ich nur ein "Teil" der OOP.

Wenn wir es noch einmal von vorne versuchen wollen, erstelle ich gerne noch einen weiteren Thread zum Thema, den ich bereits vorbereit habe. Den werde ich noch ergänzen.

Oder zu logisch. In der Mathematik wird nunmal abgeleitet: Der Kreis ist eine Sonderform der Ellipse, bei der beide Halbachsen gleich lang sind. Oder: Das Quadrat ist eine Sonderform des Rechtecks, bei dem alle Seiten gleich lang sind. Das Rechteck ist eine Sonderform des Parallelogramms, bei dem alle Winkel rechte Winkel sind. Das Parallelogramm ist eine Sonderform des Vierecks, bei dem gegenüberliegende Seiten gleich lang sind. Das Viereck hat vier Seiten und vier Winkel.

Das ist schön geschrieben.

Das obige Beispiel mit den Zahnrädern ist geradezu ein Paradebeispiel zur Vererbung in der OOP, und da mag Vererbung sinnvoll sein. Kreis / Ellipse oder Vierecke sind auch gern gewählte Beispiele, aber hier zeigt sich, dass es eher kontraproduktiv ist, alles in OOP und Vererbung quetschen zu wollen.

Das ist ein weitere Punkt zum Thema, den ich sehr gut finde.

Für einen Kreis brauch ich Mittelpunktkoordinaten und Radius. Für eine Ellipse brauche ich Mittelpunkt, Halbachsen, eigentlich noch Winkel der Halbachse. Leite ich den Kreis davon ab, schleppe ich das sinnlos mit rum. Andererseits die Ellipse vom Kreis erweitern ist auch Quatsch, weil was soll ich dann mit dem Radius?

Das ist gut beschrieben.

Und dazu kommt noch, dass Vererbung ja nur ein kleiner Teil der OOP ist.

Am Anfang des Thread dachte ich auch, es geht in der OOP nur um die Vererbung, dabei ist die Vererbung nur ein kleiner Teil, der OOP.

Vorhin habe ich geschrieben, dass wohl nichts mehr Sinnvolles kommt, so kann man sich täuschen.

[m.fuchs]

Das regelt die Architektur. Ist übrigens völlig egal ob OOP oder was anderes. Je größer eine Projekt, desto eher der Verlust der Kontrolle darüber.

Ah und dann kommt da wohl noch die Dokumention hinzu und UML Diagramme und der gleichen...

Das gehört alles zur Architektur. Ich vermute, dass so gut wie alle Probleme auf die du gestoßen bist eben nicht mit Nachteilen von OOP zusammenhängen, sondern mit einem Strukturproblem deiner Architektur.
Aber du kannst ja gerne noch deinen neuen Thread aufmachen, vielleicht mit einem konkreten Beispiel, dann kann man das eventuell etwas einfacher aufdröseln.

[pluto]

Das gehört alles zur Architektur. Ich vermute, dass so gut wie alle Probleme auf die du gestoßen bist eben nicht mit Nachteilen von OOP zusammenhängen, sondern mit einem Strukturproblem deiner Architektur.

Ich finde das ist zu einfach gesagt.

Aber du kannst ja gerne noch deinen neuen Thread aufmachen, vielleicht mit einem konkreten Beispiel, dann kann man das eventuell etwas einfacher aufdröseln.

Ich überlege es mir, in Anbetracht, wie sich dieser Thread Entwickelt hat... Als Beispiel würde ich das mit dem "Kreis" und dem "Quadrat" nehmen.
Vielleicht fällt mir auch noch was anderes ein.
Mir ging es halt darum, verschiedene Ansichten zu "lesen" und mir dann meine eigene Meinung zum Thema zu bilden.

[m.fuchs]

Aber du kannst ja gerne noch deinen neuen Thread aufmachen, vielleicht mit einem konkreten Beispiel, dann kann man das eventuell etwas einfacher aufdröseln.

Ich überlege es mir, in Anbetracht, wie sich dieser Thread Entwickelt hat... Als Beispiel würde ich das mit dem "Kreis" und dem "Quadrat" nehmen.

Nimm das bitte nicht, Kreis und Quadrat ist kein konkretes Beispiel. Das habe ich hier schon mal erklärt.

[Timm Thaler]

Ich denke, das Problem ist, dass die OOP Verfechter versuchen alles in OOP zu pressen.

Ich hab mal ein Terminal mit Qt5 und Qt Creator unter C++ umgesetzt. Da musste man für jeden Mist Slots und Verbindungen erzeugen, selbst wenn dann nur ein Widget verwendet wurde um den Status der RS232 Leitungen anzuzeigen. Das ganze prozedural unter PureBasic war deutlich entspannter. Das ganze halb OOP unter Pascal - mit Widgets in OOP, der RS232 prozedural - war auch deutlich entspannter.

Man sollte einfach nicht alles auf Krampf in OOP pressen.

[pluto]

Ich denke, das Problem ist, dass die OOP Verfechter versuchen alles in OOP zu pressen.

Genau.

Ich hab mal ein Terminal mit Qt5 und Qt Creator unter C++ umgesetzt. Da musste man für jeden Mist Slots und Verbindungen erzeugen, selbst wenn dann nur ein Widget verwendet wurde um den Status der RS232 Leitungen anzuzeigen. Das ganze prozedural unter PureBasic war deutlich entspannter. Das ganze halb OOP unter Pascal - mit Widgets in OOP, der RS232 prozedural - war auch deutlich entspannter.

Ich glaube, man kann sehr schnell übertreiben und sieht den Wald voller Klassen nicht mehr. Ich hatte mal für eine GUI ein Konzept, welches pro Komponente etwa 5 Klassen benötigt hätte, von diesem Konzept habe ich sehr schnell Abstand genommen und es nicht einmal ausprobiert.

Man sollte einfach nicht alles auf Krampf in OOP pressen.

Z.B. wie in Java, wo einfach alles eine Klasse ist. Ich finde eine gesunde Mischung wäre nicht schlecht. So könnten die Vorteile von der Funktionalen Sprache sowie von der OOP gut sich gegenseitig ergänzen.

Um mal ein Zitat von StarGate zu bringen: Wir können auf diese Eben nicht mehr Denken(welche Folge?), ich glaube das trifft auch hier zu. Leute, die nur noch mit der OOP Arbeiten, können sich Alternativen gar nicht vorstellen(Bitte nicht als Beleidigung ansehen) und verlaufen sich ohne es zu merken. Das passiert mir auch immer wieder, beim Programmieren... Wenn ich mit Arduino Arbeite, nutze baue ich mir keine eigenen Klassen, sondern nutze Fertige, da passiert es nicht ganz leicht.

[sstvmaster]

Um mal ein Zitat von StarGate zu bringen: Wir können auf diese Eben nicht mehr Denken(welche Folge?),

Folge: Nemesis Teil 2

Zitat:

Thor: "Die Asgard haben versucht, sie aufzuhalten. Ihr habt uns klar gemacht, dass ihre Schwäche durch eine weniger hoch entwickelte Methode entdeckt wurde. Wir können auf dieser Ebene nicht mehr denken."

[pluto]

Folge: Nemesis Teil 2

Scheinbar, kennt die Folge noch mehr Leute...

Thor: "Die Asgard haben versucht, sie aufzuhalten. Ihr habt uns klar gemacht, dass ihre Schwäche durch eine weniger hoch entwickelte Methode entdeckt wurde. Wir können auf dieser Ebene nicht mehr denken."

Genau, dass habe ich gemeint.

[sstvmaster]

Ich kenne vieles, z.B.: Stargate, Raumschiff Enterprise, Star Trek, Voyager, Kampfstern Galactica, Alien, Prometheus usw.