[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es ums Fachgespräch.

[0:05] Wenn du noch mehr Informationen zum Fachgespräch von mir haben willst,

[0:08] dann schau doch mal auf meiner Website vorbei, dasperfektefachgespräch.de.

[0:14] Und jetzt wünsche ich dir viel Spaß mit der Podcast-Episode.

[0:19] Herzlich willkommen zum Anwendungsentwickler-Podcast,

[0:22] dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:26] In dieser Episode geht es um häufige Fragen im Fachgespräch,

[0:29] das Thema Vererbung. Viel Spaß!

[0:37] Hallo, ich möchte heute meine Podcast-Reihe mit dem Thema

[0:42] häufige Fragen im Fachgespräch fortsetzen.

[0:45] Beim letzten Mal hatten wir uns über die Kapselung

[0:48] im Zusammenhang mit der Objektorientierung unterhalten.

[0:51] Heute möchte ich die zweite große Säule der Objektorientierung behandeln,

[0:56] und zwar die Vererbung.

[0:59] Ich habe die Episode wieder in drei Teile gegliedert.

[1:02] Ich fange erst einmal an mit der Beantwortung der Frage,

[1:05] so wie ich sie im Fachgespräch beantworten würde,

[1:08] mit den verschiedensten Informationen, die man rund um die Vererbung so erzählen kann

[1:12] in einer mündlichen Prüfung.

[1:14] Dann würde ich ein wenig auf eine weiterführende Diskussion eingehen,

[1:17] ein paar Beispiele bringen für Fragen, die man rund um die Vererbung

[1:21] auch erwarten könnte in so einem Fachgespräch.

[1:24] Und zuletzt gehe ich dann noch einmal auf die Entwicklerpraxis ein.

[1:27] Wie könnte ich die Vererbung in der Praxis umsetzen?

[1:31] Dann fangen wir doch mal an mit der Beantwortung der Frage im Fachgespräch.

[1:35] Ich formuliere einfach jetzt mal ein paar Sätze,

[1:38] so wie ich die Frage im Fachgespräch beantworten würde.

[1:41] Wie gewohnt fange ich wieder mit einer abstrakten Definition an,

[1:45] also mit einer ganz allgemeingültigen.

[1:47] Ich versuche erstmal allgemein zu erklären, was denn Vererbung bedeutet,

[1:50] und werde dann Schritt für Schritt weiter, tiefer in das Thema reingehen

[1:54] und auf den Begriffen, die ich vielleicht schon definiert habe, dann aufbauen,

[1:58] um somit einen schönen Rundum-Schlag zu machen

[2:01] und das Thema Vererbung einmal komplett zu bearbeiten.

[2:05] Also, ich fange mal an.

[2:07] Klassen können Attribute und Methoden von anderen Klassen übernehmen,

[2:11] indem sie von ihnen erben.

[2:14] Bei dieser Vererbungsbeziehung haben wir einmal die vererbende Klasse,

[2:18] die heißt Basisklasse, wird auch manchmal Eltern- oder Superklasse genannt,

[2:23] und wir haben die erbende Klasse, das ist die Subklasse,

[2:26] oder auch abgeleitete oder Kindklasse genannt.

[2:30] Um von einer Klasse zu erben, schreibt man in Java Extents

[2:34] und den Namen der Basisklasse hinter die Klassendefinition.

[2:37] In C Sharp wird anstatt Extents der Doppelpunkt verwendet.

[2:42] Als Beispiel in Java könnte man nehmen Class Auto Extents Fahrzeug.

[2:48] Alle Attribute und Methoden der Basisklasse können jetzt in der Subklasse verwendet werden,

[2:54] sofern sie dort sichtbar sind.

[2:56] Das bedeutet, dass die Member in der Basisklasse entweder Public oder Protected sein müssen.

[3:02] Public bedeutet, dass alle Klassen darauf zugreifen können,

[3:05] Protected bedeutet, dass nur die definierende Klasse und alle abgeleiteten Klassen darauf zugreifen können.

[3:11] Man kann eine Klasse mit dem Schlüsselwort Abstract als nicht-instanzierbar kennzeichnen.

[3:18] Das bedeutet, dass man kein Objekt von dieser Klasse erzeugen kann

[3:22] und dass Methoden und Attribute nur über Objekte der Subklassen dieser Klasse aufgerufen werden können.

[3:28] Das benutzt man gerne im Kontext der Vererbung,

[3:32] denn einige Klassen stellen einfach nur Basisfunktionalität bereit, ohne eine konkrete Instanz zu erlauben.

[3:40] Diese Klassen würde ich dann Abstract machen, um dann mit ihren Subklassen konkret arbeiten zu können.

[3:46] Man kann auch eine Methode als Abstract kennzeichnen.

[3:50] Das bedeutet dann, dass sie in der Basisklasse nicht implementiert ist

[3:54] und sie in den Subklassen implementiert werden muss.

[3:57] Ich kann also das erzwingen, dass diese Implementierung in den Subklassen angeboten werden muss.

[4:03] Sobald mindestens eine Methode einer Klasse Abstract ist, muss auch die gesamte Klasse Abstract sein.

[4:10] Das ist auch logisch, denn wenn man eine Methode nicht implementiert,

[4:14] das bedeutet ja, dass sie Abstract ist, kann man logischerweise auch kein Objekt dieser Klasse erzeugen,

[4:19] denn eine Methode würde ja nicht funktionieren.

[4:22] Nun ist es so, dass Methoden in Subklassen überschrieben werden können.

[4:27] Das bedeutet, dass in der Subklasse eine Methode mit derselben Signatur wie in der Basisklasse implementiert wird.

[4:35] Beim Aufruf einer Methode an einem Objekt dieser Subklasse wird jetzt diese neue,

[4:41] diese überschriebene Methode verwendet und nicht die der Basisklasse.

[4:45] Einige von mir sprachen, Java gehört dazu, erlauben standardmäßig das Überschreiben aller Methoden.

[4:51] Während andere, wie zum Beispiel C-Sharp, es standardmäßig verbieten.

[4:55] In Java kann man explizit Methoden mit dem Schlüsselwort FINAL als nicht überschreibbar kennzeichnen,

[5:01] während man in C-Sharp genau das Gegenteil macht.

[5:04] Dort kann man nämlich mit VIRTUAL eine Methode als überschreibbar kennzeichnen.

[5:09] Auch ganze Klassen können als nicht überschreibbar gekennzeichnet werden.

[5:14] Das bedeutet dann, dass man von denen eben nichts erben kann.

[5:17] In Java wird das Schlüsselwort FINAL auch dafür benutzt.

[5:20] Und in C-Sharp gibt es dafür ein anderes Schlüsselwort, das heißt SEALED.

[5:24] Mit SUPER, dem Schlüsselwort, kann man innerhalb einer Subklasse auf Member der Basisklasse zugreifen.

[5:30] Das braucht man zum Beispiel, wenn man den Konstruktor der Basisklasse aufrufen will.

[5:35] Dann macht man SUPER, Klammer auf, Klammer zu, um den aufzurufen.

[5:39] In den meisten modernen Programmiersprachen ist es heutzutage nur möglich, von einer einzigen Klasse zu erben.

[5:46] Die sogenannte Mehrfachvererbung, wo es möglich wäre, eben von mehreren unterschiedlichen Klassen zu erben,

[5:52] die ist dort verboten.

[5:54] Prominentes Beispiel, wo sie erlaubt ist, ist C++.

[5:58] Problem mit der Mehrfachvererbung ist das sogenannte Diamantenproblem.

[6:03] Wenn eine Klasse eine Methode oder einen Member vererbt an zwei abgeleitete Klassen

[6:08] und von diesen beiden Klassen gemeinsam erbt dann eine dritte Klasse,

[6:14] dann kann das zu einem Problem führen, denn der Compiler kann nicht entscheiden,

[6:18] welche konkrete Methode er zum Beispiel erben soll, von der einen oder von der anderen vererbenden Klasse.

[6:24] In vielen objektorientierten Sprachen gibt es zu jeder Klasse mindestens eine Basisklasse.

[6:31] In Java ist das zum Beispiel die Klasse Object.

[6:34] Von dieser Klasse erben automatisch alle anderen Klassen,

[6:38] egal ob selbst definiert oder von der Sprache selber bereitgestellt.

[6:43] So, das wäre alles, was mir zu diesem Thema Vererbung eingefallen ist.

[6:48] Ich habe das jetzt mal so vorstrukturiert, wie ich das erwarten würde,

[6:51] vom Allgemeinen bis hin zum Speziellen, einige Schlüsselwörter eingestreut.

[6:56] Die Unterscheidung zwischen Java und C Sharp und C++ und so weiter müsst ihr natürlich da nicht treffen.

[7:01] Ich würde euch empfehlen, immer am Beispiel eurer eigenen Lieblingsprogrammiersprache

[7:05] oder der Programmiersprache, mit der ihr im Betrieb arbeitet, die Sachen zu erklären.

[7:09] Da steckt ihr am besten drin.

[7:11] Da kommt ihr vielleicht auch auf Beispiele oder auf Probleme,

[7:14] die ihr in eurer eigenen Praxis selber schon gehabt habt.

[7:17] Und das ist meistens schöner in der Prüfung, weil man dort auch zeigen kann,

[7:21] dass man wirklich damit gearbeitet hat und nicht einfach nur Lehrbuchantworten quasi auswendig gelernt hat.

[7:27] Ich würde jetzt mal so ein paar Beispiele noch bringen,

[7:29] was ich im Anschluss an so eine Diskussion vielleicht noch für Fragen stellen könnte.

[7:34] Als allererstes möchte ich aber mit so einer kleinen Bitte beginnen.

[7:37] Überlegt euch vor dem Fachgespräch, vor der möglichen Prüfung,

[7:40] ein in irgendeiner Weise interessantes Beispiel für Vererbung.

[7:46] Bitte nehmt nicht das klassische Autofahrzeugbeispiel,

[7:50] das ganz, ganz viele Prüflinge immer in der Schule lehren.

[7:54] Auf der einen Seite geht man auf Nummer sicher, wenn man das benutzt.

[7:57] Auf der anderen Seite stellt man schnell fest,

[7:59] dass das Beispiel in Details irgendwie an der einen oder anderen Stelle manchmal hakt.

[8:03] Und wenn man da dann tiefer rein muss und das eigentlich auch noch nie in der Praxis umgesetzt hat,

[8:07] weil das kaum jemand programmiert, so ein Beispiel, dann fängt man da ganz schnell an zu schwimmen.

[8:12] Ich würde euch empfehlen, nehmt euch einfach ein Beispiel aus eurem eigenen Projekt.

[8:16] Vielleicht habt ihr da ja eine Vererbung drin, die in irgendeiner Form sinnvoll ist, was ich hoffe.

[8:20] Und die habt ihr tatsächlich selber umgesetzt und habt eure Erfahrungen damit gemacht

[8:24] und wisst auch, warum ihr die Vererbung dort eingesetzt habt und was die Vor- und Nachteile vielleicht sind.

[8:28] Das ist immer spannender und immer interessanter, als wenn ich zum 137. Mal das Beispiel mit dem Auto höre.

[8:35] Also denkt euch da irgendwie ein nettes Beispiel aus und geht das aber auch im Kopf vor der Prüfung mal im Detail durch

[8:43] und stellt dann nicht wehend der Prüfung fest, dass ihr doch eigentlich besser die Vererbung gar nicht benutzt haben solltet in eurem Projekt.

[8:50] Was ich im Zuge der Vererbung, gerade auch beim Überschreiben von Methoden, dann immer gerne mal frage,

[8:57] ist die Methodensignatur, was das denn wohl eigentlich ist.

[9:01] Die Signatur einer Methode beinhaltet zum einen den Namen der Methode und die Art und Reihenfolge der Parameter.

[9:10] Mit Art meine ich den Typ der Parameter.

[9:13] Der Rückgabewert der Methode zählt nicht zur Signatur dazu.

[9:19] Das kann man auch schön in Java sehen, wenn man eine Methode anlegt in einer Klasse,

[9:24] in der es schon eine andere Methode gibt und gibt der den gleichen Namen und die gleichen Parameter aber einen anderen Rückgabewert,

[9:31] dann wird Java sagen, tut mir leid, geht nicht, diese Methode gibt es bereits.

[9:35] Das heißt, sie ist nicht unterschiedlich zu der, die es schon gibt.

[9:39] Das bedeutet, dass die Methodensignatur eben übereinstimmt,

[9:43] weil Java nur den Namen und die Parameter für die Signatur hernimmt und eben nicht den Rückgabewert.

[9:51] Wichtig ist bei den Parametern, dass die Reihenfolge und der Typ relevant sind, nicht der Name.

[9:58] Ich kann eben nicht eine Methode anlegen mit dem gleichen Namen und jeweils einem String-Parameter,

[10:04] aber in der einen Methode nenne ich den String-Parameter Parameter 1 und in der anderen nenne ich ihn Parameter 2.

[10:10] Dann wäre zwar der Name unterschiedlich, aber der Typ nicht,

[10:13] aber der Name ist für Java völlig irrelevant und auch für andere Programmiesprachen übrigens.

[10:17] Also es geht hier nur um den Typ der Parameter.

[10:19] Im Prinzip sieht die Programmiersprache eine Signatur als Name, Klammer auf, String, Int, Char, Klammer zu.

[10:26] Die Namen interessieren, also die Namen der Parameter, interessieren die Programmiersprache nicht.

[10:33] Mit der Signatur, wenn man diesen Begriff beherrscht, kann man halt auch wunderbar eine weitere Frage beantworten,

[10:39] und zwar die nach dem Unterschied zwischen dem Überladen und dem Überschreiben von Methoden.

[10:45] Das Überladen ist etwas, was eigentlich nichts mit der Vererbung zu tun hat, wird aber halt gerne gefragt,

[10:50] weil das Überschreiben eben erklärt werden müsste im Zusammenhang mit der Vererbung.

[10:55] Und weil viele Prüflinge das gerne mal durcheinander bringen, würde ich da mal kurz drauf eingehen.

[10:59] Also das Überschreiben von Methoden, das hatte ich eingangs schon erwähnt,

[11:03] bedeutet, dass ich in einer Subklasse eine Methode mit derselben Signatur wie in der Basisklasse anlege

[11:10] und damit diese Methode überschreibe. Das bedeutet, ich gebe ihr eine neue Implementierung.

[11:17] Wenn jetzt mit dem Objekt der Subklasse gearbeitet wird und die Methode aufgerufen wird,

[11:21] dann wird die Implementierung der Subklasse verwendet und nicht die der Basisklasse.

[11:25] Das heißt, deren Funktionalität wurde verändert, die wurde überschrieben.

[11:29] Beim Überladen von Methoden bin ich in einer Klasse, da geht es gar nicht um die Vererbung,

[11:35] sondern dann definiere ich in einer Klasse eine zusätzliche Methode mit demselben Namen

[11:40] wie dem einer anderen Methode in der Klasse, aber mit unterschiedlichen Parametern.

[11:46] Hier gilt auch wieder, wie beim Überschreiben, mit unterschiedlichen Parametertypen.

[11:49] Die Namen sind auch hier wieder relevant.

[11:52] Beispiel dafür wäre aus Java die System.out.println-Methode.

[11:56] Die ist ungefähr zehnmal überladen und zwar für jeden möglichen Datentyp, den man mit Println so ausgeben kann.

[12:03] Und hier kommt auch genau der Sinn des Überladens ins Spiel.

[12:06] Ich brauche den eigentlich nur in statisch typisierten Programmiersprachen,

[12:10] wo ich einfach eine Funktionalität, der ich einen schönen Namen geben kann,

[12:14] wie zum Beispiel Println, für unterschiedliche Datentypen anbieten möchte.

[12:19] Und ich kann halt nicht in statisch typisierten Sprachen sowas machen wie Print und dann X.

[12:24] Und das X kann ein Int oder ein String oder ein was auch immer sein.

[12:29] Das geht nun mal nicht, denn der Compiler prüft die Typsicherheit beim Kompilieren.

[12:34] Und wenn ich jetzt diese Funktionalität anbieten will, muss ich die halt für alle möglichen Datentypen,

[12:38] für die die funktionieren soll, separat anbieten.

[12:41] Ein schönes Beispiel dafür ist eine Addiere-Funktion.

[12:44] Addiere int a, int b und addiere double a und double b.

[12:51] Das wäre ein schönes Beispiel für das Überladen von Methoden.

[12:56] Beim Überladen von Methoden kann übrigens auch der Rückgabewert der Methode unterschiedlich sein.

[13:00] Das Beispiel von eben ist eigentlich ganz passend.

[13:03] Wenn ich int a und int b addiere, sollte auch ein int c zurückkommen.

[13:08] Bei double a und double b sollte logischerweise double c zurückkommen.

[13:13] Eine kleine nette Frage, die mir auch ab und an noch mal einfällt,

[13:18] ist, ob ich auch private Methoden überschreiben kann.

[13:23] Dazu müsste ich jetzt als Prüfling erstmal sagen, prinzipiell nein,

[13:27] denn private Methoden und private Member allgemein werden nicht an Subklassen vererbt.

[13:32] Die sind dort nicht sichtbar und demnach auch nicht überschreibbar.

[13:36] Dennoch kann ich tatsächlich in einer Subklasse eine Methode mit derselben Signatur

[13:42] wie der einer Private Methode in der Basisklasse anlegen.

[13:46] Das bedeutet aber nicht, dass ich die Funktionalität verändert habe,

[13:49] sondern nur, dass ich die Methode der Basisklasse maskiert habe.

[13:53] Oder im Englischen sagt man dann hidden, d.h. die Methode wurde versteckt von der in der Subklasse.

[14:01] Eine weiterführende Diskussion der Vererbungen kann man dann z.B. mit Designpattern führen.

[14:07] Designpattern verwenden sehr oft die Vererbungen.

[14:10] Ein schönes Beispiel für etwas, was vielleicht der Anwender sogar in der Praxis schon eingesetzt hat,

[14:14] auch wenn er vielleicht gar nicht weiß, dass es sich dabei um ein Designpattern handelt,

[14:17] das ist die sogenannte Template Method, also die Vorlagen- oder Schablonen-Methode.

[14:23] Und die verwendet zwei Konzepte aus der Vererbung und auch zwei Schlüsselwörter,

[14:28] die man da gut dran erklären kann, und zwar einmal Final und einmal Abstract,

[14:32] wenn wir jetzt mal bei Java bleiben.

[14:34] Eine Vorlagen-Methode, also eine Template-Methode, die definiert einen Algorithmus

[14:39] in Form einer feststehenden Reihenfolge von Teilschritten.

[14:45] Ich nehme mal das Beispiel Kuchenbacken.

[14:47] Beim Kuchenbacken muss ich erst die Zutaten in den Topf tun,

[14:51] dann rühre ich die um und dann gieße ich die Zutaten auf das Backblech.

[14:56] Ich kann das nicht in einer anderen Reihenfolge machen.

[14:58] Ich kann nicht erst umrühren, dann aufs Backblech und dann die Zutaten rein.

[15:01] Das funktioniert nicht.

[15:02] Das heißt, ich backe einen Kuchen immer in genau dieser Reihenfolge.

[15:06] Wenn das so ist, weiß ich, dass ich jetzt z.B. das Schlüsselwort Final benutzen könnte,

[15:10] um diese Backe-Kuchen-Methode als nicht überschreibbar zu kennzeichnen.

[15:15] Denn diese Reihenfolge ist nun mal fix vorgegeben und darf sich auch nicht verändern.

[15:19] Und auch Subklassen dürfen die nicht einfach verändern, weil es dann zu Fehlern kommen würde.

[15:23] Jetzt ist es aber so, dass ich vielleicht meinen Subklassen die konkrete Implementierung der Teilschritte

[15:30] überlassen möchte, wie sie die umsetzen.

[15:33] Als Beispiel, wie kriege ich meine Zutaten in den Topf?

[15:37] Muss ich das Ei vorher aufknacken und dann da reinhauen?

[15:41] Muss ich den Mehlbeutel aufmachen?

[15:43] Muss ich den Zucker vorher irgendwie vorbereiten oder wie auch immer?

[15:46] Das interessiert mich beim Backe-Kuchen eigentlich weniger.

[15:49] Es geht nur darum, die Reihenfolge einzuhalten.

[15:51] Wie ich z.B. die Zutaten konkret in den Topf packe, das ist der Subklass überlassen.

[15:56] Das bedeutet, ich möchte der Subklasse erlauben, die Teilschritte zu überschreiben,

[16:03] aber den Gesamtalgorithmus nicht.

[16:05] Und wenn ich das möchte, dass die Teilschritte überschrieben werden können oder sogar müssen,

[16:10] kann ich dafür Methoden definieren in der Basisklasse und diese als Abstract kennzeichnen.

[16:16] Und genau das ist das Konzept der Template Method.

[16:18] Ich lege den definierten Algorithmus fest in Form von abstrakten Methoden,

[16:24] die in einer bestimmten Reihenfolge aufgerufen werden,

[16:26] und die Methode, die diese Reihenfolge definiert, die kennzeichne ich als Final.

[16:32] Und ich habe mal ein ganz konkretes Beispiel, was ich auch selber schon mal umgesetzt habe.

[16:36] Schreiben einer XML-Datei.

[16:38] Eine XML-Datei hat immer erstmal einen Kopf, dann kommen die Elemente und dann kommt der Fuß.

[16:43] Es ist total unlogisch, erst den Fuß, dann den Kopf und dann die Elemente zu schreiben.

[16:47] Das heißt, ich habe in einer Basisklasse definiert,

[16:49] schreibe XML, macht erst, schreibe Kopf, dann schreibe Elemente und dann schreibe Fuß.

[16:56] Aber wie die XML-Daten für die konkrete Subklasse jetzt aussehen,

[17:00] ob ich jetzt eine XML-Datei mit Autos schreibe oder mit Büchern oder mit Schülern oder was auch immer,

[17:06] das kann und will ich gar nicht definieren.

[17:08] Deswegen gibt es in der Basisklasse nur diese drei abstrakten Methoden,

[17:12] schreibe Kopf, schreibe Fuß und schreibe Elemente.

[17:14] Und die Subklasse, die dann zum Beispiel Schüler-XML-Schreiber heißt,

[17:19] die implementiert nur die abstrakten Methoden,

[17:22] aber die Final-Schreibe-XML-Methode, die wird 1 zu 1 übernommen und darf auch nicht verändert werden.

[17:30] Dann kommen wir zum letzten Kapitel für heute, und zwar den Tipps für die Entwicklerpraxis.

[17:36] Ich persönlich bin der Meinung, dass die Vererbung eine ganz, ganz wichtige Rolle heutzutage spielt.

[17:41] Viele objektorientierte Sprachen kennen die Vererbung und machen auch intensiv Gebrauch von ihr.

[17:47] Und man kann auch als Entwickler natürlich von ihr profitieren.

[17:49] Nicht umsonst ist es halt einer der wichtigsten Bereiche der Objektorientierung,

[17:54] eine ganz wichtige Säule, sage ich mal, der Objektorientierung.

[17:58] Also, da muss ich keine Angst vor haben.

[18:01] Die sollte ich und kann ich auch gerne benutzen in der Programmierung.

[18:04] Und man sieht auch an den Entwurfsmustern, ich habe einige Bücher zu den Entwurfsmustern in den Shownotes verlinkt,

[18:11] so kann man sich den mal im Detail angucken, dass ganz viele davon auf Vererbung setzen.

[18:17] Ich persönlich hätte aber ein Problem damit, die Vererbung zu stark oder zu schnell einzusetzen in der Programmierung.

[18:25] Also viele Azubis zum Beispiel tendieren dazu zu sagen,

[18:29] Vererbung kenne ich, das ist quasi zur Wiederverwendbarkeit super geeignet,

[18:33] also lasse ich einfach mal alle möglichen Klassen von irgendwas erben,

[18:35] nur damit ich eine Methode benutzen kann, die sie da definieren.

[18:38] Und das ist nicht sinnvoll.

[18:40] Denn das Vererben ist eine ganz, ganz starke Beziehung zwischen Klassen.

[18:44] Wir hatten schon gehört, dass ich meistens nur von einer einzigen Klasse erben kann.

[18:48] Und wenn ich mit der verdrahtet bin, sage ich mal, dann werde ich diese Verdrahtung sehr schwer wieder los.

[18:53] Wenn ich jetzt von einer anderen Klasse doch erben möchte, dann habe ich auf einmal ein Problem.

[18:56] Da muss ich wirklich die Klasse selber verändern.

[18:59] Ich muss die Methoden, die ich vorher geerbt habe, auf einmal doch selber implementieren und hin und her.

[19:03] Das ist also ein relativ großer Aufwand, das wieder loszuwerden.

[19:06] Und deswegen würde ich dazu tendieren, die Vererbung nicht als Standardweg zu wählen,

[19:11] sondern erstmal zu versuchen, das Ganze anders zu lösen.

[19:14] Dafür gibt es auch einen schönen Merksatz, und zwar

[19:19] Favor composition over inheritance.

[19:22] Das bedeutet, ich sollte es immer bevorzugen, eine Komposition oder auch eine Delegierung an eine andere Klasse zu benutzen,

[19:29] anstatt von einer Klasse zu erben.

[19:32] Ganz wichtig bei der Vererbung, wenn ich das denn einsetze,

[19:36] ist, an das Liskov Substitution Principle zu denken.

[19:40] Das ist eines der 5 SOLID Principles,

[19:43] und die sollte ich bei der Programmierung unbedingt einhalten.

[19:46] Dabei ist es wichtig, dass die abgeleiteten Klassen

[19:50] mindestens das Interface, also die Schnittstelle,

[19:54] der Basisklasse bereitstellen und das in keiner Weise einschränken dürfen.

[20:00] Wenn ich in meinen abgeleiteten Klassen Methoden in irgendeiner Form einschränke, die in der Basisklasse funktioniert haben,

[20:07] dann widerspreche ich dem Liskov Substitution Principle.

[20:12] Wir werden in der nächsten Folge, wenn es um die klassischen Fragen des Fachgesprächs geht, über die Polymorphie sprechen.

[20:19] Und da werden wir das Thema sicherlich nochmal aufgreifen.

[20:22] Um das Ganze so ein bisschen vorwegzunehmen, Vererbung ist ja eine Form der Polymorphie.

[20:26] Und das bedeutet, dass ich alle Subklassen dort benutzen kann, wo ich auch die Basisklasse benutzen kann.

[20:32] Wenn sich diese Subklassen dann aber nicht so verhalten wie die Basisklasse,

[20:36] sondern Funktionen nicht bereitstellen oder anders implementieren,

[20:39] dann ist eben dieses Prinzip der Ersetzbarkeit nicht mehr gewährleistet.

[20:44] Und das darf nicht sein, weil dann der Code Annahmen trifft, die durch die Subklassen quasi nicht angeboten werden.

[20:53] Und das kann dann in der Probierung nicht funktionieren.

[20:56] Ein schönes Beispiel, was Onkel Bob in einem seiner Artikel mal gebracht hat, ist Quadrat und Rechteck.

[21:04] Wenn man im Mathematikunterricht gut aufgepasst hat, dann weiß man, dass ein Quadrat eigentlich nur eine besondere Form eines Rechtecks ist.

[21:13] Die grundsätzliche Form ist das Rechteck.

[21:16] Die hat vier Seiten, von denen jeweils zwei gegenüberliegende die gleiche Länge haben.

[21:22] Und alle Seiten sind mit rechten Winkeln verbunden.

[21:25] Das definiert ein Rechteck.

[21:27] Und jetzt kann ich sagen, dass ein Quadrat einfach eine besondere Form des Rechtecks ist.

[21:31] Und zwar sind dort alle Seiten gleich lang.

[21:34] Also beide gleich langen Seitenpaare haben zusätzlich noch die gleiche Länge.

[21:40] Wenn ich dieses Hintergrundwissen habe, dann könnte ich jetzt vermuten, dass ich in meiner Programmierung das auch genauso umsetzen müsste.

[21:47] Es gibt ja auch den Ausdruck, dass wenn eine Klasse von einer anderen erbt, dann eine Ist-Ein-Beziehung besteht.

[21:54] Und das würde hier bestehen.

[21:56] Ein Quadrat ist ein Rechteck.

[21:59] Also bedeutet das, dass das Quadrat von dem Rechteck erben müsste eigentlich, ganz logisch.

[22:05] Das mag in der Mathematik auch so sein und ist dort auch sinnvoll.

[22:10] In der Programmierung führt das aber zu einem Problem.

[22:13] Und wenn wir uns das mal im Detail angucken, dann wird das sehr schnell deutlich.

[22:16] Wenn ich nämlich die Klasse Rechteck programmiere, dann muss ich eigentlich die beiden Seiten a und b individuell als Variablen anlegen.

[22:24] Ich nenne die einfach mal a und b, angenommen es sind zwei Int-Variablen.

[22:27] Wenn ich jetzt aber die Klasse Quadrat von Rechteck erben lasse, dann erbt sie ja diese beiden Attribute a und b.

[22:34] Eigentlich dürfte das Quadrat aber nur eine einzige Seite haben.

[22:40] Denn wenn wir a und b erben und auch korrekt setzen müssen, was wir tun müssen, denn wir sind ja ein Rechteck, dann kann das zu Problemen führen.

[22:48] Ich muss nämlich auf einmal ganz seltsame Prüfungen machen.

[22:50] Wenn nämlich die eine Seite gesetzt wird, muss automatisch die andere Seite mitgesetzt werden.

[22:56] Stellen wir uns vor, es gibt zwei Setter, Set A und Set B.

[22:59] Dann könnte ich mich natürlich fragen, was machen die denn jetzt eigentlich?

[23:03] Warum gibt es überhaupt zwei Setter für zwei Seiten, wenn das Quadrat doch eigentlich nur einen haben dürfte?

[23:08] Denn es hat ja überall die gleiche Länge.

[23:10] Ich müsste also in Set A, wenn das aufgerufen wird, automatisch auch Set B aufrufen.

[23:15] Und umgekehrt, wenn B gesetzt wird, auch wieder A aufrufen, damit die beiden Seiten identisch sind.

[23:20] Und dann kann man sich vorstellen, wenn man das mal irgendwo vergisst, hat man auf einmal eine Inkonsistenz.

[23:24] Also man sieht hier, wir haben hier Vererbung genutzt, um etwas darzustellen, was aus dem gesunden Menschenverstand heraus so dargestellt werden müsste,

[23:33] aber in der Programmierung nicht so umgesetzt werden darf.

[23:37] Weil wir hier einfach Dinge vererben, die in dieser Klasse Quadrat nicht vererbt werden dürfen, die dort keinen Platz haben.

[23:45] Wenn wir nur eine Variable mit einem Wert haben dürfen, dann können und sollen wir das nicht mit zwei Werten umsetzen.

[23:51] Das ist völliger Quatsch.

[23:53] So, damit wäre ich für heute auch schon wieder am Ende.

[23:57] Wir haben jetzt die zwei ersten Säulen der Objektorientierung durch, die Kapselung und die Vererbung.

[24:03] Ich hatte es eben schon angesprochen, die Polymorphie, die fehlt noch und die wird in einer der nächsten Episoden dann nachgeholt.

[24:10] Bis dahin möchte ich mich für das Zuhören bedanken.

[24:15] Ich würde mich über Feedback zur Episode oder zum Podcast insgesamt freuen, über die Website oder über Mail at andungsentwicklerpodcast.de.

[24:25] Ihr könnt mir auch gerne einen Kommentar hinterlassen oder ihr gebt mir ein Review bei iTunes, das würde mich auch sehr freuen.

[24:32] Der Link zu dieser Episode ist wie gewohnt andungsentwicklerpodcast.de.

[24:39] Dort findet ihr einige weiterführende Artikel zu den heute behandelten Themen und auch eine Literaturempfehlung, wo das Thema Vererbung nochmal im Detail erklärt wird.

[24:49] Und damit möchte ich mich für heute verabschieden.

[24:52] Ich hoffe, es hat euch gefallen.

[24:54] Ich sage nochmal danke fürs Zuhören. Bis zum nächsten Mal und tschüss.

[25:02] Untertitel der Amara.org-Community