Video: 02: Objektorientierte Programmierung, Objekte und Klassen, Typen und Variablen 2025
Das Konzept der Vererbung und somit des Faktorisierungsvorgangs in C ++ erlaubt es einer Klasse, die Eigenschaften einer Basisklasse zu erben. Vererbung hat eine Reihe von Zwecken. Der Hauptvorteil der Vererbung ist die Fähigkeit, die Beziehung zwischen Klassen aufzuzeigen. Das ist die so genannte IS_A-Beziehung - ein MicrowaveOven IS_A-Ofen und solche Dinge.
Factoring ist ein großartiges Zeug, wenn Sie die richtigen Korrelationen herstellen. Zum Beispiel scheint die Beziehung zwischen Mikrowelle und herkömmlichem Ofen natürlich zu sein. Behaupten Sie, dass Mikrowelle eine besondere Art von Toaster ist, und Sie sind auf Ärger vorbereitet. Es stimmt, sie machen beide Sachen heiß, beide benutzen Strom, und sie sind beide in der Küche zu finden, aber die Ähnlichkeit endet dort - eine Mikrowelle kann keinen Toast machen und ein Toaster kann keine Nachos machen.
Das Identifizieren der einem Problem inhärenten Klassen und das Zeichnen der korrekten Beziehungen zwischen diesen Klassen ist ein Prozess, der als -Faktorisierung bekannt ist. (Das Wort bezieht sich auf die Arithmetik, die Sie in der Grundschule erzwungen haben: Auszählen der kleinsten gemeinsamen Nenner, zum Beispiel 12 ist gleich 2 mal 2 mal 3.)
So können Sie Vererbung, um Ihre Programme mit einem Bankkonto Beispiel zu vereinfachen. Angenommen, Sie wurden gebeten, ein einfaches Bankprogramm zu schreiben, das das Konzept eines Sparkontos und eines Girokontos implementiert.
Objektorientierte Programmierer haben einen prägnanten Weg gefunden, um die hervorstechenden Punkte einer Klasse in einer Zeichnung zu beschreiben. Die Checking und Einsparungen Klassen sind in dieser Abbildung dargestellt. (Dies ist nur eine von mehreren Möglichkeiten, das Gleiche grafisch auszudrücken.)
Um diese Figur und die anderen Abbildungen zu lesen, denken Sie an Folgendes:
-
Die große Box ist die Klasse mit dem Klassennamen oben.
-
Die Namen in den Boxen sind Mitgliedsfunktionen.
-
Die nicht in Boxen enthaltenen Namen sind Datenmember.
-
Die Namen, die teilweise aus den Boxen herausragen, sind öffentlich zugängliche Mitglieder; das heißt, auf diese Mitglieder kann durch Funktionen zugegriffen werden, die nicht Teil der Klasse oder ihrer Nachkommen sind. Diejenigen Mitglieder, die vollständig innerhalb der Box sind, sind von außerhalb der Klasse nicht zugänglich.
-
Ein dicker Pfeil steht für die IS_A-Beziehung.
-
Ein dünner Pfeil steht für die HAS_A-Beziehung.
Ein Auto IS_A Fahrzeug , , aber ein Auto HAS_A Motor .
In der ersten Abbildung sehen Sie, dass die Checking - und Savings -Klassen viel gemeinsam haben. Beispielsweise haben beide Klassen eine Memberfunktion "withdraw ()" und "deposit ()".Da die beiden Klassen jedoch nicht identisch sind, müssen sie als separate Klassen verbleiben. (In einer realen Bankanwendung wären die beiden Klassen wesentlich unterschiedlicher als in diesem Beispiel.) Dennoch sollte es eine Möglichkeit geben, diese Wiederholung zu vermeiden.
Sie könnten eine dieser Klassen von der anderen erben lassen. Einsparungen hat mehr Mitglieder als Prüfen, Damit können Sie Einsparungen von Prüfen erben lassen. Diese Anordnung wird in dieser nächsten Abbildung gezeigt.
Die Savings -Klasse erbt alle Mitglieder. Die Klasse wird mit dem Hinzufügen des Datenelements noWithdrawals und dem Überschreiben der Funktion withdraw () abgeschlossen. Sie müssen die Abhebung () unterdrücken, da die Regeln für das Abheben von Geld von einem Sparkonto sich von denen für die Abhebung von Geld von einem Girokonto unterscheiden.
Obwohl Ersparnisse von geerbt werden können, ist das Überprüfen von mühsam, aber nicht vollständig zufriedenstellend. Das Hauptproblem ist, dass, wie das Gewicht auf meinem Führerschein aufgeführt, es die Wahrheit falsch darstellt. Diese Vererbungsbeziehung impliziert, dass ein Sparkonto eine besondere Art von Girokonto ist, was es nicht ist.
Solche Falschdarstellungen sind für den Programmierer verwirrend, sowohl heute als auch morgen. Eines Tages wird ein Programmierer, der mit unseren Programmier-Tricks nicht vertraut ist, lesen und verstehen müssen, was unser Code tut. Irreführende Darstellungen sind schwer zu vereinbaren und zu verstehen.
Darüber hinaus können solche Falschdarstellungen im weiteren Verlauf zu Problemen führen. Angenommen, die Bank ändert ihre Richtlinien in Bezug auf Girokonten. Angenommen, es wird entschieden, eine Servicegebühr für Girokonten nur dann zu berechnen, wenn das Mindestguthaben während des Monats unter einen bestimmten Wert fällt.
Eine solche Änderung kann leicht mit minimalen Änderungen an der Klasse Checking vorgenommen werden. Sie müssen der Klasse ein neues Datenelement hinzufügen, um den Mindestsaldo während des Monats zu verfolgen. Lassen Sie uns auf ein Glied hinausgehen und es minimumBalance nennen.
Aber jetzt haben Sie ein Problem. Da Savings von Erben erbt, erhält Savings dieses neue Datenelement ebenfalls. Es hat keine Verwendung für dieses Mitglied, weil das Mindestguthaben Sparkonten nicht betrifft, also sitzt es gerade dort. Denken Sie daran, dass jedes Girokonto-Objekt über das zusätzliche Mitglied minimumBalance verfügt. Ein zusätzliches Datenelement ist vielleicht keine große Sache, aber es fügt weitere Verwirrung hinzu.
Änderungen wie diese häufen sich an. Heute ist es ein zusätzliches Datenmitglied - morgen ist es eine veränderte Mitgliedsfunktion. Schließlich trägt die Sparkonto-Klasse viel zusätzliches Gepäck, das nur für Girokonten gilt.
Jetzt kommt die Bank zurück und beschließt, eine Sparkontopolitik zu ändern. Dazu müssen Sie einige Funktionen in Prüfen ändern. Änderungen wie diese in der Basisklasse werden automatisch auf die Unterklasse übertragen, sofern die Funktion nicht bereits in der Unterklasse Einsparungen überschrieben wurde.
Nehmen Sie zum Beispiel an, dass die Bank entscheidet, Toaster für jede Einzahlung auf das Girokonto auszugeben. Wenn die Bank (oder ihre Programmierer) das nicht wüssten, würden Einzahlungen auf Girokonten automatisch zu Toasterspenden führen. Wenn Sie nicht sehr vorsichtig sind, können Änderungen an Prüfen unerwartet in Einsparungen erscheinen.
Wie können Sie diese Probleme vermeiden? Die Behauptung, dass Prüfen ein Sonderfall von Einsparungen ist, ändert sich, löst aber nicht unser Problem. Was Sie brauchen, ist eine dritte Klasse (nennen Sie es Account, nur für Grins), die die Dinge verkörpert, die zwischen Checking und Savings, üblich sind.
Wie löst das Erstellen eines neuen Kontos die Probleme? Erstens ist das Erstellen einer neuen Account -Klasse eine genauere Beschreibung der realen Welt (was auch immer das ist). Natürlich ist etwas wirklich als ein Konto bekannt. Sparkonten und Girokonten sind Spezialfälle dieses grundlegenderen Konzepts.
Außerdem ist die Klasse Savings von Änderungen an der Klasse Checking (und umgekehrt) isoliert. Wenn die Bank eine grundlegende Änderung an allen Konten vornimmt, können Sie Konto ändern, und alle Unterklassen erben die Änderung automatisch. Wenn die Bank ihre Richtlinien jedoch nur für die Prüfung von Konten ändert, können Sie nur die Checking -Kontoklasse ändern, ohne die Einsparungen für zu beeinflussen.
Dieser Prozess des Aussortierens gemeinsamer Eigenschaften aus ähnlichen Klassen ist das Wesen des Klassen-Factoring .
Factoring ist nur dann legitim, wenn die Vererbungsbeziehung der Realität entspricht. Eine Klasse Maus und Joystick zusammen zu fassen, weil sie beide Hardware-Zeigegeräte sind, ist legitim. Das Zusammenfassen einer Klasse Maus und Anzeige , weil beide Low-Level-Betriebssystemaufrufe ausführen, ist dies nicht.
