Ist die Klassische OOP gescheitert?

[pluto]

Das ist doch ein uralter Hut. Leite ich von Rechteck oder von Quadrat ab? Oder von was ganz anderem?

Genau, dass ist teil des Problems... sagen wir du hast eine Basis Klasse...

Das ist aber kein Problem der OOP, sondern einer Problem der Anforderungsanalyse.

Das ist auch gut.... Man muss einfach nur das Problem ändern und schon ist es keins mehr.... Praktisch...

Erstens ist auch die Vererbung nicht gescheitert. Zweitens ist OOP nicht nur Vererbung.

Aha... Gut, bei der OOP kann man natürlich Eigenschaften/Felder definieren um ein Objekt zu beschreiben.
Dann könnte ich aber auch gleich records nehmen. Es gibt natürlich auch noch Sichtbarkeitsregeln wie public...

Ich finde es nicht gut, dass du hier so kategorisch das Scheitern von OOP propagierst. Das ist einfach weit entfernt von der Realität.

Mag sein, dass es weit von der Realität ist, aber ich wollte es hier nur mal zu Diskussion stellen. Bisher haben ja nur ein paar Leute drauf geantwortet...

Ich gebe aber zu, ich bin überrascht, dass ich zum Thema im Internet bisher wenig finden konnte... Nur ein paar Treffer, jedenfalls auf den Deutschten seiten.
Vielleicht hat sich das, noch nicht durch gesetzt oder warum auch immer.....

Scheinbar hat es auch noch keiner von euch gehört/gelesen oder was auch immer...

[m.fuchs]

Das ist doch ein uralter Hut. Leite ich von Rechteck oder von Quadrat ab? Oder von was ganz anderem?

Genau, dass ist teil des Problems... sagen wir du hast eine Basis Klasse...

Ja, und weiter?

Das ist aber kein Problem der OOP, sondern einer Problem der Anforderungsanalyse.

Das ist auch gut.... Man muss einfach nur das Problem ändern und schon ist es keins mehr.... Praktisch...

Nein, da hast du mich falsch verstanden. Ich verlagere das Problem nicht, sondern ich mache eine vernünftige Anforderungsanalyse.
Dann weiß ich auch wie ich die Klassen und die Vererbung baue. Oder ob ich Alternativen zur Vererbung nehme.

Erstens ist auch die Vererbung nicht gescheitert. Zweitens ist OOP nicht nur Vererbung.

Aha... Gut, bei der OOP kann man natürlich Eigenschaften/Felder definieren um ein Objekt zu beschreiben.
Dann könnte ich aber auch gleich records nehmen. Es gibt natürlich auch noch Sichtbarkeitsregeln wie public...

Nein, Records enthalten nur Daten, bei OOP kommt auch noch Verhalten dazu. Das ist das was OOP ausmacht.

Ich gebe aber zu, ich bin überrascht, dass ich zum Thema im Internet bisher wenig finden konnte... Nur ein paar Treffer, jedenfalls auf den Deutschten seiten.
Vielleicht hat sich das, noch nicht durch gesetzt oder warum auch immer.....
Scheinbar hat es auch noch keiner von euch gehört/gelesen oder was auch immer...

Aus dem gleichen Grund, warum man nicht viel zum praktischen Einsatz der kalten Kernfusion findet.

Es mag ja sein, das vereinzelt Leute das Ende von OOP beschwören. Aber das sind dann halt (unbegründete) Einzelmeinungen.

[pluto]

Ja, und weiter?

Wie weiter?
Sagen wir, wir haben als Basis Klasse mit den Namen TFigure
Davon leiten wir jetzt Quadrat und Rechteck ab...
Wie sehen die Felder aus, die gemeinsam sind?
ein Quadrat braucht ja jetzt keine breite und höhe... wie beim Rechteck....

Nein, Records enthalten nur Daten, bei OOP kommt auch noch Verhalten dazu. Das ist das was OOP ausmacht.

Records können auch teile vom OOP Konzept übernehmen, soweit ich weiß...

Aus dem gleichen Grund, warum man nicht viel zum praktischen Einsatz der kalten Kernfusion findet.

Vielleicht findet man da, sogar noch mehr Seiten im Internet...

Es mag ja sein, das vereinzelt Leute das Ende von OOP beschwören. Aber das sind dann halt (unbegründete) Einzelmeinungen.

Hier hast du mich falsch verstanden: Ich habe "behauptet" das, dass Konzept der OOP gescheitert ist, aber das ist nicht mit einem Ende der OOP gleich zu setzten...
Es wird nur in einer anderen Form weiter geführt. In einer "weiter" entwickelten form... wenn du so möchtest...
Und in dieser neuen Form, gilt das Konzept vom Vererbung als Gescheitert, weil es unnötig die Struktur Unübersichtlicher macht...

Viele habe ja auch das ende von der Zeitung vorhergesagt, als das Internet kam.... Die Form hat sich nur verlagert... Zeitungen wird es immer geben, nur eben immer weniger Print Medien....
Oder auch das Klassische Fernsehn hat sich verlagert...

[m.fuchs]

Ja, und weiter?

Wie weiter?
Sagen wir, wir haben als Basis Klasse mit den Namen TFigure
Davon leiten wir jetzt Quadrat und Rechteck ab...
Wie sehen die Felder aus, die gemeinsam sind?
ein Quadrat braucht ja jetzt keine breite und höhe... wie beim Rechteck....

Und schon sind wir jetzt genau bei dem Problem der Anforderungsanalyse. Die Beschreibung ist praktisch wertlos und die Frage nach den Feldern kann nicht beantwortet werden.

Was ist denn das eigentliche praktische Problem? Niemand hat einfach nur eine Basisklasse und leitet davon ab. Jeder will damit ja irgendetwas bezwecken.

Nein, Records enthalten nur Daten, bei OOP kommt auch noch Verhalten dazu. Das ist das was OOP ausmacht.

Records können auch teile vom OOP Konzept übernehmen, soweit ich weiß...

Du spielst vermutlich auf die Advanced Records an. Warum auch immer die erfunden worden: sie sind nicht nur Records sondern Klassen/Objekte.

Es mag ja sein, das vereinzelt Leute das Ende von OOP beschwören. Aber das sind dann halt (unbegründete) Einzelmeinungen.

Hier hast du mich falsch verstanden: Ich habe "behauptet" das, dass Konzept der OOP gescheitert ist, aber das ist nicht mit einem Ende der OOP gleich zu setzten...

Dann solltest du vielleicht noch einmal einen Schritt zurückgehen und dir überlegen, was du eigentlich kommunizieren möchtest? Willst du über Schwierigkeiten beim Einsatz von OOP sprechen?
Ich weiß inzwischen nicht mehr, was dein eigentlicher Diskussionspunkt ist. Bisher ist angekommen: OOP ist gescheitert. Warum und wieso? Und das war es.

[pluto]

Und schon sind wir jetzt genau bei dem Problem der Anforderungsanalyse. Die Beschreibung ist praktisch wertlos und die Frage nach den Feldern kann nicht beantwortet werden.

Was ist denn das eigentliche praktische Problem. Niemand hat einfach nur eine Basisklasse und leitet davon ab. Jeder will damit ja irgendetwas bezwecken.

Der Fall sollte klar sein.... Es geht erst mal nur um die Breite und Höhe...
Dann mach ein eigenes Beispiel....

Du spielst vermutlich auf die Advanced Records an. Warum auch immer die erfunden worden: sie sind nicht nur Records sondern Klassen/Objekte.

Genau... Vielleicht war das eine vor gänger Version von Klassen und Objekten.

Dann solltest du vielleicht noch einmal einen Schritt zurückgehen und dir überlegen, was du eigentlich kommunizieren möchtest? Willst du über Schwierigkeiten beim Einsatz von OOP sprechen?
Ich weiß inzwischen nicht mehr, was dein eigentlicher Diskussionspunkt ist. Bisher ist angekommen: OOP ist gescheitert. Warum und wieso? Und das war es.

Gut, ich kann dir auf die Sprünge helfen: Der Kern ist:
Das OOP Konzept gilt als gescheitert nun kommt das weil

Das OOP Konzept gilt als gescheitert, weil das mit der Vererbung selten eine Gute Idee ist, weil dadurch wird die Klassen Strukturen sehr schnell sehr umfangreich.
Wie zum Beispiel, mein GUI Projekt mit den 4 bis 5 Klassen pro Komponente... oder nimmt schaut auch die VCL/LCL an...
Ich kann auch gut als Beispiel meine Versuche mit dem eigenen Rich Text Editor nennen... Da hatte ich eine sehr umfangreiche Klassenstruktur, von der ich aber inzwischen überzeugt bin, dass es gerechtfertigt ist... Die letzten Projekte in dieser Richtung waren im Prinzip nichts anders als HTML&CSS Code zu Pasen und zu Rendern...
Vielleicht ist das Konzept von Anfang an Fehlerhaft gewesen und darum habe ich schnell die Übersicht verloren...
Könnte ich jetzt einfach Methoden einer Klasse hinzufügen, wären deutlich weniger Klassen Notwendig... Aber es gibt mehr Methoden auf der anderen Seite...

Wenn ich von TCustomControll erbe, erbe ich sehr viele Sachen, die vielleicht nicht alle benötigt werden... Als Beispiel kann ich das TLabel nennen:
Beim TLabel werden die Events vom TCustomControll mit geerbt... Events, die im Prinzip selten Verwendet werden wie z.b. onClick oder onMouseDown und der gleichen.
Klar kommt das von der VCL(von Delphi), aber geht das nicht auch Effektiver?
Das Label soll jetzt einfach nur ein Text Anzeigen.... hat aber eine ganze reihe von events, die selten oder gar nicht verwendet werden....

[Timm Thaler]

Das Label soll jetzt einfach nur ein Text Anzeigen.... hat aber eine ganze reihe von events, die selten oder gar nicht verwendet werden....

Und ist das schlimm? Ich muss die doch nicht nutzen...

Ein Problem dürfte sein, dass man möglichst universell sein will. Am Beispiel TLabel: Einige OS haben da ein OnClick Ereignis, andere nicht, oder führen es in der Zukunft ein, und da will man flexibel bleiben.

[Timm Thaler]

"C++ Bibliotheken die wild Speicher erzeugen und ich keinerlei Zugriff darauf habe"

So eine Lib brauche ich für den Raspi. Die darf dann gern ein oder zwei GB RAM zusätzlich erzeugen. Geht das auch unter Pascal? Und ich bräuchte dann schon auch Zugriff auf den Speicher.

[Warf]

OOP ist nicht gescheitert, sondern gilt nur als falsch verstanden. Der entwickler von Smalltalk hat mal gesagt das er allein den Namen OOP bereut, denn es geht eigentlich nicht um Objekte, Vereerbung, etc. das sind nur Nebenprodukte, sondern es geht um Nachrichtenaustausch.

Er war vorher Biologe (bzw. ist es noch, ich glaub man hört nicht einfach so auf Biologe zu sein) und versteht OOP als eine art eins zu eins übersetzung von Zellen in die Programmierwelt. Ein Objekt ist eine Abgeschlossene Zelle die mit anderen Zellen über Methoden und Events kommunizieren soll. Dabei sollen Zellen(objekte) sich problemlos weiter entwickeln können (ohne das dabei das alter Interface zerstört wird, dafür gibts vereerbung und interfaces) oder sogar absterben können (also das einfach entfernen von Objekten aus dem Projekt).
Leider ist das so nie bei den Programmierern angekommen, für die meisten liegt der Fokus dabei auf den Objekten und Vereerbung ist lediglich ein Tool um Code nicht doppelt schreiben zu müssen. Was dann genau die Problematik bietet das kleine änderungen in der Basisklasse die vereerbten klassen zerschießen kann. Man muss seine Klassen ableitung so designen das man theoretisch eine komplette klasse aus der Hirarchie austauschen kann ohne das das Programm zusammen fällt, das machen viele entwickler aber einfach nicht.

Daher gehen viele neue Programmiersprachen das Thema OOP ganz anders an. Go z.B. legt den Fokus sehr stark auf Interfaces, ich weiß gar nicht ob es normale Klassenvereerbung überhaupt gibt. Javascripts OOP (ich würde es als absoluten Müll bezeichnen aber andere stehen drauf) kommt ganz ohne klassen aus, sondern die Objekte können zur Laufzeit erzeugt und verändert werden:

Code: Alles auswählen

function Foo() { this.name = "Foo"; }
Foo.prototype.bar = function () { this.name += "Bar"; } // füge neue methode hinzu
var foo = new Foo();
foo.bar();
console.log(foo.name); // printed FooBar

Ich bin aber der Meinung, es ist nicht OOP das gescheitert ist, es sind die entwickler die einfach ihre Software schlecht designed haben. Im großen Enterprise bereich, in dem es eigene Teams von Software Entwicklern gibt die sich nur damit beschäftigen sich ein gutes OOP design zu überlegen, funktioniert es ja wunderbar, bzw. würde es ohne OOP komplett gegen die wand fahren.

So sehr ich auch ein verfechter der künstlerischen Programmierung bin (also ohne groß nachdenken einfach mal loslegen und schauen wo es einen hinbringt), sobald die Projekte größer werden lohnt es sich doch mal sich die Woche zeit zu nehmen und mal mit UML Diagrammen alles von vorne bis hinten durchzuplanen

[pluto]

Und ist das schlimm? Ich muss die doch nicht nutzen...

sagen wir, es ist Speicher Verschwendung...

Ein Problem dürfte sein, dass man möglichst universell sein will. Am Beispiel TLabel: Einige OS haben da ein OnClick Ereignis, andere nicht, oder führen es in der Zukunft ein, und da will man flexibel bleiben.

Klar, dass führt dann zu mehr Speicher Verbrauch...

OOP ist nicht gescheitert, sondern gilt nur als falsch verstanden. Der entwickler von Smalltalk hat mal gesagt das er allein den Namen OOP bereut, denn es geht eigentlich nicht um Objekte, Vereerbung, etc. das sind nur Nebenprodukte, sondern es geht um Nachrichtenaustausch.

Nachrichtenaustausch... Ich dachte immer es geht um Struktur... Ich habe jetzt ein Problem und das möchte ich möglich gut strukturieren...

Ein Objekt ist eine Abgeschlossene Zelle die mit anderen Zellen über Methoden und Events kommunizieren soll. Dabei sollen Zellen(objekte) sich problemlos weiter entwickeln können (ohne das dabei das alter Interface zerstört wird, dafür gibts vereerbung und interfaces) oder sogar absterben können (also das einfach entfernen von Objekten aus dem Projekt).

Ist ja Interessant.. Daher kommt die OOP?

Was dann genau die Problematik bietet das kleine änderungen in der Basisklasse die vereerbten klassen zerschießen kann.

Richtig, oder das Konzept durcheinander bringen kann... weil dann alles angepasst werden muss...
Z.B. ich füge ein Parameter in einer Methode hinzu, die überall überladen wird...

Man muss seine Klassen ableitung so designen das man theoretisch eine komplette klasse aus der Hirarchie austauschen kann ohne das das Programm zusammen fällt, das machen viele entwickler aber einfach nicht.

Stelle ich mir auch Problematisch vor... wie soll das im Einzelfall gehen?
Nehmen wir als Beispiel wenn möglich eine GUI

Javascripts OOP (ich würde es als absoluten Müll bezeichnen aber andere stehen drauf) kommt ganz ohne klassen aus, sondern die Objekte können zur Laufzeit erzeugt und verändert werden:

JavaScript hat ja keine OOP sondern, Protype oder so ähnlich...

Ich bin aber der Meinung, es ist nicht OOP das gescheitert ist,

Ich glaube das ist die erste wirklich sachkundige Meinung zum Thema in diesem Thread... bitte korrigiert mich wenn ich Falsche liege...

Im großen Enterprise bereich, in dem es eigene Teams von Software Entwicklern gibt die sich nur damit beschäftigen sich ein gutes OOP design zu überlegen, funktioniert es ja wunderbar, bzw. würde es ohne OOP komplett gegen die wand fahren.

Andere sagen wieder, dass OOP in Firmen bereits verboten wurde bzw. nicht verwendet wird....
Ich finde die OOP in sehr vielen Punkte recht gut, nur halt das mit der Vererbung ist so eine Sache...
Zum beispiel Java erlaubt Mehrfach Vererbung, in anderen Sprachen gilt das als Schlechter Programmierstile....

Oder wenn ich irgendwo ein Variable mit einem Datentyp habe und möchte bei dieser Variable den Datentyp in einer weiteren Klasse ändern... das geht, ist aber nicht so toll...

sobald die Projekte größer werden lohnt es sich doch mal sich die Woche zeit zu nehmen und mal mit UML Diagrammen alles von vorne bis hinten durchzuplanen

Ich mache mir in der Regel vorher "Grobe" Gedanken und schreibe sie mir mit einem Text Editor auf.... weil beim Programmieren kann man das eine oder andere schnell "vergessen"...
meisten erstelle ich mir eine reihe von Prototypen, dann weiß ich genau wo hin die "reise" geht... inzwischen bin ich sogar dazu übergangen und sage: dann mache ich das eine bestimmte zeit und erwarte das ich das in der Zeit dann auch schaffe, was auch gut Funktioniert....

Eine art Grober Zeitplan hilft natürlich auch, damit man sich nicht verzettelt...

[m.fuchs]

Und schon sind wir jetzt genau bei dem Problem der Anforderungsanalyse. Die Beschreibung ist praktisch wertlos und die Frage nach den Feldern kann nicht beantwortet werden.
Was ist denn das eigentliche praktische Problem. Niemand hat einfach nur eine Basisklasse und leitet davon ab. Jeder will damit ja irgendetwas bezwecken.

Der Fall sollte klar sein.... Es geht erst mal nur um die Breite und Höhe...

Das ist immer noch kein praktisches Beispiel, sondern nur die Beschreibung von ein paar Properties. Was wäre denn die konkrete Aufgabestellung?

Dann mach ein eigenes Beispiel....

Nehmen wir mal an, ich habe eine Funktion in die ich ein beliebiges geometrische Gebilde geben möchte. Diese Funktion benötigt wiederum Umfang und Flächeninhalt dieses Gebildes.

Dann baue ich mir ein TGeometrischesGebilde mit den beiden abstrakten Funktionen BerechneUmfang und BerechneFlaeche. Dann leite ich fröhlich alle meine Gebilde von dieser Basisklasse ab.
Und die erhalten dann notwendige Eigenschaften (TRechteck bekommt zwei Seiten, TQuadrat nur eine, TKreis hat einen Radius) und implementieren alle diese beiden Funktionen. Voilà: OOP.

Du spielst vermutlich auf die Advanced Records an. Warum auch immer die erfunden worden: sie sind nicht nur Records sondern Klassen/Objekte.

Genau... Vielleicht war das eine vor gänger Version von Klassen und Objekten.

Nein, das gibt es erst recht neu. Wie gesagt: wozu weiß ich nicht.

Das OOP Konzept gilt als gescheitert, weil das mit der Vererbung selten eine Gute Idee ist, weil dadurch wird die Klassen Strukturen sehr schnell sehr umfangreich.

Nicht unbedingt: in meinem obigen Beispiel gibt es eine Klasse mehr (die Elternklasse). Dafür benötige ich aber nur eine Funktion die mit der Elternklasse arbeitet und nicht eine für jedes geometrische Gebilde.
Ich spare also viel Quellcode ein.

Wie zum Beispiel, mein GUI Projekt mit den 4 bis 5 Klassen pro Komponente... oder nimmt schaut auch die VCL/LCL an...

Einspruch. Hast du denn eine Alternative die nicht OOP ist und übersichtlicher? Und vor allen Dingen ohne Code-Dopplung. Die Komplexität der LCL hängt mit der hohen Masse an Funktionalität zusammen.

Ich kann auch gut als Beispiel meine Versuche mit dem eigenen Rich Text Editor nennen... Da hatte ich eine sehr umfangreiche Klassenstruktur, von der ich aber inzwischen überzeugt bin, dass es gerechtfertigt ist...

Ja, aber vielleicht hast du aus anderen Gründen den Überblick verloren. Wie hast du die Anforderungen erstellt? Wie die Architektur? Wie war dein Projektmanagement?

Wenn ich von TCustomControll erbe, erbe ich sehr viele Sachen, die vielleicht nicht alle benötigt werden... Als Beispiel kann ich das TLabel nennen:
Beim TLabel werden die Events vom TCustomControll mit geerbt... Events, die im Prinzip selten Verwendet werden wie z.b. onClick oder onMouseDown und der gleichen.
Klar kommt das von der VCL(von Delphi), aber geht das nicht auch Effektiver?
Das Label soll jetzt einfach nur ein Text Anzeigen.... hat aber eine ganze reihe von events, die selten oder gar nicht verwendet werden....

Das ist aber nur deine persönliche Sichtweise. Ich benötigt onClick im Label schon häufiger.
So ein großes Framework ist sicherlich erst einmal gewöhnungsbedürftig. Aber es deckt auch echt sehr viel ab.

[m.fuchs]

Ich bin aber der Meinung, es ist nicht OOP das gescheitert ist, es sind die entwickler die einfach ihre Software schlecht designed haben.

Exakt das ist das Problem!

So sehr ich auch ein verfechter der künstlerischen Programmierung bin (also ohne groß nachdenken einfach mal loslegen und schauen wo es einen hinbringt), sobald die Projekte größer werden lohnt es sich doch mal sich die Woche zeit zu nehmen und mal mit UML Diagrammen alles von vorne bis hinten durchzuplanen

Genau, vor dem Programmieren etwas Nachdenken, erspart einem hinterher viel unnütze Arbeit.

[af0815]

Ich sage mal ganz frei heraus.

Vererbung (OOP) ja, aber nur soviel wie nötig/sinnvoll. Die Objekte selbst sollten mittel Interfaces kommunizieren damit sind diese Schnittstellen auch leichter Austauschbarer und auch Testbar. Vor allen hat eine Änderung in einem Objekt keine Auswirkung auf ein anderes Objekt. Wenn ich also jetzt ein OOP-Objekt ändere und an der Schnittstelle bleibt (Testbar) alles gleich, so wird kein anderes Objekt davon betroffen sein. Hängt alles mit OOP zusammen so sind die Auswirkungen meistens nicht überschaubar, weil man ja nicht unbedingt daran denkt was in einer vererbten Kindklasse passiert.

my 2 cent

[m.fuchs]

Und ist das schlimm? Ich muss die doch nicht nutzen...

sagen wir, es ist Speicher Verschwendung...

Du kannst auch einfach alles von Hand machen, eigene Objekte erstellen die nur die von dir nötigen Methoden haben. Oder einfach direkt nur auf den Bildschirm zeichnen.
Oder du nimmst gleich Assembler und fängst ganz unten an. Das ist bestimmt am ressourcenschonendsten. Aber es ist halt unglaublich viel Aufwand. Da ist ein fertiges Framework doch deutlich einfacher.

Nachrichtenaustausch... Ich dachte immer es geht um Struktur... Ich habe jetzt ein Problem und das möchte ich möglich gut strukturieren...

Und das macht man beispielsweise in dem man Objekte hat, die miteinander kommunizieren, also Nachrichten austauschen.

Ich glaube das ist die erste wirklich sachkundige Meinung zum Thema in diesem Thread... bitte korrigiert mich wenn ich Falsche liege...

Hm, das kommt jetzt bei mir nicht so gut an.

Andere sagen wieder, dass OOP in Firmen bereits verboten wurde bzw. nicht verwendet wird....

Es gibt sogar Firmen, die rein prozedural entwickeln. Oder eben auch nur mit Assembler. Das sagt doch aber nix aus.

Ich finde die OOP in sehr vielen Punkte recht gut, nur halt das mit der Vererbung ist so eine Sache...

Wenn sie dich stört, dann lass sie doch weg.

Oder wenn ich irgendwo ein Variable mit einem Datentyp habe und möchte bei dieser Variable den Datentyp in einer weiteren Klasse ändern... das geht, ist aber nicht so toll...

Das geht ganz gut mit generischen Klassen, aber hast du doch nicht letztens beschwert dass du die nicht nutzen willst?

[m.fuchs]

Wenn ich also jetzt ein OOP-Objekt ändere und an der Schnittstelle bleibt (Testbar) alles gleich, so wird kein anderes Objekt davon betroffen sein. Hängt alles mit OOP zusammen so sind die Auswirkungen meistens nicht überschaubar, weil man ja nicht unbedingt daran denkt was in einer vererbten Kindklasse passiert.

Da gibt es drei Dinge die das verhindern können: Unittests, Unittests, Unittests.

[af0815]

Da gibt es drei Dinge die das verhindern können: Unittests, Unittests, Unittests.

Das gilt für alles, nicht nur für OOP