Sådan forklares objektorienterede programmeringskoncepter for en 6-årig

Har du bemærket, hvordan de samme clichespørgsmål altid bliver stillet ved jobinterviews - igen og igen?

Jeg er sikker på at du ved hvad jeg mener.

For eksempel:

Hvor ser du dig selv om fem år?

eller endnu værre:

Hvad anser du for at være din største svaghed?

Uh ... giv mig en pause. Jeg betragter det som en stor svaghed at besvare dette spørgsmål! I hvert fald ikke min pointe.

Så trivielle som spørgsmål som disse kan være, de er vigtige, fordi de giver spor om dig. Din nuværende sindstilstand, din holdning, dit perspektiv.

Når du svarer, skal du være forsigtig, da du måske afslører noget, du senere fortryder.

I dag vil jeg tale om en lignende type spørgsmål i programmeringsverdenen:

Hvad er hovedprincipperne for objektorienteret programmering?

Jeg har været på begge sider af dette spørgsmål. Det er et af de emner, der bliver spurgt så ofte, at du ikke kan tillade dig ikke at vide det.

Junior- og entry-level-udviklere skal normalt svare på det. Fordi det er en nem måde for intervieweren at fortælle tre ting:

  1. Forberedte kandidaten sig til dette interview?

    Bonuspoint, hvis du straks hører et svar - det viser en seriøs tilgang.

  2. Er kandidaten forbi tutorialsfasen?

    At forstå principperne for objektorienteret programmering (OOP) viser, at du er gået ud over kopiering og indsætning fra tutorials - du ser allerede ting fra et højere perspektiv.

  3. Er kandidatens forståelse dyb eller lav?

    Kompetenceniveauet på dette spørgsmål svarer ofte til niveauet for kompetence på de fleste andre emner . Stol på mig.

De fire principper for objektorienteret programmering er indkapsling , abstraktion , arv ,og polymorfisme .

Disse ord lyder måske skræmmende for en juniorudvikler. Og de komplekse, alt for lange forklaringer i Wikipedia fordobler undertiden forvirringen.

Derfor vil jeg give en enkel, kort og klar forklaring på hvert af disse begreber. Det lyder måske som noget, du forklarer for et barn, men jeg ville faktisk elske at høre disse svar, når jeg gennemfører et interview.

Indkapsling

Sig, at vi har et program. Det har et par logisk forskellige objekter, der kommunikerer med hinanden - i henhold til reglerne defineret i programmet.

Indkapsling opnås, når hvert objekt holder sin tilstand privat inden for en klasse. Andre objekter har ikke direkte adgang til denne tilstand. I stedet kan de kun kalde en liste over offentlige funktioner - kaldte metoder.

Så objektet styrer sin egen tilstand via metoder - og ingen anden klasse kan røre ved det, medmindre det udtrykkeligt er tilladt. Hvis du vil kommunikere med objektet, skal du bruge de angivne metoder. Men (som standard) kan du ikke ændre tilstanden.

Lad os sige, at vi bygger et lille simmespil. Der er mennesker, og der er en kat. De kommunikerer med hinanden. Vi ønsker at anvende indkapsling, så vi indkapsler al "kat" -logik til enCatklasse. Det kan se sådan ud:

Her er kattens “tilstand” de private variablermood , hungryog energy. Det har også en privat metode meow(). Det kan kalde det, når det vil, de andre klasser kan ikke fortælle katten, hvornår den skal miave.

Hvad de kan gøre er defineret i de offentlige metodersleep() , play()og feed(). Hver af dem ændrer den interne tilstand på en eller anden måde og kan påberåbe sig meow(). Således er bindingen mellem den private stat og de offentlige metoder skabt.

Dette er indkapsling.

Abstraktion

Abstraktion kan betragtes som en naturlig forlængelse af indkapsling.

I objektorienteret design er programmer ofte ekstremt store. Og separate objekter kommunikerer meget med hinanden. Så det er svært at opretholde en stor codebase i årevis - med ændringer undervejs -.

Abstraktion er et koncept, der sigter mod at lette dette problem.

Anvendelse af abstraktion betyder, at hvert objekt kun skal udsætte en mekanisme på højt niveau til brug af det.

Denne mekanisme skal skjule interne implementeringsoplysninger. Det skal kun afsløre operationer, der er relevante for de andre objekter.

Tænk - en kaffemaskine. Det gør en masse ting og laver skæve lyde under hætten. Men alt hvad du skal gøre er at lægge kaffe og trykke på en knap.

Fortrinsvis skal denne mekanisme være let at bruge og sjældent ændre sig over tid. Tænk på det som et lille sæt offentlige metoder, som enhver anden klasse kan kalde uden at "vide", hvordan de fungerer.

Et andet virkeligt eksempel på abstraktion?

Tænk over, hvordan du bruger din telefon:

Du interagerer med din telefon ved kun at bruge et par knapper. Hvad sker der under emhætten? Du behøver ikke at vide - implementeringsoplysninger er skjult. Du behøver kun at kende et kort sæt handlinger.

Implementeringsændringer - for eksempel en softwareopdatering - påvirker sjældent den abstraktion, du bruger.

Arv

OK, vi så, hvordan indkapsling og abstraktion kan hjælpe os med at udvikle og vedligeholde en stor codebase.

Men ved du, hvad der er et andet almindeligt problem i OOP-design?

Objekter er ofte meget ens. De deler fælles logik. Men de er ikke helt de samme. Ugh ...

Så hvordan genbruger vi den fælles logik og udtrækker den unikke logik i en separat klasse? En måde at opnå dette på er arv.

Det betyder, at du opretter en (barn) klasse ved at stamme fra en anden (forælder) klasse. På denne måde danner vi et hierarki.

Underklassen genbruger alle felter og metoder i overordnet klasse (fælles del) og kan implementere sin egen (unik del).

For eksempel:

Hvis vores program har brug for at administrere offentlige og private lærere, men også andre typer mennesker som studerende, kan vi implementere dette klassehierarki.

På denne måde tilføjer hver klasse kun det, der er nødvendigt for det, mens de genbruger fælles logik med de overordnede klasser.

Polymorfisme

Vi er nede på det mest komplekse ord! Polymorfisme betyder "mange former" på græsk.

Så vi kender allerede arvets kraft og bruger den med glæde. Men der kommer dette problem.

Sig, at vi har en overordnet klasse og et par børneklasser, der arver fra den. Nogle gange vil vi bruge en samling - for eksempel en liste - der indeholder en blanding af alle disse klasser. Eller vi har en metode implementeret til forældreklassen - men vi vil også gerne bruge den til børnene.

Dette kan løses ved hjælp af polymorfisme.

Kort sagt, polymorfisme giver en måde at bruge en klasse nøjagtigt som sin forælder, så der er ingen forveksling med blandingstyper.Men hver barneklasse holder sine egne metoder, som de er.

Dette sker typisk ved at definere en (overordnet) grænseflade, der skal genbruges. Det skitserer en masse almindelige metoder. Derefter implementerer hver barneklasse sin egen version af disse metoder.

Hver gang en samling (såsom en liste) eller en metode forventer en forekomst af forældrene (hvor almindelige metoder er beskrevet), sørger sproget for at evaluere den rigtige implementering af den fælles metode - uanset hvilket barn der passeres.

Se på en skitse af implementering af geometriske figurer. De genbruger en fælles grænseflade til beregning af overfladeareal og omkreds:

Under disse tre figurer arver den forælder Figure Interfacekan du oprette en liste over blandet triangles, circlesog rectangles. Og behandle dem som den samme type objekt.

Derefter, hvis denne liste forsøger at beregne overfladen for et element, bliver den korrekte metode fundet og udført. Hvis elementet er en trekant, er trekantensCalculateSurface()Hedder. Hvis det er en cirkel - så cirlce'sCalculateSurface()Hedder. Og så videre.

Hvis du har en funktion, der fungerer med en figur ved hjælp af dens parameter, behøver du ikke definere den tre gange - en gang for en trekant, en cirkel og et rektangel.

Du kan definere det en gang og acceptere en Figuresom et argument. Uanset om du passerer en trekant, en cirkel eller et rektangel - så længe de implementeres CalculateParamter(), betyder deres type ikke noget.

Jeg håber, det hjalp. Du kan bruge disse nøjagtige samme forklaringer direkte på jobinterviews.

Hvis du finder noget stadig svært at forstå - tøv ikke med at spørge i kommentarerne nedenfor.

Hvad er det næste?

At være parat til at besvare en af ​​klassespørgsmålsklassikerne hele tiden er fantastisk - men nogle gange bliver man aldrig kaldt til et interview.

Dernæst vil jeg fokusere på, hvad arbejdsgivere ønsker at se i en juniorudvikler, og hvordan man skiller sig ud fra mængden, når de søger job.

Bliv hængende.