Kako 6-letniku razložiti objektno usmerjene koncepte programiranja

Ste že opazili, kako se na intervjujih za službo vedno znova postavljajo ista vprašanja o klišejih?

Prepričan sem, da veste, kaj mislim.

Na primer:

Kje se vidite čez pet let?

ali, še huje:

Kaj se vam zdi vaša največja slabost?

Uf ... daj mi počitek. Odgovor na to vprašanje se mi zdi velika slabost! Kakorkoli, ne moja poanta.

Kakor koli nepomembna so vprašanja, kot so ta, so pomembna, ker dajejo namige o vas. Vaše trenutno stanje duha, vaš odnos, vaša perspektiva.

Pri odgovarjanju bodite previdni, saj lahko razkrijete nekaj, česar boste kasneje obžalovali.

Danes želim govoriti o podobni vrsti vprašanj v programskem svetu:

Katera so glavna načela objektno usmerjenega programiranja?

Bil sem na obeh straneh tega vprašanja. To je ena tistih tem, ki se tako pogosto sprašuje, da si ne morete dovoliti, da ne veste.

Na to morajo običajno odgovoriti mladinski in začetni razvijalci. Ker anketar na preprost način pove tri stvari:

  1. Se je kandidat pripravljal na ta razgovor?

    Bonus točke, če takoj slišite odgovor - kažejo resen pristop.

  2. Je kandidat prešel fazo vaj?

    Razumevanje načel objektno usmerjenega programiranja (OOP) kaže, da ste presegli kopiranje in lepljenje iz vadnic - stvari že vidite z višje perspektive.

  3. Je kandidatovo razumevanje globoko ali plitvo?

    Raven usposobljenosti pri tem vprašanju je pogosto enaka stopnji usposobljenosti za večino drugih predmetov . Zaupaj mi.

Štiri načela objektno usmerjenega programiranja so kapsulacija , abstrakcija , dedovanje ,in polimorfizem .

Te besede se morda zdijo za mlajšega razvijalca zastrašujoče. In zapletena, predolga pojasnila v Wikipediji včasih podvojijo zmedo.

Zato želim dati preprosto, kratko in jasno razlago vsakega od teh konceptov. Morda se sliši kot nekaj, kar otroku razložite, vendar bi te odgovore dejansko rad slišal, ko bom opravil razgovor.

Kapsulacija

Recimo, da imamo program. Ima nekaj logično različnih predmetov, ki komunicirajo med seboj - v skladu s pravili, določenimi v programu.

Inkapsulacija se doseže, ko vsak objekt ohrani svoje stanje zasebno znotraj razreda. Drugi predmeti nimajo neposrednega dostopa do tega stanja. Namesto tega lahko pokličejo samo seznam javnih funkcij - imenovanih metod.

Torej objekt upravlja svoje stanje s pomočjo metod - in noben drug razred se ga ne more dotakniti, razen če je izrecno dovoljeno. Če želite komunicirati s predmetom, uporabite uporabljene metode. Toda (privzeto) ne morete spremeniti stanja.

Recimo, da gradimo majhno igro Sims. Obstajajo ljudje in obstaja mačka. Komunicirajo med seboj. Želimo uporabiti enkapsulacijo, zato vmešamo vso "mačjo" logiko v aCatrazred. Izgleda lahko takole:

Tu "stanje" mačka je v zasebni spremenljivkemood , hungryin energy. Ima tudi zasebno metodo meow(). Pokliče ga lahko kadar koli hoče, drugi razredi mački ne morejo povedati, kdaj naj mijavka.

Kaj lahko naredite, je opredeljena v javnih metodsleep() , play()in feed(). Vsak od njih nekako spremeni notranje stanje in se lahko sklicuje meow(). Tako je narejena vezava med zasebno državno in javno metodo.

To je kapsulacija.

Abstrakcija

Abstrakcijo lahko razumemo kot naravni podaljšek inkapsulacije.

Pri objektno usmerjenem oblikovanju so programi pogosto izredno veliki. In ločeni predmeti veliko komunicirajo med seboj. Tako je težko več let vzdrževati takšno kodno bazo - s spremembami na poti -.

Abstrakcija je koncept, ki želi olajšati ta problem.

Uporaba abstrakcije pomeni, da bi moral vsak predmet izpostaviti samo mehanizem na visoki ravni za njegovo uporabo.

Ta mehanizem bi moral skriti podrobnosti o notranji izvedbi. Razkrivati ​​mora le operacije, pomembne za druge predmete.

Pomislite - aparat za kavo. Naredi veliko stvari in pod pokrovom sproži čudne zvoke. Toda vse, kar morate storiti, je dati kavo in pritisniti gumb.

Po možnosti bi moral biti ta mehanizem enostaven za uporabo in se sčasoma redko spreminja. Pomislite na to kot na majhen nabor javnih metod, ki jih lahko pokliče kateri koli drug razred, ne da bi vedel, kako delujejo.

Še en resnični primer abstrakcije?

Pomislite, kako uporabljate telefon:

S telefonom komunicirate z uporabo le nekaj gumbov. Kaj se dogaja pod pokrovom motorja? Ni vam treba vedeti - podrobnosti o izvedbi so skrite. Poznati morate le kratek nabor dejanj.

Spremembe izvedbe - na primer posodobitev programske opreme - redko vplivajo na abstrakcijo, ki jo uporabljate.

Dedovanje

V redu, videli smo, kako nam lahko enkapsulacija in abstrakcija pomagata razviti in vzdrževati veliko kodno bazo.

Toda ali veste, kaj je še ena pogosta težava pri načrtovanju OOP?

Predmeti so si pogosto zelo podobni. Skupna jim je logika. Niso pa popolnoma enaki. Uf ...

Torej, kako ponovno uporabiti skupno logiko in izvleči edinstveno logiko v ločen razred? Eden od načinov, kako to doseči, je dedovanje.

To pomeni, da ustvarite (podrejeni) razred z izpeljavo iz drugega (nadrejenega) razreda. Na ta način oblikujemo hierarhijo.

Podrejeni razred ponovno uporabi vsa polja in metode nadrejenega razreda (skupni del) in lahko implementira svojega (unikatni del).

Na primer:

Če mora naš program voditi javne in zasebne učitelje, pa tudi druge vrste ljudi, kot so učenci, lahko uporabimo to hierarhijo razredov.

Na ta način vsak razred doda samo tisto, kar je zanj potrebno, ob ponovni uporabi skupne logike s starševskimi razredi.

Polimorfizem

Prišli smo do najbolj zapletene besede! Polimorfizem v grščini pomeni "veliko oblik".

Torej že poznamo moč dedovanja in jo z veseljem uporabljamo. Toda prihaja ta težava.

Recimo, da imamo roditeljski razred in nekaj podrejenih razredov, ki ga podedujejo. Včasih želimo uporabiti zbirko - na primer seznam -, ki vsebuje kombinacijo vseh teh razredov. Ali imamo metodo, ki je implementirana za nadrejeni razred - vendar bi jo radi uporabili tudi za otroke.

To lahko rešimo z uporabo polimorfizma.

Preprosto povedano, polimorfizem daje način za uporabo razreda natanko tako kot njegov nadrejeni, tako da ni nobene zamenjave z mešanjem vrst.Toda vsak otroški razred drži svoje metode, kakršne so.

To se običajno zgodi z določitvijo (nadrejenega) vmesnika, ki ga je treba ponovno uporabiti. Opisuje kup pogostih metod. Nato vsak podrejeni razred implementira svojo različico teh metod.

Kadar zbirka (na primer seznam) ali metoda pričakuje primerek nadrejenega (kjer so opisane običajne metode), jezik poskrbi za oceno pravilne izvedbe skupne metode - ne glede na to, kateri otrok je poslan.

Oglejte si skico izvedbe geometrijskih figur. Ponovno uporabljajo skupni vmesnik za izračun površine in oboda:

Ob teh treh številk podedoval od staršev, Figure Interfacevam omogoča, da ustvarite seznam mešani triangles, circlesin rectangles. In ravnajte z njimi kot z isto vrsto predmetov.

Če nato ta seznam skuša izračunati površino elementa, se najde in izvede pravilna metoda. Če je element trikotnik, trikotnikCalculateSurface()je poklican. Če je krog - potem cirlceCalculateSurface()je poklican. In tako naprej.

Če imate funkcijo, ki deluje s sliko s pomočjo njenega parametra, vam je ni treba določiti trikrat - enkrat za trikotnik, krog in pravokotnik.

Lahko ga določite enkrat in sprejmete a Figurekot argument. Ne glede na to, ali ste podali trikotnik, krog ali pravokotnik - če le-ti izvajajo CalculateParamter(), njihova vrsta ni pomembna.

Upam, da je to pomagalo. Popolnoma enaka pojasnila lahko neposredno uporabite na razgovorih za službo.

Če ste še vedno težko razumljivi - ne oklevajte in vprašajte v spodnjih komentarjih.

Kaj je naslednje?

Pripravljenost na odgovor na katero od klasičnih vprašanj o intervjuju je odlična - včasih pa te nikoli ne pokličejo na razgovor.

Nato se bom osredotočil na to, kaj želijo delodajalci videti pri mlajšem razvijalcu in kako izstopati iz množice pri iskanju zaposlitve.

Ostani na vezi.