Kuidas seletada objektorienteeritud programmeerimise mõisteid 6-aastasele lapsele

Kas olete märganud, kuidas tööintervjuudel küsitakse alati samu klišeelisi küsimusi - ikka ja jälle?

Olen kindel, et teate, mida mõtlen.

Näiteks:

Kus näete ennast viie aasta pärast?

või veelgi hullem:

Mida peate oma suurimaks nõrkuseks?

Uh ... anna mulle puhkust. Pean sellele küsimusele vastamist suureks nõrkuseks! Igatahes, mitte minu mõte.

Nii triviaalsed kui sellised küsimused ka ei ole, on need olulised, kuna annavad teie kohta vihjeid. Teie praegune meeleseisund, suhtumine, vaatenurk.

Vastates peaksite olema ettevaatlik, sest võite paljastada midagi, mida hiljem kahetsete.

Täna tahan rääkida sarnast tüüpi küsimustest programmeerimismaailmas:

Millised on objektorienteeritud programmeerimise peamised põhimõtted?

Olen olnud selle küsimuse mõlemal poolel. See on üks neist teemadest, mida küsitakse nii tihti, et te ei saa endale lubada, et te seda ei tea.

Tavaliselt peavad sellele vastama noorema ja algtaseme arendajad. Sest intervjueerijal on lihtne öelda kolme asja:

  1. Kas kandidaat valmistus selleks intervjuuks ette?

    Boonuspunktid, kui kuulete kohe vastust - see näitab tõsist lähenemist.

  2. Kas kandidaat on juhendamisetapist möödas?

    Objektorienteeritud programmeerimise (OOP) põhimõtete mõistmine näitab, et olete õppetööst kaugemale jõudnud kopeerimisest ja kleepimisest - te näete asju juba kõrgemast perspektiivist.

  3. Kas kandidaadi arusaam on sügav või madal?

    Selle küsimuse kompetentsuse tase võrdub sageli enamiku teiste ainete pädevuse tasemega . Usalda mind.

Objektorienteeritud programmeerimise neli põhimõtet on kapseldamine , abstraktsioon , pärimine ,ja polümorfism .

Need sõnad võivad nooremarendaja jaoks kõlada hirmutavalt. Ja Vikipeedia keerukad, liiga pikad selgitused kahekordistavad segadust.

Sellepärast tahan anda nende mõistete kohta lihtsa, lühikese ja selge selgituse. See võib kõlada nagu midagi, mida te lapsele seletate, kuid mulle meeldiks intervjuu läbiviimisel neid vastuseid kuulda.

Kapseldamine

Oletame, et meil on programm. Sellel on mõned loogiliselt erinevad objektid, mis suhtlevad omavahel - vastavalt programmis määratletud reeglitele.

Kapseldamine saavutatakse siis, kui iga objekt hoiab oma riiki klassi sees privaatsena . Teistel objektidel pole sellele olekule otsest juurdepääsu. Selle asemel saavad nad helistada ainult avalike funktsioonide loendile - nn meetoditele.

Niisiis, objekt haldab oma olekut meetodite abil - ja ükski teine ​​klass ei saa seda puudutada, kui see pole selgesõnaliselt lubatud. Kui soovite objektiga suhelda, peaksite kasutama pakutavaid meetodeid. Kuid (vaikimisi) ei saa te olekut muuta.

Oletame, et me ehitame pisikest simsi mängu. On inimesi ja on kass. Nad suhtlevad omavahel. Tahame rakendada kapseldamist, seega kapseldame kogu „kassi“ loogika a-ksCatklass. See võib välja näha järgmine:

Siin on "riik", et kass on privaatne muutujadmood , hungryja energy. Sellel on ka privaatne meetod meow(). See võib seda kutsuda siis, kui ta tahab, teised klassid ei saa kassile öelda, millal möllata.

Mida nad saavad teha on määratletud avaliku meetodeidsleep() , play()ja feed(). Igaüks neist muudab sisemist olekut kuidagi ja võib seda ka kasutada meow(). Seega tehakse sidumine erariigi ja avalike meetodite vahel.

See on kapseldamine.

Abstraktsioon

Abstraktsiooni võib pidada kapseldumise loomulikuks jätkuks.

Objektorienteeritud kujunduses on programmid sageli äärmiselt mahukad. Ja eraldi objektid suhtlevad omavahel palju. Niisiis on sellise suure koodibaasi säilitamine aastaid - muutuste teel - keeruline.

Abstraktsioon on mõte, mille eesmärk on seda probleemi leevendada.

Abstraktsiooni rakendamine tähendab, et iga objekt peaks selle kasutamiseks paljastama ainult kõrgetasemelise mehhanismi.

See mehhanism peaks peitma sisemise rakenduse üksikasjad. See peaks näitama ainult teiste objektide jaoks olulisi toiminguid.

Mõelge - kohvimasin. See teeb palju asju ja tekitab kapoti all omapäraseid hääli. Kuid peate vaid kohvi sisse panema ja nuppu vajutama.

Eelistatult peaks seda mehhanismi olema lihtne kasutada ja see peaks aja jooksul harva muutuma. Mõelge sellest kui väikesest kogusest avalikest meetoditest, mida iga teine ​​klass võib nimetada, ilma et ta oma toimimist teaks.

Veel üks abstraktsiooni näide reaalsest elust?

Mõelge oma telefoni kasutamisele:

Suhtlete telefoniga vaid mõne nupu abil. Mis kapoti all toimub? Te ei pea teadma - rakenduse üksikasjad on peidetud. Peate teadma ainult lühikesi toiminguid.

Rakenduse muudatused - näiteks tarkvarauuendus - mõjutavad teie kasutatud abstraktsiooni harva.

Pärand

OK, nägime, kuidas kapseldamine ja abstraktsioon aitab meil välja töötada ja säilitada suurt koodibaasi.

Kuid kas teate, mis on veel üks levinud probleem OOP-i kujundamisel?

Objektid on sageli väga sarnased. Neil on ühine loogika. Kuid nad pole täiesti ühesugused. Uhh

Niisiis, kuidas me levinud loogikat taaskasutada ja ainulaadse loogika eraldada eraldi klassi? Üks viis selle saavutamiseks on pärimine.

See tähendab, et loote (lapse) klassi tuletades teisest (vanema) klassist. Nii moodustame hierarhia.

Lapseklass kasutab taaskasutuseks kõiki vanemateklassi välju ja meetodeid (ühine osa) ning saab oma (ainulaadne osa) rakendada.

Näiteks:

Kui meie programm peab juhtima avalikke ja eraõpetajaid, aga ka teist tüüpi inimesi, näiteks õpilasi, saame selle klassi hierarhia rakendada.

Nii lisab iga klass ainult selle, mis on selle jaoks vajalik, samas kui taaskasutab vanemateklassidega ühist loogikat.

Polümorfism

Oleme jõudnud kõige keerulisema sõna juurde! Polümorfism tähendab kreeka keeles “palju kujundeid”.

Nii et me juba teame pärimise jõudu ja kasutame seda rõõmsalt. Kuid see probleem tuleb.

Oletame, et meil on vanemateklass ja mõned lasteklassid, mis sellest pärivad. Mõnikord soovime kasutada kogu - näiteks loendit -, mis sisaldab kõigi nende klasside segu. Või on meil vanemateklassi jaoks rakendatud meetod - kuid me tahaksime seda kasutada ka laste jaoks.

Selle saab lahendada polümorfismi abil.

Lihtsamalt öeldes annab polümorfism võimaluse kasutada klassi täpselt nagu tema vanem, seega pole segiajamist segatüüpidega.Kuid igas lasteklassis on oma meetodid alles.

Tavaliselt juhtub see korduvkasutatava (vanema) liidese määratlemisega. Selles tuuakse välja hulk levinud meetodeid. Seejärel rakendab iga lasteklass nendest meetoditest oma versiooni.

Iga kord, kui kogu (näiteks loetelu) või meetod eeldab vanema eksemplari (kus on välja toodud ühised meetodid), hoolitseb keel ühise meetodi õige rakendamise hindamise eest - olenemata sellest, milline laps on läbitud.

Heitke pilk geomeetriliste jooniste teostuse visandile. Nad kasutavad pinna ja perimeetri arvutamiseks uuesti ühist liidest:

Võttes need kolm arvud pärib vanema Figure Interfacevõimaldab teil luua nimekiri segatud triangles, circlesja rectangles. Ja kohtle neid nagu sama tüüpi esemeid.

Seejärel, kui selles loendis üritatakse elemendi pinda arvutada, leitakse õige meetod ja täidetakse see. Kui element on kolmnurk, siis kolmnurga omaCalculateSurface()kutsutakse. Kui see on ring - siis keerista omaCalculateSurface()kutsutakse. Ja nii edasi.

Kui teil on funktsioon, mis töötab joonisega selle parameetri abil, ei pea te seda kolm korda määratlema - üks kord kolmnurga, ringi ja ristküliku jaoks.

Saate selle üks kord määratleda ja nõustuda a Figureargumendina. Kas möödute kolmnurgast, ringist või ristkülikust - nii kaua kui need rakenduvad CalculateParamter(), pole nende tüüp oluline.

Loodan, et see aitas. Neid täpselt samu selgitusi saate otse kasutada tööintervjuudel.

Kui leiate midagi veel raskesti mõistetavat - küsige sellest allpool toodud kommentaarides.

Mis järgmiseks?

Valmisolek vastata ühele kõigi aegade intervjuuküsimuste klassikale on suurepärane - kuid mõnikord ei kutsuta teid kunagi intervjuule.

Järgmisena keskendun sellele, mida tööandjad nooremarendaja juures näha tahavad ja kuidas tööjahil massist eristuda.

Püsige lainel.