Hvordan forklare objektorienterte programmeringskonsepter for en 6-åring

Har du lagt merke til hvordan de samme klisjespørsmålene alltid blir stilt ved jobbintervjuer - om og om igjen?

Jeg er sikker på at du vet hva jeg mener.

For eksempel:

Hvor ser du deg selv om fem år?

eller enda verre:

Hva anser du for å være din største svakhet?

Ugh ... gi meg en pause. Jeg anser det å svare på dette spørsmålet som en stor svakhet! Uansett, ikke poenget mitt.

Så trivielle som spørsmål som disse kan være, de er viktige fordi de gir ledetråder om deg. Din nåværende sinnstilstand, din holdning, ditt perspektiv.

Når du svarer, bør du være forsiktig, da du kan avsløre noe du senere angrer på.

I dag vil jeg snakke om en lignende type spørsmål i programmeringsverdenen:

Hva er hovedprinsippene for objektorientert programmering?

Jeg har vært på begge sider av dette spørsmålet. Det er et av de emnene som blir spurt så ofte at du ikke kan tillate deg å ikke vite.

Junior- og entry-level-utviklere må vanligvis svare på det. Fordi det er en enkel måte for intervjueren å fortelle tre ting:

  1. Forberedte kandidaten seg til dette intervjuet?

    Bonuspoeng hvis du hører et svar umiddelbart - det viser en seriøs tilnærming.

  2. Er kandidaten forbi opplæringsfasen?

    Å forstå prinsippene for objektorientert programmering (OOP) viser at du har gått utover kopiering og liming fra opplæringsprogrammer - du ser allerede ting fra et høyere perspektiv.

  3. Er kandidatens forståelse dyp eller grunne?

    Kompetansenivået på dette spørsmålet tilsvarer ofte kompetansenivået på de fleste andre fag . Stol på meg.

De fire prinsippene for objektorientert programmering er innkapsling , abstraksjon , arv ,og polymorfisme .

Disse ordene kan høres skummelt ut for en juniorutvikler. Og de komplekse, for lange forklaringene i Wikipedia dobler noen ganger forvirringen.

Derfor vil jeg gi en enkel, kort og tydelig forklaring på hvert av disse konseptene. Det høres kanskje ut som noe du forklarer for et barn, men jeg vil faktisk gjerne høre disse svarene når jeg gjennomfører et intervju.

Innkapsling

Si at vi har et program. Den har noen få logisk forskjellige objekter som kommuniserer med hverandre - i henhold til reglene som er definert i programmet.

Innkapsling oppnås når hvert objekt holder sin tilstand privat , innenfor en klasse. Andre objekter har ikke direkte tilgang til denne tilstanden. I stedet kan de bare ringe en liste over offentlige funksjoner - kalt metoder.

Så objektet styrer sin egen tilstand via metoder - og ingen andre klasser kan berøre den med mindre det er uttrykkelig tillatt. Hvis du vil kommunisere med objektet, bør du bruke metodene som er gitt. Men (som standard) kan du ikke endre tilstanden.

La oss si at vi bygger et lite Sims-spill. Det er mennesker og det er en katt. De kommuniserer med hverandre. Vi ønsker å bruke innkapsling, så vi innkapsler all "katt" -logikk i enCatklasse. Det kan se slik ut:

Her er "tilstanden" til katten de private variablenemood , hungryog energy. Den har også en privat metode meow(). Den kan kalle den når den vil, de andre klassene kan ikke fortelle katten når den skal mjau.

Hva de kan gjøre er definert i de offentlige metodenesleep() , play()og feed(). Hver av dem endrer den indre tilstanden på en eller annen måte og kan påberope seg meow(). Dermed blir bindingen mellom den private staten og offentlige metoder laget.

Dette er innkapsling.

Abstraksjon

Abstraksjon kan betraktes som en naturlig forlengelse av innkapsling.

I objektorientert design er programmene ofte ekstremt store. Og separate objekter kommuniserer mye med hverandre. Så å opprettholde en stor kodebase som dette i årevis - med endringer underveis - er vanskelig.

Abstraksjon er et konsept som tar sikte på å lette dette problemet.

Å bruke abstraksjon betyr at hvert objekt bare skal avsløre en mekanisme på høyt nivå for bruk av den.

Denne mekanismen skal skjule detaljer om interne implementeringer. Den skal bare avsløre operasjoner som er relevante for de andre objektene.

Tenk - en kaffemaskin. Det gjør mange ting og lager sære lyder under panseret. Men alt du trenger å gjøre er å legge i kaffe og trykke på en knapp.

Fortrinnsvis bør denne mekanismen være enkel å bruke og sjelden endres over tid. Tenk på det som et lite sett med offentlige metoder som enhver annen klasse kan kalle uten å "vite" hvordan de fungerer.

Et annet eksempel på abstraksjon i virkeligheten?

Tenk på hvordan du bruker telefonen:

Du samhandler med telefonen din ved å bruke bare noen få knapper. Hva skjer under panseret? Du trenger ikke vite - implementeringsdetaljer er skjult. Du trenger bare å vite et kort sett med handlinger.

Implementeringsendringer - for eksempel en programvareoppdatering - påvirker sjelden abstraksjonen du bruker.

Arv

OK, vi så hvordan innkapsling og abstraksjon kan hjelpe oss med å utvikle og opprettholde en stor kodebase.

Men vet du hva som er et annet vanlig problem i OOP-design?

Objekter er ofte veldig like. De deler felles logikk. Men de er ikke helt like. Uh ...

Så hvordan gjenbruker vi den vanlige logikken og trekker ut den unike logikken i en egen klasse? En måte å oppnå dette på er arv.

Det betyr at du oppretter en (barn) klasse ved å komme fra en annen (foreldre) klasse. På denne måten danner vi et hierarki.

Barneklassen gjenbruker alle felt og metoder i foreldreklassen (felles del) og kan implementere sin egen (unike del).

For eksempel:

Hvis programmet vårt trenger å administrere offentlige og private lærere, men også andre typer mennesker som studenter, kan vi implementere dette klassehierarkiet.

På denne måten legger hver klasse bare til det som er nødvendig for det mens de gjenbruker vanlig logikk med foreldreklassene.

Polymorfisme

Vi er nede på det mest komplekse ordet! Polymorfisme betyr "mange former" på gresk.

Så vi kjenner allerede arvets kraft og bruker den gjerne. Men det kommer dette problemet.

Si at vi har en foreldreklasse og noen få barneklasser som arver fra den. Noen ganger ønsker vi å bruke en samling - for eksempel en liste - som inneholder en blanding av alle disse klassene. Eller vi har en metode implementert for foreldreklassen - men vi vil også bruke den til barna.

Dette kan løses ved å bruke polymorfisme.

Enkelt sagt, polymorfisme gir en måte å bruke en klasse akkurat som foreldrene, så det er ingen forvirring med blandingstyper.Men hver barneklasse holder sine egne metoder som de er.

Dette skjer vanligvis ved å definere et (foreldre) grensesnitt som skal brukes på nytt. Den skisserer en rekke vanlige metoder. Deretter implementerer hver barneklasse sin egen versjon av disse metodene.

Hver gang en samling (for eksempel en liste) eller en metode forventer en forekomst av foreldrene (der vanlige metoder er skissert), tar språket seg til å evaluere riktig implementering av den vanlige metoden - uavhengig av hvilket barn som blir passert.

Ta en titt på en skisse av implementeringen av geometriske figurer. De gjenbruker et felles grensesnitt for beregning av overflateareal og omkrets:

Å ha disse tre tallene arve foreldrene Figure Interfacelar deg lage en liste over blandet triangles, circlesog rectangles. Og behandle dem som samme type gjenstand.

Deretter, hvis denne listen prøver å beregne overflaten for et element, blir den riktige metoden funnet og utført. Hvis elementet er en trekant, er det trekantCalculateSurface()er kalt. Hvis det er en sirkel - så cirlceCalculateSurface()er kalt. Og så videre.

Hvis du har en funksjon som fungerer med en figur ved å bruke parameteren, trenger du ikke å definere den tre ganger - en gang for en trekant, en sirkel og et rektangel.

Du kan definere det en gang og godta et Figuresom argument. Enten du passerer en trekant, sirkel eller et rektangel - så lenge de implementerer CalculateParamter(), betyr ikke typen deres noe.

Jeg håper dette hjalp. Du kan bruke disse nøyaktig samme forklaringene direkte på jobbintervjuer.

Hvis du finner noe som fortsatt er vanskelig å forstå - ikke nøl med å spørre i kommentarene nedenfor.

Hva blir det neste?

Å være forberedt på å svare på en av klassikerne til intervjuspørsmål er alltid bra - men noen ganger blir du aldri kalt til intervju.

Deretter vil jeg fokusere på hva arbeidsgivere vil se i en juniorutvikler og hvordan de skiller seg ut fra mengden når de jobber på jobb.

Følg med.