Factoring och arv i C ++ - dummies

Begreppet arv, och därmed factoring, tillåter i C ++ en klass att erva egenskaper hos en basklass. Erfarenhet har ett antal syften; Den största fördelen med arv är förmågan att påpeka förhållandet mellan klasserna. Detta är det så kallade IS_A-förhållandet - en MicrowaveOven IS_A-ugn och saker som det.

Factoring är bra saker om du gör korrekta korrelationer. Till exempel verkar mikrovågsugnen mot konventionell ugnsförhållande naturligt. Hävdar att mikrovågsugn är en speciell typ av brödrost, och du är på väg för problem. Det är sant att de båda gör sakerna heta, de använder båda elen, och de finns båda i köket, men likheten slutar där - en mikrovågsugn kan inte göra toast och en brödrost kan inte göra nachos.

Att identifiera klasserna som är inneboende i ett problem och rita de korrekta relationerna mellan dessa klasser är en process som kallas factoring. (Ordet är relaterat till den aritmetik som du var tvungen att göra i grundskolan: factoring ut de minst gemensamma nämnarna, till exempel är 12 lika med 2 gånger 2 gånger 3.)

Så här kan du använda arv för att förenkla dina program med hjälp av ett bankkonto exempel. Antag att du blev ombedd att skriva ett enkelt bankprogram som implementerade begreppet ett sparkonto och ett checkkonto.

Objektorienterade programmerare har kommit med ett kortfattat sätt att beskriva de viktigaste punkterna i en klass i en ritning. Klasserna Checking och Savings visas i denna figur. (Detta är bara ett av flera sätt att grafiskt uttrycka samma sak.)

Kontrollerar och Besparingar. ">

Oberoende klasser Kontrollerar och Besparingar.

För att läsa den här siffran och de andra figurerna, kom ihåg följande:

• Den stora låda är klassen, med klassnamnet högst upp.

• Namnen i lådor är medlemsfunktioner.

• Namnen som inte finns i lådor är datamedlemmar.

• Namnen som sträcker sig delvis ut ur rutorna är offentligt tillgängliga medlemmar. det vill säga dessa medlemmar kan nås av funktioner som inte ingår i klassen eller någon av dess efterkommande. De medlemmar som är helt inuti lådan är inte tillgängliga utanför klassen.

• En tjock pil representerar IS_A-förhållandet.

• En tunn pil representerar HAS_A-förhållandet.

En bil IS_A Fordon , men en bil HAS_A Motor .

Du kan se i den första bilden att klasserna Checking och Savings har mycket gemensamt. Till exempel har båda klasserna en uttag () och insättning () medlemsfunktion.Eftersom de två klasserna inte är identiska, måste de förbli som separata klasser. (I en verklig bankansökan skulle de två klasserna vara mycket mer annorlunda än i det här exemplet.) Det borde fortfarande finnas ett sätt att undvika denna upprepning.

Du kan få en av dessa klasser att ärva från den andra. Besparingar har fler medlemmar än Kontrollerar så att du kan låta Besparingar ärva från Kontroll. Detta arrangemang visas i nästa bild.

Klassen Besparingar ärver alla medlemmar. Klassen kompletteras med tillägget av datamedlemen noWithdrawals och genom att tvinga bort funktionen () . Du måste åsidosätta återkallelse () eftersom reglerna för att ta ut pengar från ett sparkonto skiljer sig från dem som gäller för att ta ut pengar från ett checkkonto.

Besparingar implementeras som en underklass på Kontroll. ">

Besparingar implementeras som en underklass av Kontroll.

Även om att låta Besparingar ärva från Kontrollerar är arbetskrävande, är det inte helt tillfredsställande. Det största problemet är att det, som den vikt som anges på mitt körkort, felaktigt föreställer sanningen. Detta arvsförhållande innebär att ett sparkonto är en särskild typ av checkkonto, vilket det inte är.

Sådana företeelser är förvirrande för programmeraren, både dagens och morgondagens. Idag måste en programmerare som inte är bekant med våra programmeringsverktyg läsa och förstå vad vår kod gör. Vilseledande representationer är svåra att förena och förstå.

Dessutom kan sådana felaktigheter leda till problem på vägen. Antag exempelvis att banken ändrar sin policy med avseende på kontroll av konton. Säg att det bestämmer sig för att debitera en serviceavgift vid kontroll av konton endast om lägsta saldot sjunker under ett visst värde under månaden.

En sådan förändring kan enkelt hanteras med minimala ändringar i klassen Kontroll. Du måste lägga till en ny datamedlem i klassen Kontrollerar för att hålla reda på minsta balans under månaden. Låt oss gå ut på en lem och kalla det minimumBalans.

Men nu har du ett problem. Eftersom Besparingar ärver från Checkar, sparas den nya dataleden också. Det har ingen nytta för den här medlemmen eftersom lägsta saldot inte påverkar sparkonton, så det sitter bara där. Kom ihåg att varje kontokontobjekt har detta extra minimumBalans medlem. En extra data medlem kanske inte är en stor sak, men det ger ytterligare förvirring.

Ändras som denna ackumulera. Idag är det en extra data medlem - imorgon är det en ändrad medlemsfunktion. Så småningom tar sparkonto-klassen mycket extra bagage som endast gäller för kontroll av konton.

Nu kommer banken tillbaka och bestämmer sig för att ändra en sparmakspolicy. Detta kräver att du ändrar en viss funktion i Kontroll. Förändringar som detta i basklassen sprider sig automatiskt ner till underklassen om inte funktionen redan är överdriven i underklassen Besparingar.

Antag exempelvis att banken beslutar att ge bort brödrostar för varje insättning i kontokontot. Utan att banken (eller dess programmerare) vet det, kommer inlåning till att kontrollera konton automatiskt resultera i brödrostdonationer. Om du inte är mycket försiktig kan ändringar i Checking oväntat visas i Besparingar.

Hur kan du undvika dessa problem? Påstår att Checking är ett speciellt fall av Besparingar ändringar men löser inte vårt problem. Vad du behöver är en tredje klass (kallar det Konto, bara för grins) som förkroppsligar de saker som är vanliga mellan Kontrollera och Spara, som visas här.

Kontrollerar och Besparingar på en vanlig Konto klass. ">

Basing Kontrollerar och Besparingar på en vanlig Konto klass.

Lös problemet med hur man bygger ett nytt konto? Först skapar en ny konto klass en mer exakt beskrivning av den verkliga världen (vad som än är). Självklart finns det verkligen något som är känt som ett konto. Besparingar konton och checkkonton är speciella fall av detta mer grundläggande koncept.

Dessutom är klassen Besparingar isolerad från ändringar i klassen Kontroll (och vice versa). Om banken instituterar en grundläggande förändring av alla konton kan du ändra Konto, och alla underklasser kommer automatiskt att förvärva förändringen. Men om banken ändrar sin policy endast för att kontrollera konton, kan du bara ändra Checking kontoklassen utan att påverka Besparingar.

Denna process för att kasta gemensamma egenskaper från liknande klasser är kärnan i klass factoring .

Factoring är endast legitimt om arvsförhållandet motsvarar verkligheten. Att fakturera tillsammans en klass Mus och Joystick eftersom de är båda maskinvarupekdon är legitima. Att föra samman en klass Mus och Display eftersom de båda gör samtal på låg nivå operativsystem är inte.