Kaip paaiškinti objektyvaus programavimo koncepcijas 6 metų vaikui

Ar pastebėjote, kaip pokalbiuose dėl darbo visada užduodami tie patys klišiniai klausimai - vėl ir vėl?

Aš tikiu, kad žinote, ką turiu omenyje.

Pavyzdžiui:

Kur matai save po penkerių metų?

arba, dar blogiau:

Ką laikote didžiausia savo silpnybe?

Ugh ... duok man pailsėti. Manau, kad atsakymas į šį klausimą yra didelė silpnybė! Šiaip ar taip, ne mano mintis.

Kad ir kokie trivialūs gali būti tokie klausimai, jie yra svarbūs, nes suteikia užuominų apie jus. Jūsų dabartinė proto būsena, požiūris, perspektyva.

Atsakydami turėtumėte būti atsargūs, nes galite atskleisti tai, ko vėliau gailitės.

Šiandien noriu pakalbėti apie panašaus tipo klausimus programavimo pasaulyje:

Kokie yra pagrindiniai į objektą orientuoto programavimo principai?

Aš buvau abiejose šio klausimo pusėse. Tai viena iš tų temų, kurios klausinėjamos taip dažnai, kad negali sau leisti to nežinoti.

Į tai paprastai turi atsakyti jaunesniojo ir pradinio lygio kūrėjai. Nes tai paprastas būdas pašnekovui pasakyti tris dalykus:

  1. Ar kandidatas ruošėsi šiam pokalbiui?

    Premijos taškai, jei iškart išgirsite atsakymą - tai rodo rimtą požiūrį.

  2. Ar kandidatas praėjo mokymo etapą?

    Suprasti į objektą orientuoto programavimo (OOP) principus rodo, kad peržengėte ne tik kopijavimą ir įklijavimą iš vadovėlių - jau matote dalykus iš aukštesnės perspektyvos.

  3. Ar kandidato supratimas gilus, ar negilus?

    Kompetencijos lygis šiuo klausimu dažnai prilygsta daugumos kitų dalykų kompetencijos lygiui . Pasitikėk manimi.

Keturi objektinio programavimo principai yra kapsuliavimas , abstrakcija , paveldėjimas ,ir polimorfizmas .

Šie žodžiai gali pasirodyti baisūs jaunesniajam kūrėjui. O sudėtingi, pernelyg ilgi paaiškinimai Vikipedijoje kartais padvigubina painiavą.

Štai kodėl noriu pateikti paprastą, trumpą ir aiškų paaiškinimą kiekvienai iš šių sąvokų. Tai gali atrodyti kažkas, ką paaiškinsi vaikui, bet iš tikrųjų norėčiau išgirsti šiuos atsakymus, kai vesiu interviu.

Inkapsuliacija

Tarkime, kad turime programą. Jis turi keletą logiškai skirtingų objektų, kurie bendrauja tarpusavyje - pagal programoje apibrėžtas taisykles.

Kapsuliavimas pasiekiamas, kai kiekvienas objektas savo valstybę laiko privačia klasėje. Kiti objektai neturi tiesioginės prieigos prie šios būsenos. Vietoj to, jie gali iškviesti tik viešųjų funkcijų sąrašą, vadinamą metodais.

Taigi objektas valdo savo būseną metodais - ir jokia kita klasė negali jo liesti, nebent tai būtų aiškiai leidžiama. Jei norite bendrauti su objektu, turėtumėte naudoti pateiktus metodus. Bet (pagal numatytuosius nustatymus) negalite pakeisti būsenos.

Tarkime, mes kuriame mažą „Sims“ žaidimą. Yra žmonių ir yra katė. Jie bendrauja tarpusavyje. Mes norime pritaikyti inkapsuliaciją, todėl visą „katės“ logiką apjungiame aCatklasė. Tai gali atrodyti taip:

Čia "valstybė", kad katė yra privatūs kintamiejimood , hungryir energy. Tai taip pat turi privatų metodą meow(). Tai gali vadinti kada tik nori, kitos klasės negali pasakyti katei, kada miaukti.

Ką jie gali padaryti, tai apibrėžta viešųjų metodųsleep() , play()ir feed(). Kiekvienas iš jų kažkaip keičia vidinę būseną ir gali pasinaudoti meow(). Taigi tarp privačios valstybės ir viešųjų metodų privalomas ryšys.

Tai yra kapsuliavimas.

Abstrakcija

Abstrakcija gali būti laikoma natūraliu kapsulės pratęsimu.

Kuriant objektinį dizainą, programos dažnai būna itin didelės. Ir atskiri objektai daug bendrauja tarpusavyje. Taigi išlaikyti tokią didelę kodų bazę daugelį metų - kintant kelyje - sunku.

Abstrakcija yra sąvoka, kuria siekiama palengvinti šią problemą.

Taikant ėmimo reiškia, kad kiekvienas daiktas turi tik patirti aukšto lygio mechanizmą jį naudoti.

Šis mechanizmas turėtų paslėpti vidinę įgyvendinimo informaciją. Tai turėtų atskleisti tik su kitais objektais susijusias operacijas.

Pagalvok - kavos aparatas. Tai daro daugybę dalykų ir skleidžia keistus garsus po variklio dangčiu. Bet tereikia įdėti kavos ir paspausti mygtuką.

Pageidautina, kad šis mechanizmas būtų lengvai naudojamas ir laikui bėgant turėtų retai keistis. Pagalvokite apie tai kaip apie nedidelį viešųjų metodų rinkinį, kurį bet kuri kita klasė gali vadinti „nežinodama“, kaip jie veikia.

Kitas realus abstrakcijos pavyzdys?

Pagalvokite, kaip naudojatės telefonu:

Su telefonu bendraujate naudodami tik kelis mygtukus. Kas vyksta po gaubtu? Nereikia žinoti - išsami įgyvendinimo informacija yra paslėpta. Jums reikia žinoti tik trumpą veiksmų rinkinį.

Įgyvendinimo pakeitimai, pavyzdžiui, programinės įrangos atnaujinimas, retai veikia jūsų naudojamą abstrakciją.

Paveldėjimas

Gerai, mes matėme, kaip kapsuliavimas ir abstrakcija gali padėti mums sukurti ir išlaikyti didelę kodų bazę.

Bet ar žinote dar vieną dažnai pasitaikančią OOP dizaino problemą?

Objektai dažnai būna labai panašūs. Jie turi bendrą logiką. Bet jie nėra visiškai vienodi. Ugh ...

Taigi, kaip mes pakartotinai panaudosime bendrą logiką ir išskirsime unikalią logiką į atskirą klasę? Vienas iš būdų tai pasiekti yra paveldėjimas.

Tai reiškia, kad jūs sukursite (vaikų) klasę kilę iš kitos (tėvų) klasės. Tokiu būdu formuojame hierarchiją.

Vaiko klasė pakartotinai naudoja visus tėvų klasės laukus ir metodus (bendrą dalį) ir gali įgyvendinti savo (unikalią dalį).

Pavyzdžiui:

Jei mūsų programai reikia valdyti valstybinius ir privačius mokytojus, bet ir kitus žmones, pavyzdžiui, studentus, galime įgyvendinti šią klasių hierarchiją.

Tokiu būdu kiekviena klasė prideda tik tai, kas jai reikalinga, pakartotinai panaudojant bendrą logiką su tėvų klasėmis.

Polimorfizmas

Mes iki sudėtingiausio žodžio! Polimorfizmas graikų kalba reiškia „daug formų“.

Taigi mes jau žinome paveldėjimo galią ir mielai ja naudojamės. Tačiau kyla ši problema.

Tarkime, kad turime tėvų klasę ir keletą vaikų klasių, kurios paveldi ją. Kartais mes norime naudoti kolekciją, pavyzdžiui, sąrašą, kuriame yra visų šių klasių derinys. Arba mes turime metodą, pritaikytą tėvų klasei, tačiau norėtume jį naudoti ir vaikams.

Tai galima išspręsti naudojant polimorfizmą.

Paprasčiau tariant, polimorfizmas suteikia būdą naudoti klasę tiksliai taip, kaip jos tėvai, todėl nereikia painioti su maišymo tipais.Tačiau kiekviena vaikų klasė taiko savo metodus tokius, kokie yra.

Tai paprastai nutinka apibrėžiant (pirminę) sąsają, kuri bus naudojama pakartotinai. Jame išdėstyta krūva bendrų metodų. Tada kiekviena vaikų klasė įgyvendina savo šių metodų versiją.

Kiekvieną kartą, kai rinkinys (pvz., Sąrašas) ar metodas tikisi tėvų egzemplioriaus (kur aprašomi bendri metodai), kalba pasirūpina įvertinti tinkamą bendro metodo įgyvendinimą - nepaisant to, kuris vaikas yra išlaikytas.

Pažvelkite į geometrinių figūrų įgyvendinimo eskizą. Jie pakartotinai naudoja bendrą sąsają apskaičiuodami paviršiaus plotą ir perimetrą:

Atsižvelgdama į šiuos tris skaičius, paveldi iš tėvų Figure Interfaceleidžia jums sukurti mišraus sąrašą triangles, circlesir rectangles. Ir elkitės su jais kaip su tos pačios rūšies objektais.

Tada, jei šiame sąraše bandoma apskaičiuoti elemento paviršių, randamas ir vykdomas teisingas metodas. Jei elementas yra trikampis, trikampisCalculateSurface()vadinamas. Jei tai apskritimas - tada sukasiCalculateSurface()vadinamas. Ir taip toliau.

Jei turite funkciją, kuri veikia su figūra naudodama jos parametrą, neprivalote jos apibrėžti tris kartus - vieną kartą trikampiui, apskritimui ir stačiakampiui.

Galite tai apibrėžti vieną kartą ir priimti a Figurekaip argumentą. Nesvarbu, ar praeisite trikampį, apskritimą ar stačiakampį - tol, kol jie įgyvendinami CalculateParamter(), jų tipas nesvarbus.

Tikiuosi, kad tai padėjo. Darbo pokalbiuose galite tiesiogiai naudoti tuos pačius paaiškinimus.

Jei jums vis dar sunku suprasti - nedvejodami paklauskite toliau pateiktuose komentaruose.

Kas toliau?

Pasirengimas atsakyti į vieną iš visų laikų interviu klausimų klasikų yra puiku - tačiau kartais niekada nebūna pakviestas į interviu.

Toliau sutelsiu dėmesį į tai, ką darbdaviai nori pamatyti pas jaunesnįjį kūrėją ir kaip išsiskirti iš minios ieškant darbo.

Sekite naujienas.