Factoring en Inheritance in C ++ - dummies

Het concept van overerving, en dus factoring, in C ++ staat een klasse toe om de eigenschappen van een basisklasse te erven. Overname heeft een aantal doelen; het belangrijkste voordeel van overerving is het vermogen om de relatie tussen klassen te benadrukken. Dit is de zogenaamde IS_A-relatie - een magnetronoven IS_A-oven enzo.

Factoring is geweldig als je de juiste correlaties maakt. De verhouding tussen magnetron en conventionele oven lijkt bijvoorbeeld natuurlijk. Claim dat magnetron een speciaal soort broodrooster is en dat je op problemen stuit. Toegegeven, ze maken beide dingen warm, ze gebruiken allebei elektriciteit, en ze zijn allebei te vinden in de keuken, maar daar eindigt de overeenkomst - een magnetron kan geen toast maken en een broodrooster kan geen nacho's maken.

Het identificeren van de klassen die inherent zijn aan een probleem en het tekenen van de juiste relaties tussen deze klassen is een proces dat factoring wordt genoemd. (Het woord heeft betrekking op de rekenkunde die je op de basisschool moest doen: de minst voorkomende noemers worden meegerekend, bijvoorbeeld 12 is gelijk aan 2 keer 2 keer 3.)

Hier is hoe je kunt gebruiken overerving om uw programma's te vereenvoudigen met behulp van een voorbeeld van een bankrekening. Stel dat u werd gevraagd om een ​​eenvoudig bankprogramma te schrijven dat het concept van een spaarrekening en een betaalrekening implementeerde.

Object-georiënteerde programmeurs hebben een beknopte manier bedacht om de meest opvallende punten van een klasse in een tekening te beschrijven. De klassen Controleren en Besparingen worden weergegeven in deze afbeelding. (Dit is slechts een van de verschillende manieren om hetzelfde grafisch weer te geven.)

Besparingen controleren en. "> Onafhankelijke klassen

Sparen controleren en . Onthoud het volgende om deze figuur en de andere figuren te lezen:

De grote doos is de klasse, met de klassennaam bovenaan.

• De namen in vakjes zijn lidfuncties.

• De namen die niet in vakjes staan, zijn gegevensleden.

• De namen die zich tot halverwege de vakken uitstrekken zijn openbaar toegankelijke leden; dat wil zeggen, deze leden kunnen worden benaderd door functies die geen deel uitmaken van de klas of een van zijn nakomelingen. Die leden die volledig in de doos zitten, zijn niet toegankelijk van buiten de klas.

• Een dikke pijl vertegenwoordigt de IS_A-relatie.

• Een dunne pijl vertegenwoordigt de HAS_A-relatie.

• Een auto IS_A voertuig

, maar een auto HAS_A Motor . In de eerste afbeelding ziet u dat de klassen

Controleren en Besparingen veel gemeen hebben. Beide klassen hebben bijvoorbeeld een functie voor intrekking () en storting ().Omdat de twee klassen niet identiek zijn, moeten ze echter als afzonderlijke klassen blijven. (In een echte banktoepassing zouden de twee klassen heel wat anders zijn dan in dit voorbeeld.) Toch zou er een manier moeten zijn om deze herhaling te voorkomen. U kunt een van deze klassen van de andere klasse laten erven.

Besparingen heeft meer leden dan Controleren, , zodat u Besparingen kunt erven van Controleren. Dit arrangement wordt getoond in de volgende afbeelding. De

Besparingen -klasse erft alle leden. De klasse wordt aangevuld met de toevoeging van het gegevenslid noWithdrawals en door het opheffen van de functie () . U moet de opname () overschrijven omdat de regels voor het opnemen van geld van een spaarrekening anders zijn dan die voor het opnemen van geld van een betaalrekening. Besparingen

geïmplementeerd als een subklasse van Controleren. "> Besparingen

geïmplementeerd als een subklasse van Controleren. Hoewel verhuur

besparingen erven van Controleren werkt moeizaam, is het niet helemaal bevredigend. Het grootste probleem is dat het, net als het gewicht op mijn rijbewijs, de waarheid verkeerd voorstelt. Deze erfrechtverhouding houdt in dat een spaarrekening een speciaal type betaalrekening is, wat niet het geval is. Dergelijke verkeerde voorstellingen zijn verwarrend voor de programmeur, zowel van vandaag als morgen. Op een dag zal een programmeur die onze programmeertrucs niet kent, moeten lezen en begrijpen wat onze code doet. Misleidende voorstellingen zijn moeilijk te verzoenen en te begrijpen.

Bovendien kunnen dergelijke onjuiste voorstellingen op de weg tot problemen leiden. Stel bijvoorbeeld dat de bank haar beleid met betrekking tot het controleren van rekeningen wijzigt. Stel dat het besluit om servicekosten in rekening te brengen bij het controleren van rekeningen, als het minimumbedrag tijdens de maand onder een bepaalde waarde daalt.

Een verandering zoals deze kan eenvoudig worden afgehandeld met minimale wijzigingen in de klasse

Controleren. U moet een nieuw lid van de gegevens toevoegen aan de klas Controleren om het minimale saldo gedurende de maand bij te houden. Laten we uitgaan naar een ledemaat en het minimale evenwicht noemen. Maar nu heb je een probleem. Omdat besparingen

erft van controleren, besparingen krijgt dit nieuwe gegevenslid ook. Het heeft geen zin voor dit lid omdat het minimum saldo geen invloed heeft op spaarrekeningen, dus het zit er gewoon in. Vergeet niet dat elk betaalrekeningobject dit extra minimumBalance -lid heeft. Eén extra gegevenslid is misschien geen probleem, maar het voegt nog meer verwarring. Veranderingen zoals deze stapelen zich op. Vandaag is het een extra data-lid - morgen is het een gewijzigde ledenfunctie. Uiteindelijk draagt ​​de spaarrekeningklasse veel extra bagage die alleen van toepassing is op het controleren van rekeningen. Nu komt de bank terug en besluit een beleid voor spaarrekeningen te wijzigen. Dit vereist dat u een functie in

Controleren wijzigt.

Wijzigingen zoals deze in de basisklasse worden automatisch doorgevoerd naar de subklasse, tenzij de functie al is onderdrukt in de subklasse Besparingen. Stel dat de bank besluit om broodroosters weg te geven voor elke storting op de betaalrekening. Zonder dat de bank (of programmeurs) ervan op de hoogte zijn, zouden stortingen op betaalrekeningen automatisch resulteren in broodroosterdonaties. Tenzij u heel voorzichtig bent, kunnen wijzigingen in Controleren

onverwacht verschijnen in Besparingen. Hoe kunt u deze problemen voorkomen? Beweren dat Controleren

een speciaal geval is van Besparingen verandert, maar ons probleem niet oplost. Wat je nodig hebt is een derde klas (noem het Account, alleen voor grins) die de dingen belichaamt die veel voorkomen tussen Checking en Savings, zoals hier getoond. en

Besparingen controleren op een gewone account -klasse. "> Basen

en Besparingen controleren op een gewone account -klasse. Hoe lost het samenstellen van een nieuw account de problemen op? Ten eerste is het maken van een nieuwe Account

-klasse een nauwkeuriger beschrijving van de echte wereld (wat dat ook is). Natuurlijk is er echt iets bekend als een account. Spaarrekeningen en betaalrekeningen zijn speciale gevallen van dit meer fundamentele concept. Bovendien is de klasse Besparingen

geïsoleerd van wijzigingen in de klasse Controle (en omgekeerd). Als de bank een fundamentele wijziging in alle accounts instelt, kunt u Account, wijzigen en alle subklassen zullen de wijziging automatisch overnemen. Maar als de bank haar beleid alleen wijzigt voor het controleren van accounts, kunt u alleen de accountklasse Controleren wijzigen zonder Besparingen te beïnvloeden. Dit proces van het verwijderen van gemeenschappelijke eigenschappen uit vergelijkbare klassen is de essentie van klassenfactoren .

Factoring is alleen legitiem als de inheritance-relatie overeenkomt met de realiteit. Het samenvoegen van een klasse muis

en joystick omdat beide hardware-aanwijsapparaten legitiem zijn. Het samenvoegen van een klasse muis en beeldscherm , omdat ze beide op laag niveau oproepen van het besturingssysteem niet doen.