"to MI or not to MI"

[Shade Of Mine]

So.

Habe heute weiter rumprobiert.
Aber es funktioniert nicht. Ich stoße konstant auf Ärgerlichkeiten. Zu dem Problem ob ein Auto ein Motor ist oder einen hat, komme ich nichtmal.

Ich habe folgende Probleme mit dem Ansatz:

Keine Information Hiding. Jedes Implementierungsdetail ist öffentlich, was nachträgliche Änderungen sehr schwer macht. Denn jedes Implementierungsdetail steht ja im Typen drin

Programmierung gegen Implementationen und nicht gegen Interfaces. Ich kann einen Typen nicht einfach austauschen. Wenn ich zB feststelle, dass vector kein guter Typ ist, kann ich nicht list stattdessen verwenden ohne das an jeder Stelle im Code auszubessern. Da ich ja immer Vector::add() schreibe...

Massig Codeverdopplung. Das kann natürlich an C++ liegen, aber da ich keine Interfaces habe die ich nutzen kann und keine Information verstecken kann, muss ich viel Code doppelt schreiben.

Codeänderungen brechen enorm viel Code. Ich führe zB einen neuen Vater ein, und schon habe ich dessen Scope geerbt. Das macht in C++ riesen Probleme und man benutzt dauernd ::Integer statt Integer. Das würde eine bessere Sprache natürlich lösen.

Änderungen einer Entitity können andere Entities kaputt machen. Indem ich in einem Vater eine neue Funktion einführe, kann ich damit Clientcode brechen.

Es entstehen unheimlich viele Typen. Man muss konstant neue Typen erstellen um vernünftige Namen zu haben. Wenn ich
int alter;
sagen will, dann muss ich von Integer eine Klasse Alter erben und von dieser Erbe ich dann um mein "int alter;" zu bekommen. Ich habe also massig nur einmal verwendete Typen die den Namensraum beschmutzen. Da braucht man ein Sprachfeature ala "Person : public Integer as Alter" oder so.

Invarianten sind nur schwer garantierbar, da eine Entity nicht in sich geschlossen ist. Ich ertappe mich immer dabei geschlossene Entitäten zu schreiben - die dadurch aber nichtmehr die Vererbung erlauben um die es geht. Diesen Punkt kann man aber uU lösen wenn man eine bessere Sprache hat.

Invarianten würden sich ganz gut garantieren lassen, wenn wir access specifier des Vaters im Kind ändern könnten. Mir ist nur nicht klar wie man sowas implementieren könnte.

Es entstehen sehr komische Verwandschaften zwischen Typen die eigentlich nicht beabsichtig sind. Das ist manchmal ganz witzig, aber manchmal einfach nur "wierd".

Es fehlen Verwandschaften die eigentlich ganz praktisch wären. Da wir keine Interfaces haben gegen die wir implementieren, sind prinzipiell sehr ähnliche Typen oft garnicht miteinander verwandt. Das könnte man durch Java Interfaces wieder ausbessern, in C++ müsste man aber Templates nehmen und die funktionieren nicht, da sie sich nicht die richtigen Eltern aus dem Typ rausziehen können.

Templates verlieren ihre Coolness. wie im vorherigen Punkt beschrieben: Templates können sich nicht den korrekten Vater aus dem Kind herausziehen. Und wenn sie das nicht können, ist das Kind nutzlos für sie - da sie die Typ-specifier nicht hinzufügen können bei einem Zugriff.

Alles in allem funktioniert der Ansatz in C++ nicht. Und um ehrlich zu sein, er funktioniert in keiner mir bekannten Sprache. Man verletzt fast konstant essentielle Guidelines wie Open Closed Principle, Liskov Substitute Principle, Program against Interfaces not Implementations, Information Hiding, Encapsulation,... Ich weiß nicht ob das eine gute Idee ist.

Wenn man so radikal anders programmieren will, müsste man wohl von OOP weg. Aber ich meine Metasprachen gibt es ja schon. In JavaScript schreibt man sich idR Funktionen die dann Klassen erstellen die man dann instanziiert. dh ich kann mir gekapselte Komponenten schreiben und die dann beim erstellen einer Klasse darauf anwenden.

Ich sehe schon was der Hintergedanke von dir ist: Ich importiere mir die Komponenten die ich brauche und muss mich nicht mit der Implementierung beschäftigen. Ich sage einfach Auto holt sich alles von Motor was es braucht. Aber irgendwie ist da Vererbung die falsche Formulierung. In JavaScript würde ich folgendes schreiben:

var Auto = {};
Motor.applyTo(Auto);

var mercedes = new Auto();
mercedes.volltanken();

Wobei Motor hier sowohl private als auch public Felder in Auto hinzufügen kann und natürlich auch für Auto unsichtbare Felder.

[SideWinder]

Danke Shade, wobei du natürlich Zeit investiert hast die viele andere Personen auch schon investiert haben und die man Xin auch zusammensammeln hätte lassen können Aber, man kann sich wohl alles zusammensuchen was hier gefragt wird, dementsprechend

MfG SideWinder

[Antoras]

knivil schrieb:

Ich verstehe immer noch nicht, welches Problem geloest warden soll.

Ich bin auch ausgestiegen. Geht es noch immer darum, dass man anstelle von

auto.tank.volltanken()

einfach nur

auto.volltanken()

schreiben kann?