Factoring og arv i C ++ - dummies

Begrepet arv, og dermed factoring, i C ++ tillater en klasse å arve egenskapene til en baseklasse. Arv har en rekke formål; Hovedfordelen med arv er evnen til å påpeke forholdet mellom klasser. Dette er det såkalte IS_A-forholdet - en MicrowaveOven IS_A Ovn og ting som det.

Factoring er gode ting hvis du gjør de riktige korrelasjonene. For eksempel virker mikrobølgeovn mot konvensjonelt ovnsforhold naturlig. Påstår at mikrobølgeovn er en spesiell slags brødrister, og du er på vei for problemer. Det er sant at de begge gjør ting varmt, de bruker begge strøm, og de er begge funnet på kjøkkenet, men likheten slutter der - en mikrobølgeovn kan ikke lage toast og en brødrister kan ikke lage nachos.

Identifisere klassene som er knyttet til et problem og tegne de riktige forholdene mellom disse klassene er en prosess kjent som factoring. (Ordet er relatert til aritmetikken som du ble tvunget til å gjøre i klasseskolen: factoring ut de minst vanlige nevnerne, for eksempel 12 er lik 2 ganger 2 ganger 3.)

Slik kan du bruke arv for å forenkle programmene dine ved hjelp av et bankkonto eksempel. Anta at du ble bedt om å skrive et enkelt bankprogram som implementerte begrepet en sparekonto og en kontrollkonto.

Objektorienterte programmerere har kommet opp på en kort måte å beskrive de viktigste poengene til en klasse i en tegning. Klassene Kontroller og Savings er vist i denne figuren. (Dette er bare en av flere måter å grafisk uttrykke det samme.)

Kontrollerer og Savings. ">

Uavhengige klasser Kontrollerer og Savings.

For å lese denne figuren og de andre tallene, husk følgende:

• Den store boksen er klassen, med klassenavnet øverst.

• Navnene i boksene er medlemsfunksjoner.

• Navnene som ikke er i boksene, er datamedlemmer.

• Navnene som strekker seg delvis ut av boksene, er offentlig tilgjengelige medlemmer; det vil si disse medlemmene kan nås av funksjoner som ikke er en del av klassen eller noen av dens etterkommere. De medlemmene som er helt inne i esken, er ikke tilgjengelige utenfor klassen.

• En tykk pil representerer IS_A-forholdet.

• En tynn pil representerer HAS_A-forholdet.

En bil IS_A-kjøretøy , men en bil HAS_A Motor .

Du kan se i første figur at Kontroller og Savings -klassene har mye til felles. For eksempel har begge klassene en tilbaketrekning () og innskudd () medlemsfunksjon.Fordi de to klassene ikke er identiske, må de forbli som separate klasser. (I en virkelig bankapplikasjon vil de to klassene være mye mer annerledes enn i dette eksemplet.) Likevel bør det være en måte å unngå denne repetisjonen på.

Du kan ha en av disse klassene arve fra den andre. Savings har flere medlemmer enn Kontrollerer slik at du kan la Savings arve fra Kontroll. Dette arrangementet er vist i denne neste figuren.

Klassen Savings arver alle medlemmene. Klassen er fullført med tillegg av datamedlemmet noWithdrawals og ved å overstyre funksjonstabellen () . Du må overstyre tilbaketrekning () fordi reglene for å trekke penger fra en sparekonto er forskjellig fra de som gjelder for å ta ut penger fra en kontrollkonto.

Savings implementert som en underklasse av Kontroll. ">

Savings implementert som en underklasse av Kontroll.

Selv om Savings arve fra Kontrollerer , er det arbeidsløs, er det ikke helt tilfredsstillende. Hovedproblemet er at det, som vekten som er oppført på kjørerkortet, forvirrer sannheten. Dette arveforholdet innebærer at en sparekonto er en spesiell type sjekkkonto, som det ikke er.

Slike feilrepresentasjoner er forvirrende for programmereren, både dagens og morgendagens. I dag må en programmerer som ikke er kjent med våre programmeringstricks, lese og forstå hva vår kode gjør. Misvisende representasjoner er vanskelige å forene og forstå.

I tillegg kan slike feilrepresentasjoner føre til problemer nedover veien. Anta for eksempel at banken endrer sin policy med hensyn til å sjekke kontoer. Si at den bestemmer seg for å belaste et serviceavgift ved å sjekke kontoer bare hvis minimumsbalansen faller under en gitt verdi i løpet av måneden.

En slik endring kan enkelt håndteres med minimal endring i klassen Kontroll. Du må legge til et nytt datamedlem i klassen Kontrollerer for å holde oversikt over minimumsbalansen i løpet av måneden. La oss gå ut på en lem og kaller det minimumBalanse.

Men nå har du et problem. Fordi Savings arver fra Checking, Savings blir også dette nye data medlemmet. Det har ingen bruk for dette medlemmet fordi minimumsbalansen ikke påvirker sparekontoer, så det sitter bare der. Husk at hvert kontrollkontoobjekt har dette ekstra minimumbalansen medlem. Et ekstra datalid kan ikke være en stor avtale, men det gir videre forvirring.

Endringer som dette akkumuleres. I dag er det et ekstra datamedlem - i morgen er det en endret medlemsfunksjon. Til slutt bærer sparekonto-klassen mye ekstra bagasje som bare gjelder for å sjekke kontoer.

Nå kommer banken tilbake og bestemmer seg for å endre litt sparingskonto. Dette krever at du endrer noen funksjon i Kontroll. Endringer som dette i grunnklassen forplanter seg automatisk til underklassen, med mindre funksjonen allerede er overskredet i underkategorien Savings.

For eksempel, anta at banken bestemmer seg for å gi bort brødristere for hvert innskudd på sjekkkontoen. Uten banken (eller programmene) som vet det, vil innskudd til å sjekke kontoer automatisk resultere i brødristerbidrag. Med mindre du er veldig forsiktig, kan endringer i Kontrollerer forekomme uventet i Savings.

Hvordan kan du unngå disse problemene? Hevder at Kontrollerer er et spesielt tilfelle av Savings endringer, men løser ikke vårt problem. Det du trenger er en tredje klasse (kall det Konto, bare for grin) som legemliggjør de tingene som er vanlige mellom Kontroller og Savings, som vist her.

Kontrollerer og Savings på en felles Konto klasse. ">

Basing Kontrollerer og Savings på en felles Konto klasse.

Hvordan løser du en ny konto med problemene? Først skaper du en ny konto klassen en mer nøyaktig beskrivelse av den virkelige verden (uansett hva det er). Selvfølgelig er det virkelig noe kjent som en konto. Sparekontoer og sjekkekontoer er spesielle tilfeller av dette mer grunnleggende konseptet.

I tillegg er klassen Savings isolert fra endringer i klassen Kontrollerer (og omvendt). Hvis banken institusjonerer en grunnleggende endring i alle kontoer, kan du endre Konto, , og alle underklasser vil automatisk arve endringen. Men hvis banken bare endrer sin policy for å sjekke kontoer, kan du bare endre Kontroller kontoklassen uten å påvirke Savings.

Denne prosessen med å kaste ut felles egenskaper fra lignende klasser er essensen av klasse factoring .

Factoring er kun legitimt hvis arveforholdet tilsvarer virkeligheten. Faktorer sammen en klasse Mus og Joystick fordi de er begge maskinvarepekerenhetene er legitime. Faktorer sammen en klasse Mus og Skjerm fordi de begge gjør ringe operativsystem samtaler er ikke.