Vererbung? Finger weg!

[@caaarl6588]

9:18 Wow, hab ich mich bei den Soundeffekts erscheckt. 😶

[@alexanderbehling4680]

Und was ist mit Komposition? Damit schaffe ich eine starke Abhängigkeit. Damit ist die Wiederverwendbarkeit nicht mehr gegeben, da die beiden Klassen eine Einheit bilden. Die Verbindung wäre sowas wie "besteht aus". In einem konkreten Projekt habe ich eine Klasse "Court". Diese hat besagte Abhängigkeit zu den Klassen "Filiale" und "Sportart". Die Klasse "Court" besteht also aus "Filiale" und "Sportart", da diese Eigenschaften der Klasse sind und ohne diese ist die Klasse nicht lauffähig. DI wird hierbei schon genutzt. Ist das nun eine "gute Abhängigkeit" wie du erwähnt hast oder kann man die Wiederverwendbarkeit irgendwie erhöhen?

[@hulzi]

Bin da nicht ganz der selben Meinung, wenn man Vererbungen richig anwendet, gerade bei core logiken für verschieden Ausprägung, macht es absolut Sinn. Wie wollte ja bewuss mit Änderungen in der Basis zentral gesteuert möglichst viel erwischen und im extrem Fall nicht in einer Interface Hölle landen. Dependency injections, statics, worker und handler klassen ja. Je nach Anwendungsfall würd ich sagen, aber das Grundkonzept der OOP hat seine Berechtigung und muss natürlich richtig verwendet werden. Es gibt mittlerweile auch Konzepte die begründen, dass man code bewusst duplizieren (copy paste) soll.

[@BinGanzLieb]

bei uns wird zurzeit eine über 3-4 Vererbungshierarchien gebaut, was total quatsch ist. der typ (der das gemacht hat) kapiert das aber nicht. er habe ja bereits über 20 Jahre Erfahrung.

[@J0000-3]

Ich denke dieses duplizieren von Code macht nur dann sinn, wenn es möglich ist, dass sie unabhängig voneinander angepasst werden könnten oder? Sobald man Code dupliziert, je öfter, desto schlimmer, lassen sich nur sehr schwer Bugs beheben oder alle Funktionen gleichzeitig anpassen. Bei einer 2-Fachen Ausführung ist das noch human aber wenn ich manchmal sehe, dass man den selben Code-Snippet 10-15x im Projekt verwendet und ich daran dann irgendetwas anpassen darf, drehe ich durch ^^

[@hiemieshey9624]

Da bin ich voll und ganz bei dir!

[@DavidTielke]

Schön :)

[@marcusreinicke]

Hallo David, ab und an schaffe ich es, auch mal ein paar ältere Videos von Dir zu sichten. Ich bin voll bei Dir, aber Was ist denn mit OCP Open Close Prinzip? Eine Klasse nicht verändern, aber durch eine Ableitung erweitern!? Ist doch auch Vererbung. Gruß Marcus

[@DavidTielke]

Hallo Marcus, da hast Du ja noch ein bisschen was vor dir :) Früher wurde das OCP sehr viel mit Vererbung eingesetzt, aber überwiegend als noch große Monolithen entwickelt wurden. Heute wird meist eine Komponentenarchitektur verwendet und da ist halt das Problem, das die Abhängigkeit von Subklasse zu Basisklasse eine unlösbare Abhängigkeit erzeugt, d.h. solche Aspekte wie Austauschbarkeit, Modifizierbarkeit, Testbarkeit usw. sind nicht mehr erfüllbar. Ich glaube (sicher bin ich mir nicht) darüber habe ich auch in dem Video zu OCP gesprochen: kzbin.info/www/bejne/p6iUhZ-BadebjNk Gruß David

[@marcusreinicke]

@@DavidTielke ja Du hast recht. Das hast Du in dem Video gezeigt. Musste gerade kurz noch mal reinschauen. Das die Erweiterbarkeit über Schnittstellen realisiert wird, um eine lose Kopplung zu ermöglichen ist mir auch bekannt. Ist aber auch mal wieder nach hinten gerutscht. Ich hatte jetzt nur die Vererbung auf dem Schirm. 😉 LG

[@DavidTielke]

Alles gut, Hauptsache es ist klarer :) Gruß David

[@sral_bavaria]

@@DavidTielke Danke für den Kommentar, durch ihn kann den im Video angesprochenen Standpunkt besser nachvollziehen: Die Abhängigkeit zwischen Basis- und Abgeleiteter Klasse ist unlösbar und damit sind einige Nachteile für die Softwarequalität im Aspekt Testbarkeit und wiederverwendbarkeit vorraussehbar. Diese Info fehlt leider im Video. Überzeugt hat mich das trotzdem noch nicht, zumindest würde ich diesen Punkt gegen die Vorteile der Polymorphie abwägen.

[@yutubl]

Ich bin voll Deiner Meinung. OOP ist ein faszinierendes Programmierparadigma neben weiteren. Die wahre Kunst besteht darin, das dem zu lösenden Problem angemessene Paradigma zu wählen, so wie gut gewählte Datenstrukturen und Algorithmen viele Probleme ersparen oder lösen. Ich würde einer einmal entwickelten Basisklasse nicht leichtfertig ändern (ggf. temporär zu Debug-Zwecken aber nicht ohne Absprache ins VCS committen/submitten/einchecken) oder womöglich etwas hinzufügen, ohne zu wissen ob dies nicht bereits in Ableitungen dieser Klassenhierarchie Konflikte oder Probleme bereitet. Also nur mit guter Testabdeckung überhaupt in der OOP-Basisklassen-Tiefsee ändern mit Testbegleitung, denn dies kann eine nicht offensichtlich erkennbare aber sehr tiefgehende Änderung sein mit dem Risiko typischer Probleme durch Quereffekte mit versteckten Fehlern wie überhaupt bei jedem vorhandenem Quelltext ab einer gewissen Komplexität.

[@MarkusBurrer]

Es gibt ein wunderschönes Video von Dave Thomas "The Best OO Language is a Functional One". Da bittet er am Anfang alle die Hand zu heben, die OO programmieren. Dann sollen alle die Hände runter nehmen, die Klassen mit öffentlichen Daten verwenden (public instance variables), wenn sie Klassen mit Gettern und Settern verwenden und wenn sie Vererbung verwenden. Alle die übrig blieben programmieren tatsächlich OO. Alle anderen machen Klassen basierte Programmierung. Wer sich anschauen will wie OO ursprünglich gedacht war muss sich Smalltalk anschauen. Kann das Video nur wärmstens empfehlen.

[@marcotroster8247]

Vererbung ist ein absolutes No-Go. Das darf höchstens als Adapter verwendet werden, wenn ein externes API eine bestimmte externe API Klasse statt einem Interface als Parameter erwartet. Vererbung führt zu niedriger Kohäsion, weil der Code über die Hierarchie verteilt wird und somit auch schlecht lesbar ist. Außerdem bekommt man hohe Kopplung, die man mit Interfaces und Dependency Inversion nicht gehabt hätte. Meistens ist DRY nicht so wichtig wie man denkt. Wenn man ganz normalen Code mit Standard-Libs der jeweiligen Programmiersprache schreibt, stört mich die Dopplung von Code in den jeweiligen Interface Implementierungen kaum.

[@OlliS71]

Man muss aber auch sagen, dass für die meisten Highlevel-Entwickler sich gar nicht die Notwendigkeit ergibt, Implementation zu vererben. Auf Lowlevel-Ebene ergibt sich das auch nicht oft, aber ab und zu und da ist die Kopplung der Klassen kein Problem; ein gutes Beispiel sind ja Klassen für GUI-Komponenten oder die C++ I/O Streams, die sogar Mehrfach-Vererbung nach dem Diamond-Pattern machen.

[@Shabazza84]

Für mich ist die Kurzfassung für die Entscheidung immer: Ist eine Klasse ein "IST" zu einer anderen -> Vererbung (CKuh IST ein CTier) ist eine Klasse ein "HAT" zu einer anderen -> Komposition/Aggregation (CAuto HAT CMotor aber IST kein CMotor oder umgekehrt)

[@sral_bavaria]

Video hat mich nicht überzeugt :( Wenn man es falsch macht, ist es falsch. Stimmt! Aber wenn man Vererbung richtig und zielgerichtet einsetzt hat man dadurch deutliche Vorteile. Warum also Finger weg?

[@Dennis-el7cb]

Da hast du meine volle Zustimmung. Gibt es für dich noch andere Anwendungsfälle außer bei Entitäten? Mir fallen auch nur Entitäten ein. Denn ggf. wäre mir das sogar eine Diskussion im Team wert, dass man eine Vermeidung von Vererbungen in die Code-Richtlinie mit auf nimmt.

[@DavidTielke]

Schön das Du das auch so siehst! Bei der Verwendung von Frameworks und bestimmten Design-Patterns nutzt man es gezielt, sonst wüsste ich ehrlich gesagt kaum andere Anwendungsfälle.

[@DavidTielke]

@@gatisavots Dabei beziehst Du dich aber wieder auf Datenklassen. Fällt Dir für Logikklassen ein Beispiel ein?

[@Aalii6]

👍👍

[@andrerademacher9701]

Intro war nice, der Übergang etwas holprig

[@Tony.K871]

Vielleicht könnte man in solchen Fällen auch über den Einsatz eines Decorators nachdenken.

[@MindFreeaforLife]

Das ist selbstverständlich, dann ist es keine Vererbung mehr, ich liebe L in SOLID ;-)…

[@troi951]

Ich bin im Java Kontext unterwegs, das Beispiel einer MightyKlasse, wie du sie beschreibst habe ich noch nie gesehen. Also ich habe schon viel Schwachsinn gesehen aber ich würde am selben Tag das Unternehmen verlassen, wenn ich sowas sehen würde. Ehrlich gesagt halte ich das Beispiel für realitätsfern, kann mir kaum vorstellen, dass das wirklich so oft passiert.