Ist die Klassische OOP gescheitert?

[m.fuchs]

Ihr könnt es nenne wie ihr wollt: Gemeinsamkeiten suchen, oder Sinnvolle Eigenschaften und Methoden suchen, wo ist da der Unterschied?

Weil nur Gemeinsamkeiten nicht ausreichen, zwei Klassen mit vielen Gemeinsamkeiten müssen nichts miteinander zu tun haben.

[kupferstecher]

Ein Beispiel:
[...]
Dann stellen wir uns mal zwei Szenarien vor, in denen du als Entwickler an diesem Quellcode arbeitest.

1.) Du möchtest jeden Zug der gemacht wird zusätzlich in eine Logdatei schreiben. Du suchst die Stelle in der CalculateNextTurn aufgerufen wird und schriebst die Daten dort weg. [...]

2.) Du möchtest dass der aggressive Computergegner sich nicht selbst komplett opfert um dem menschlichen Spieler zu schaden. Dann gehst du direkt in die Implementierung von TAggressivePlayer.CalculateNextTurn und änderst diese ab.

Gutes Beispiel! In beiden beide Szenarien musst du das Zusammenspiel zwischen der Basisklasse und der abgeleiteten Klassen bereits kennen. Wenn man vor dem Code steht ist das erstmal nicht offensichtlich. Wobei das natürlich auch mit der eigenen Erfahrung zu tun hat.

[Niesi]

Ihr könnt es nenne wie ihr wollt: Gemeinsamkeiten suchen, oder Sinnvolle Eigenschaften und Methoden suchen, wo ist da der Unterschied?
Klar geht es bei der Vererbung darum, Sachen von einer anderen Klasse zu übernehmen, davon spreche ich doch die ganze Zeit.

Wenn ich zum Beispiel ein Programm schreibe, welches Zahnräder aus Stahl und aus Kunststoff berechnen können soll, dann werde ich unter Umständen für beide jeweils eine eigene Basisklasse kreieren. Denn zwar sehen sie geometrisch gleich aus, aber die Berechnung, Herstellung und das Material sind so anders, dass eine gemeinsame Basisklasse eventuell nicht schlau wäre. (Mir fällt gerade kein besseres BEISPIEL (<- ACHTUNG, dies ist lediglich ein BEISPIEL) besseres ein, Sorry).

Du kannst, jedoch die Methoden zu Berechnung jedoch überschreiben und die Berechnungen anpassen. Wo ist das Problem?

Die Betonung beim Vererben liegt darauf, dass es SINNVOLL sein muss. Es gibt keine Gesetze, keine Regeln, keine zehn Vererbungsgebote in Tontafeln, die in irgendeiner Form vorschreiben, was ich wovon ableite ...

Klar, gibt es dabei Regeln bzw. Empfehlungen. Es gibt ein Grund Konzept. Klar kann ich es machen wie ich möchte, nur dann ist das kein guter Code.

Weil sich die Berechnung von Stahlzahnrädern grundlegend unterscheidet von der Berechnung von Kunststoffzahnrädern. Ok, der Geometrieteil KÖNNTE von einem gemeinsamen Vorfahren ererbt werden - aber das ist nicht viel. Die Anzahl der Rechenschritte ist stark unterschiedlich, es lohnt sich evtl. nicht. Wie gesagt, das ist ein BEISPIEL.

Nimm noch einmal das Beispiel aus dem Restaurant: Sicher ist, das jedes Gericht einen Preis, eine Herstellungsmethode und eine Herstellungszeit hat. Das könnte die Basisklasse liefern.

Aber dann: nicht sinnvoll wäre es, ein Erbsengemüse von einem Salat abzuleiten - Erbsengemüse wird gewaschen, gedünstet und heiß serviert. Ein Salat wird gewaschen, getrocknet und kalt serviert. Obwohl beide zum Essen sind, beide zusammen bestellt werden können, würde ich sie nicht voneinander ableiten.

Genauso der Kreis und die Ellipse: der Kreis hat weniger Eigenschaften, daher würde ich - wenn überhaupt - die Ellipse vom Kreis ableiten und die Eigenschaften, die sie mehr hat, dann hinzufügen. Alternativ können sie auch nebeneinander stehen, also jeweils von einem tGraphObject abgeleitet sein. Das liegt ganz und gar bei den Programmierenden, nur die selbst haben das zu entscheiden. Und es nimmt ihnen auch niemand ab ...

[m.fuchs]

Gutes Beispiel! In beiden beide Szenarien musst du das Zusammenspiel zwischen der Basisklasse und der abgeleiteten Klassen bereits kennen. Wenn man vor dem Code steht ist das erstmal nicht offensichtlich.

Genau, deshalb: gute Architektur, gute Architekturbeschreibung, vernünftige Benennung der Klassen. Ohne die ist man immer aufgeschmissen.

[Niesi]

Und wenn ich eine neue Technologie verwenden will/muss, dann bastele ich mir ersteinmal ein Testprojekt um das Ding ansatzweise zu verstehen. Probier es mal mit diesem Weg.

Empfehlenswerte Methode. Mache ich auch so.

Ich bin jetzt sogar so weit, dass ich in meinem Projekt eine tForm "mitlaufen" lasse, in der ich Sachen testen kann und die ich zur Informationsausgabe nutzen kann.

[pluto]

Ich schaue mal in meine Glaskugel und vermute, dass deine Projektarchitektur eher suboptimal ist.

Ich habe wohl die eine oder andere Antwort übersehen: Das sowas kommt war mir klar. Das ist aber zu eine einfachere Sichtweise.

Stellen wir uns eine Komponentenstruktur vor.
Es gibt Grund Klassen, wie TPLComponent, TPLVisuallComponent, TPLLabel.
Nun möchte ich eine Unit haben, die sich uplGUI nennt, wo die ganzen Basis Sachen drin sind. Dann möchte ich einzelne Klassen pro Unit hat.
Dieser Ansatz hat gewisse Nachteile. So sind die Komponenten aber schön Strukturiert.
Soweit ist das ganze auch kein Problem, aber wenn sich die Klassen in den Verschiedenen Units sich gegenseitig brauchen, kommt das Problem mit den Units.

Nimm es mir nicht übel, aber ich glaube sehr dass das dein Problem ist. Du fängst etwas sehr komplexes an und das ohne Planung.

Am Anfang habe ich das auch gemacht, inzwischen fange ich erst an, wenn ich ein Plan habe.

Ich versuche bei jedem Projekt ab einer gewissen Größe mich mit anderen Entwicklern darüber auszutauschen. Und nach so einem Gespräch schmeiße ich mein erstes Konzept weg und mache ein Neues. Weil immer, und zwar wirklich immer durch so eine Diskussion neue Probleme auftauchen, die ich nicht auf dem Schirm habe.

Diesen Austausch habe ich bisher noch nicht.

Und wenn ich eine neue Technologie verwenden will/muss, dann bastele ich mir ersteinmal ein Testprojekt um das Ding ansatzweise zu verstehen. Probier es mal mit diesem Weg.

Genau. Ich fange eine reihe von Test Projekten an um ein Konzept oder eine Idee auszuprobieren.

Weil nur Gemeinsamkeiten nicht ausreichen, zwei Klassen mit vielen Gemeinsamkeiten müssen nichts miteinander zu tun haben.

Das meine ich auch gar nicht. Ich meine, wenn man eine Klassenstruktur hat und innerhalb dieser Klassenstruktur haben die Klassen was gemeinsam.
KlasseA und KlassB können ähnliche Eigenschaften haben und doch unterschiedlich sein. Auch wenn ich kein Beispiel im Moment habe.

Aber dann: nicht sinnvoll wäre es, ein Erbsengemüse von einem Salat abzuleiten - Erbsengemüse wird gewaschen, gedünstet und heiß serviert. Ein Salat wird gewaschen, getrocknet und kalt serviert. Obwohl beide zum Essen sind, beide zusammen bestellt werden können, würde ich sie nicht voneinander ableiten.

Das ist klar. Das würde auch wohl keiner machen.
Jedoch könnten Erbsengemüse und Salat eine Gemeinsame Basis Klasse haben.

Ich bin jetzt sogar so weit, dass ich in meinem Projekt eine tForm "mitlaufen" lasse, in der ich Sachen testen kann und die ich zur Informationsausgabe nutzen kann.

Die meisten Projekte, die ich Anfange haben in der Regel keine Grafische Oberfläche, sondern ich nutzte die Textbasierte Ausgabe.

[pluto]

Mir ist da noch eine Idee gekommen, eben:
Ich könnte ein "Konzept" Ausarbeiten zu einer Editor Komponente, dieses Konzept habe ich schon öfter umgesetzt bin aber immer wieder an gewissen stellen "gescheitert".

Das Konzept Entstand aus einer "kurzen" zusammenarbeit mit einem anderen Entwickler. Ich darf dieses Konzept jedoch weiter "nutzen" und habe es auch stark geändert.
Die Grund Idee löst bereits viele Probleme, die meine Vorherigen Konzepte hatten, aber sie schafft auch neue. Das Hauptproblem dabei ist immer wieder die Vererbung von Stylen.
Ich orientiere mich stark an HTML und CSS. Übernehme aber nicht alles. Von CSS werde ich ca 30 bis 40 Eigenschaften übernehmen. Für den "Anfang".

In den "letzten Jahren", hatte ich den Ansatz geändert und wollte erst mal eine RenderEngine haben, die ich dann für mein Editor nutzen kann. Inzwischen bin ich zu der Überzeugung gekommen, ich sollte mich gleich auf eine Editor Komponente Konzentrieren, wäre Sinnvoller.

Die Idee ist, ihr schaut euch dieses Konzept an und beurteilt es und bringt vielleicht eigene Idee ein. Vielleicht wäre sogar eine art "Zusammenarbeit" vorstellbar.

Das Konzept ist nicht einfach. Es wird kein Zeitplan geben. Jeder der eine Meinung dazu hat oder gar mit machen möchte kann das dann tun.
Auch, wenn jemand nur eine kleine Idee hat, kann dies vielleicht schon viel aus machen.

Auch wenn jemand "keine oder nur wenig zeit hat". Seit 2007 Arbeite ich an der Idee.... und das Konzept hat sich inzwischen gefestigt.
Dazu mache ich dann ein neuen Thread auf.

Ich denke, so kann ich "Zeigen", dass ich die OOP durchaus verstanden habe. Ich kenne zwar nicht alle "Fachbegriffe" oder gar alle Hintergründe oder Konzepte. Ich verwende die OOP jedoch und habe verschiedene Dinge bereits ausprobiert... Oft verwende ich auch Ideen, die sogar ein Namen haben, die ich nicht kenne.