Kuinka selittää olio-ohjelmointikonseptit 6-vuotiaalle

Oletko huomannut, kuinka samoja kliseekysymyksiä kysytään aina työhaastatteluissa - yhä uudelleen?

Olen varma, että tiedät mitä tarkoitan.

Esimerkiksi:

Missä näet itsesi viiden vuoden kuluttua?

tai mikä vielä pahempaa:

Mitä pidät suurimpana heikkoutena?

Uh ... anna minulle tauko. Pidän vastaamista tähän kysymykseen suureksi heikkoudeksi! Joka tapauksessa, ei minun mielipiteeni.

Niin pieniä kuin nämä kysymyksetkin ovat, ne ovat tärkeitä, koska ne antavat vihjeitä sinusta. Nykyinen mielentila, asenne, näkökulma.

Vastatessasi sinun tulee olla varovainen, koska saatat paljastaa jotain, mitä myöhemmin kadut.

Tänään haluan puhua samanlaisesta kysymyksestä ohjelmointimaailmassa:

Mitkä ovat olio-ohjelmoinnin pääperiaatteet?

Olen ollut tämän kysymyksen molemmin puolin. Se on yksi niistä aiheista, joita kysytään niin usein, että et voi sallia itsesi olla tietämättä.

Juniori- ja lähtötason kehittäjien on yleensä vastattava siihen. Koska haastattelija on helppo tapa kertoa kolme asiaa:

  1. Valmistautuiko ehdokas tähän haastatteluun?

    Bonuspisteitä, jos kuulet vastauksen heti - se osoittaa vakavaa lähestymistapaa.

  2. Onko ehdokas ohittanut opetusvaiheen?

    Kohdepainotteisen ohjelmoinnin (OOP) periaatteiden ymmärtäminen osoittaa, että olet mennyt pidemmälle kuin kopiointi ja liittäminen opetusohjelmista - näet asiat jo korkeammasta perspektiivistä.

  3. Onko ehdokkaan ymmärrys syvä vai matala?

    Pätevyystaso tässä asiassa on usein sama kuin useimpien muiden aiheiden pätevyystaso . Luota minuun.

Objektiivisen ohjelmoinnin neljä periaatetta ovat kapselointi , abstraktio , perintö ,ja polymorfismi .

Nämä sanat saattavat kuulostaa pelottavalta nuoremmalle kehittäjälle. Ja monimutkaiset, liian pitkät selitykset Wikipediassa kaksinkertaistavat sekaannuksen.

Siksi haluan antaa yksinkertaisen, lyhyen ja selkeän selityksen kullekin näistä käsitteistä. Se saattaa kuulostaa siltä, ​​mitä selität lapselle, mutta haluaisin todella kuulla nämä vastaukset, kun suoritan haastattelun.

Kapselointi

Sano, että meillä on ohjelma. Siinä on muutama loogisesti erilainen objekti, jotka kommunikoivat keskenään - ohjelmassa määriteltyjen sääntöjen mukaisesti.

Kapselointi saavutetaan, kun jokainen objekti pitää tilansa yksityisenä luokan sisällä. Muilla esineillä ei ole suoraa pääsyä tähän tilaan. Sen sijaan he voivat kutsua vain luettelon julkisista toiminnoista - menetelmistä.

Joten, objekti hallitsee omaa tilaansa menetelmillä - eikä mikään muu luokka voi koskea siihen, ellei sitä nimenomaisesti sallita. Jos haluat olla yhteydessä objektiin, sinun tulee käyttää annettuja menetelmiä. Mutta (oletuksena) et voi muuttaa tilaa.

Oletetaan, että rakennamme pienen Sims-pelin. On ihmisiä ja on kissa. He kommunikoivat keskenään. Haluamme soveltaa kapselointia, joten kapseloimme kaiken "kissa" -logiikan a-muotoonCatluokassa. Se voi näyttää tältä:

Täällä ”tila” kissa on yksityinen muuttujiamood , hungryja energy. Sillä on myös yksityinen menetelmä meow(). Se voi kutsua sitä milloin tahansa, muut luokat eivät voi sanoa kissalle, milloin meow.

Mitä he voivat tehdä, on määritelty julkisen menetelmiäsleep() , play()ja feed(). Kukin niistä muuttaa jotenkin sisäistä tilaa ja voi vedota siihen meow(). Siten yksityisen valtion ja julkisten menetelmien välinen sitoutuminen tehdään.

Tämä on kapselointi.

Abstraktio

Abstraktio voidaan ajatella kapseloinnin luonnollisena jatkeena.

Kohdekeskeisessä suunnittelussa ohjelmat ovat usein erittäin suuria. Ja erilliset esineet kommunikoivat keskenään paljon. Joten tällaisen suuren koodikannan ylläpitäminen vuosien ajan - muutosten myötä - on vaikeaa.

Abstraktio on käsite, jonka tarkoituksena on helpottaa tätä ongelmaa.

Soveltamalla abstraktio tarkoittaa sitä, että kukin esine olisi vain paljastaa korkean tason mekanismi käyttää sitä.

Tämän mekanismin tulisi piilottaa sisäiset toteutustiedot. Sen pitäisi paljastaa vain muiden kohteiden kannalta merkitykselliset toiminnot.

Ajattele - kahvinkeitin. Se tekee paljon tavaraa ja tuottaa omituisia ääniä hupun alla. Mutta sinun tarvitsee vain laittaa kahvia ja painaa painiketta.

Tämän mekanismin tulisi mieluiten olla helppokäyttöinen ja sen tulisi muuttua harvoin ajan myötä. Ajattele sitä pienenä joukona julkisia menetelmiä, joita kuka tahansa muu luokka voi kutsua "tietämättä" miten ne toimivat.

Toinen tosielämän esimerkki abstraktiosta?

Mieti, miten käytät puhelintasi:

Olet vuorovaikutuksessa puhelimesi kanssa vain muutamalla painikkeella. Mitä hupun alla tapahtuu? Sinun ei tarvitse tietää - toteutuksen yksityiskohdat on piilotettu. Sinun on tiedettävä vain lyhyt joukko toimintoja.

Toteutusmuutokset - esimerkiksi ohjelmistopäivitys - vaikuttavat harvoin käyttöösi abstraktioon.

Perintö

OK, näimme kuinka kapselointi ja abstraktio voivat auttaa meitä kehittämään ja ylläpitämään isoa koodipohjaa.

Mutta tiedätkö mikä on toinen yleinen ongelma OOP-suunnittelussa?

Esineet ovat usein hyvin samankaltaisia. Heillä on yhteinen logiikka. Mutta he eivät ole täysin samanlaisia. Uh ...

Joten miten voimme käyttää yhteistä logiikkaa uudelleen ja purkaa ainutlaatuisen logiikan erilliseen luokkaan? Yksi tapa saavuttaa tämä on perintö.

Se tarkoittaa, että luot (lapsi) luokan seuraamalla toista (vanhempi) luokkaa. Tällä tavalla muodostamme hierarkian.

Lapsiluokassa käytetään uudelleen kaikkia vanhempaluokan kenttiä ja menetelmiä (yhteinen osa) ja voidaan toteuttaa omat (ainutlaatuinen osa).

Esimerkiksi:

Jos ohjelmamme on hallinnoitava julkisia ja yksityisiä opettajia, mutta myös muita ihmisiä, kuten opiskelijoita, voimme toteuttaa tämän luokkahierarkian.

Tällä tavoin kukin luokka lisää vain sen tarpeen, kun taas käytetään uudelleen yhteistä logiikkaa vanhempien luokkien kanssa.

Polymorfismi

Olemme alas monimutkaisimmasta sanasta! Polymorfismi tarkoittaa kreikan kielellä "monia muotoja".

Joten me tiedämme jo perinnön voiman ja käytämme sitä mielelläni. Mutta tämä ongelma tulee.

Sano, että meillä on vanhempaluokka ja muutama lapsiluokka, jotka perivät siitä. Joskus haluamme käyttää kokoelmaa - esimerkiksi luetteloa -, joka sisältää sekoituksen kaikista näistä luokista. Tai meillä on menetelmä vanhempaluokalle - mutta haluaisimme käyttää sitä myös lapsille.

Tämä voidaan ratkaista käyttämällä polymorfismia.

Yksinkertaisesti sanottuna polymorfismi antaa tavan käyttää luokkaa täsmälleen kuten sen vanhempi, joten sekoitustyyppien kanssa ei ole sekaannusta.Mutta jokainen lapsiluokka pitää omat menetelmänsä sellaisina kuin ne ovat.

Tämä tapahtuu tyypillisesti määrittelemällä uudelleenkäytettävä (pää) käyttöliittymä. Siinä hahmotellaan joukko yleisiä menetelmiä. Sitten jokainen lapsiluokka toteuttaa oman versionsa näistä menetelmistä.

Aina kun kokoelma (kuten luettelo) tai menetelmä odottaa vanhemman esiintymää (jossa yleiset menetelmät on hahmoteltu), kieli huolehtii yhteisen menetelmän oikean toteutuksen arvioinnista riippumatta siitä, mikä lapsi hyväksytään.

Katso luonnos geometristen kuvien toteutuksesta. Ne käyttävät uudelleen yhteistä rajapintaa pinta-alan ja kehän laskemiseen:

Ottaa nämä kolme luvut periä vanhemman Figure Interfacevoit luoda listan sekoittaa triangles, circlesja rectangles. Ja kohtele heitä kuin samantyyppisiä esineitä.

Jos tämä luettelo yrittää laskea elementin pinnan, oikea menetelmä löydetään ja suoritetaan. Jos elementti on kolmio, kolmionCalculateSurface()kutsutaan. Jos se on ympyrä - sitten pyörreCalculateSurface()kutsutaan. Ja niin edelleen.

Jos sinulla on funktio, joka toimii kuvan kanssa sen parametrin avulla, sinun ei tarvitse määrittää sitä kolme kertaa - kerran kolmion, ympyrän ja suorakulmion kohdalla.

Voit määrittää sen kerran ja hyväksyä a Figureargumenttina. Ohitatko kolmion, ympyrän tai suorakulmion - CalculateParamter()niiden tyypillä ei ole merkitystä, kunhan ne toteutetaan .

Toivon, että tämä auttoi. Voit käyttää näitä samoja selityksiä suoraan työhaastatteluissa.

Jos löydät jotain edelleen vaikeasti ymmärrettävää - älä epäröi kysyä alla olevista kommenteista.

Mitä seuraavaksi?

Valmistautuminen vastaamaan yhteen kaikkien aikojen haastatteluklassikoista on hienoa - mutta joskus et koskaan kutsu haastatteluun.

Seuraavaksi keskityn siihen, mitä työnantajat haluavat nähdä juniorikehittäjässä ja kuinka erottua joukosta työnhaun yhteydessä.

Pysy kanavalla.