Factoring und Vererbung in C ++

Das Konzept der Vererbung und damit Factoring, in C ++ ermöglicht eine Klasse die Eigenschaften einer Basisklasse erben. Vererbung hat eine Reihe von purposes- der Hauptvorteil der Vererbung ist die Fähigkeit, die Beziehung zwischen den Klassen zu zeigen. Dies ist die sogenannte IST EIN Beziehung - ein Mikrowellen IS_A Ofen und solche Sachen.

Factoring ist great stuff, wenn Sie die richtigen Zusammenhänge machen. Zum Beispiel scheint die Mikrowelle im Vergleich zu herkömmlichen Ofen Beziehung natürlich. Behaupten, dass Mikrowelle ist eine besondere Art von Toaster, und du bist für Ärger geleitet. Es stimmt, sie beide machen es heiß, sie beide Strom verbrauchen, und sie sind beide in der Küche gefunden, aber die Ähnlichkeit endet dort - eine Mikrowelle kann nicht Toast und Toaster nicht Nachos machen.

Die Identifizierung der Klassen inhärenten in einem Problem und zeichnen die richtigen Beziehungen zwischen diesen Klassen ist ein Prozess bekannt als Factoring. (Das Wort zum arithmetischen verwandt ist, dass Sie gezwungen wurden, in der Grundschule zu tun: das kleinste gemeinsame Nenner Ausklammerung zum Beispiel ist 12 gleich 2 mal 2 mal 3.)

Hier ist, wie Sie die Vererbung verwenden können Sie Ihre Programme mit einem Bankkonto Beispiel zu vereinfachen. Angenommen, Sie wurden gebeten, eine einfache Bank-Programm zu schreiben, die das Konzept eines Sparkontos und ein Girokonto umgesetzt.

Die objektorientierte Programmierer haben sich mit knapper Form die wichtigsten Punkte einer Klasse in einer Zeichnung zu beschreiben. Das Überprüfung und Ersparnisse Klassen sind in dieser Figur gezeigt. (Dies ist nur eine von mehreren Möglichkeiten, um graphisch das gleiche auszudrücken.)

Unabhängige Klassen & lt; i>Checkinglt; / i> und lt; i> Savings.lt; / i>
Unabhängige Klassen Überprüfung und Ersparnisse.

Um diese Zahl zu lesen und die anderen Figuren ist folgendes zu beachten:

  • Das große Feld ist die Klasse, mit dem Klassennamen an der Spitze.

  • Die Namen in den Feldern sind Member-Funktionen.

  • Die Namen in Kartons sind Datenelemente.

  • Die Namen, die aus den Boxen erweitern partway sind öffentlich zugängliche members-, die durch Funktionen ist, können diese Mitglieder zugegriffen werden, die nicht Teil der Klasse oder einer ihrer Abkömmlinge sind. Diejenigen Mitglieder, die vollständig innerhalb der Box sind nicht zugänglich sind von außerhalb der Klasse.

  • Ein dicker Pfeil stellt die IST EIN Beziehung.

  • Ein dünner Pfeil stellt die HAT EIN Beziehung.

EIN Auto IS_A Fahrzeug, aber ein Auto HAS_A Motor.

Sie können in der ersten Figur zu sehen, dass die Überprüfung und Ersparnisse Klassen haben viel gemeinsam. Zum Beispiel haben beide Klassen ein Rückzug() und Anzahlung() Member-Funktion. Da die beiden Klassen nicht identisch sind, jedoch müssen sie als separate Klassen bleiben. (In einem realen Bankanwendung, die beiden Klassen würde viel mehr anders sein als in diesem Beispiel). Dennoch sollte es eine Möglichkeit, diese Wiederholung zu vermeiden.

Sie könnte einer dieser Klassen von der anderen erben. Ersparnisse hat mehr Mitglieder als Überprüfung, so könnten Sie lassen Ersparnisse beerben Überprüfung. Diese Anordnung wird in der nächsten Abbildung dargestellt.

Das Ersparnisse Klasse erbt alle Mitglieder. Die Klasse wird mit der Zugabe des Datenelement abgeschlossen noWithdrawals und durch die Funktion überschreiben Rückzug(). Sie haben außer Kraft zu setzen Rückzug() weil die Regeln, Geld von einem Sparkonto zum Abziehen unterscheiden sich von denen für Geld von einem Girokonto zurückziehen.

& lt; i>Savingslt; / i> als eine Unterklasse implementiert von lt; i> Checking.lt; / i>
Ersparnisse implementiert als eine Unterklasse von Überprüfung.

Obwohl im Stich gelassen Ersparnisse beerben Überprüfung arbeitsspar ist, ist es nicht ganz befriedigend. Das Hauptproblem ist, dass, wie das Gewicht notiert an meinen Führerschein, es ist die Wahrheit entstellt. Diese Vererbungsbeziehung bedeutet, dass ein Sparkonto eine spezielle Art von Girokonto ist, was es nicht ist.

Solche Verdrehungen dem Programmierer, die beide heute und morgen sind verwirrend. Eines Tages wird ein Programmierer nicht vertraut mit unserer Programmierung Tricks zu lesen und zu verstehen, was unsere Code tut. Irreführende Darstellungen sind nur schwer in Einklang zu bringen und zu verstehen.

Darüber hinaus können solche falschen Darstellungen zu Problemen auf der Straße führen. Nehmen wir zum Beispiel, dass die Bank ändert ihre Politik in Bezug auf Girokonten. Sagen Sie es entscheidet auf Girokonten nur dann, wenn die Mindestguthaben Dips unter einen bestimmten Wert im Laufe des Monats eine Servicegebühr zu erheben.

Eine Änderung wie diese können leicht mit minimalen Änderungen an der Klasse behandelt werden Überprüfung. Sie werden ein neues Datenelement der Klasse hinzufügen müssen Überprüfung im Laufe des Monats Spur des minimalen Gleichgewicht zu halten. Lassen Sie uns auf einem Bein gehen und nennen es minimumBalance.

Aber jetzt haben Sie ein Problem. weil Ersparnisse Abgeleitet von Ersparnisse überprüfen auch wird diese neue Datenelement. Es hat keine Verwendung für dieses Mitglied, weil das Mindestguthaben nicht Sparkonten beeinflussen, so dass es sitzt nur da. Denken Sie daran, dass jedes Girokonto-Objekt hat diese zusätzliche minimumBalance Mitglied. Ein zusätzliches Datenelement kann keine große Sache, aber es fügt weitere Verwirrung.

Änderungen wie diese akkumulieren. Heute ist es ein zusätzliches Datenelement - morgen ist es eine veränderte Memberfunktion. Schließlich wird das Sparkonto Klasse eine Menge extra Gepäck tragen, die nur auf Girokonten anwendbar ist.

Jetzt kommt die Bank zurück und beschließt, einige Sparpolitik Konto zu ändern. Dies erfordert, dass Sie eine Funktion zu ändern in Überprüfung. Änderungen wie diese in der Basisklasse propagieren automatisch in die Unterklasse nach unten, wenn die Funktion bereits in der Unterklasse überschrieben wird Ersparnisse.

Angenommen, dass die Bank für jede Einzahlung Toastern zu verschenken entscheidet in das Girokonto. Ohne die Bank (oder seine Programmierer) es zu wissen, die Einlagen auf Girokonten würde automatisch in Toaster Spenden. Es sei denn, Sie sehr vorsichtig sind, ändert sich zu Überprüfung möglicherweise unerwartet erscheinen in Ersparnisse.

Wie kann man diese Probleme zu vermeiden? die Behauptung, dass Überprüfung ist ein Spezialfall von Ersparnisse Änderungen aber löst nicht unser Problem. Was Sie brauchen, eine dritte Klasse ist (nennen wir es Konto, nur für grinst), das verkörpert die Dinge, die zwischen gemeinsam sind Überprüfung und Ersparnisse, wie hier gezeigt.

Basing & lt; i>Checkinglt; / i> und lt; i> Savingslt; / i> auf einer gemeinsamen lt; i> Accountlt;. / i> Klasse
Basing Überprüfung und Ersparnisse auf einer gemeinsamen Konto Klasse.

Wie sieht den Bau eines neuen Kontos die Probleme zu lösen? Erstens die Schaffung eines neuen Konto Klasse ist eine genauere Beschreibung der realen Welt (was immer das ist). Natürlich gibt es wirklich etwas wie ein Konto bekannt. Sparkonten und Girokonten sind spezielle Fälle dieser grundsätzlichere Konzept.

Darüber hinaus ist die Klasse Ersparnisse von Änderungen an der Klasse isoliert Überprüfung (und umgekehrt). Wenn die Bankinstitute eine grundlegende Änderung auf alle Konten, die Sie ändern können Konto, und alle Unterklassen wird die Änderung automatisch erben. Aber wenn die Bank nur ihre Politik ändert Konten zur Überprüfung, können Sie ändern einfach die Überprüfung Kontoklasse ohne Beeinträchtigung Ersparnisse.

Dieser Prozess der Keulung gemeinsamen Eigenschaften von ähnlichen Klassen ist das Wesen der Klasse Factoring.

Factoring ist legitim, nur dann, wenn die Vererbungsbeziehung der Realität entspricht. Factoring zusammen eine Klasse Maus und Joystick weil sie beide Hardware Zeigegeräte sind, ist legitim. Factoring zusammen eine Klasse Maus und Anzeigen weil sie beide Low-Level-Betriebssystem Anrufe nicht.

Menü