>>154246Nein, damit hat das leider nichts zu tun.
>>154249>Vererbung hat immer noch nichts mit Arrays zu tun.
Das Gegenteil ist der Fall: Drösel das mit den Subtypen und den Arrays doch mal auf.
>Warum glauben Leute nur, dass sie Vererbung bräuchten? Man kann doch auch einfach bei jeder.png Änderung alle.jpg Verwendungen bei allen.jpg Benutzern anpassen. Es ist so ein Fach!
In der Tat ist es so einfach:
Die Sache der Änderungen ist mit Kapselung gegessen. Wow, jede der 1 Änderungen, wie soll man sich von so viel Arbeit erholen?
Die Sache mit _neuen_ Klassen ist dank Compiler-Warnung gegessen.
Wobei Kapselung auch schon wieder spukig ist, und dann die "Experten" kommen, was "echte" Kapselung sei. Man könnte auch ganz unspukig sagen: Man schreibt ein paar Funktionen (wau).
>Oder man möchte einfach das Verhalten eines Objekts befristet anpassen, ohne dabei jedes Mal durch die gesamte Kotbasis dackeln zu müssen.
Du passt dann die Funktionalität an der Stelle an, an der die Funktionalität implementiert ist.
Pro-Tipp: Du benennst einfach den Typ um.
>Oder
Oder man will schnell einen Überblick über diese Funktionalität bei allen Klassen haben.
Oder man möchte eine Funktionalität von mehreren Klassen anpassen, ohne an mehrere Stellen der Kotbasis dackeln zu müssen.
Oder man möchte den Klassen eine neue, unterschiedliche Funktionalität hinzufügen, ohne dabei jedes Mal zu drölf Kotstellen zu gehen.
Oder man möchte gleiche Funktionalität erst gar nicht über mehrere Klassen hinweg sprotzeln. Zu welcher Klasse soll das dann gerade noch mal gehören?
Dass ist alles meilenweit davon entfernt, dass man Vererbung bräuchte, weil, wenn man schaut, was Vererbung in der Implementierung eigentlich ist, Vererbung am Ende als alleiniges Alleinstellungsmerkmal eine einfache Generierung/Aufruf von einer Virtuellen-Funktionszeiger-Tabelle bringt. Alles andere geht trivial ohne Vererbung, insbesondere, wo die Funktionalität liegt. Und insbesondere geht auch alles aus deiner Auflistung ohne Vererbung. Nur hat man dann die Freiheit, es auch anders zu organisieren, oder es gleich zu organisieren. Wegen letzterem ist an dem Punkt argumentativ dann Ende.
Übrigens führt Vererbung gerade zu weniger Kapselung. Denn Vererbung verbietet es, virtuelle Funktionen nicht als Teil der Klasse zu implementieren. Deswegen ist hier
>How Non-Member Functions Improve Encapsulation
https://www.aristeia.com/Papers/CUJ_Feb_2000.pdf
auch der erste Fall
make f a member function of C, was eben dieser Vererbungs-Beschränkung geschuldet ist. Hätte man diese Beschränkung nicht, würde man es lieber, falls möglich, als freie Funktion implementieren, und damit bessere Kapselung haben. Freie Funktionen (falls möglich) sind besser, aber Vererbung verwehrt einem das.
In Bezug z.B. auf WARMED ist das switch überlegen. Eben auch, weil es einem die Wahl lässt, wohin man die Funktionalität tut.