Kā 6 gadus vecam bērnam izskaidrot objektorientētas programmēšanas koncepcijas

Vai esat pamanījuši, kā darba intervijās vienmēr tiek uzdoti vieni un tie paši klišejas jautājumi - atkal un atkal?

Es esmu pārliecināts, ka jūs zināt, ko es domāju.

Piemēram:

Kur jūs redzat sevi pēc pieciem gadiem?

vai, vēl sliktāk:

Ko jūs uzskatāt par savu lielāko vājumu?

Ugh ... dod man pārtraukumu. Es uzskatu, ka atbilde uz šo jautājumu ir liela vājība! Jebkurā gadījumā, ne mans viedoklis.

Lai cik mazsvarīgi būtu šādi jautājumi, tie ir svarīgi, jo tie sniedz norādes par jums. Jūsu pašreizējais prāta stāvoklis, attieksme, perspektīva.

Atbildot, jums vajadzētu būt piesardzīgam, jo ​​jūs varat atklāt kaut ko, ko vēlāk nožēlojat.

Šodien es vēlos runāt par līdzīga veida jautājumiem programmēšanas pasaulē:

Kādi ir galvenie uz objektu orientētās programmēšanas principi?

Esmu bijis šī jautājuma abās pusēs. Tā ir viena no tām tēmām, kas tiek uzdota tik bieži, ka nevar atļauties nezināt.

Parasti uz to jāatbild junioru un sākuma līmeņa izstrādātājiem. Jo tas ir vienkāršs veids, kā intervētājs var pateikt trīs lietas:

  1. Vai kandidāts gatavojās šai intervijai?

    Bonusa punkti, ja uzreiz dzirdat atbildi - tas parāda nopietnu pieeju.

  2. Vai kandidāts ir pagājis apmācības fāzē?

    Izprotot objektorientētās programmēšanas (OOP) principus, redzams, ka esat aizgājis pāri kopēšanai un ielīmēšanai no apmācībām - jūs jau redzat lietas no augstākas perspektīvas.

  3. Vai kandidāta izpratne ir dziļa vai sekla?

    Kompetences līmenis šajā jautājumā bieži vien ir kompetences līmenis lielākajā daļā citu priekšmetu . Uzticies man.

Četri objektorientētās programmēšanas principi ir iekapsulēšana , abstrakcija , mantošana ,un polimorfisms .

Šie vārdi var šķist biedējoši jaunākajam izstrādātājam. Un sarežģītie, pārmērīgi garie skaidrojumi Vikipēdijā dažkārt dubulto neskaidrības.

Tāpēc es vēlos sniegt vienkāršu, īsu un skaidru skaidrojumu katram no šiem jēdzieniem. Tas var izklausīties kā kaut kas, ko jūs paskaidrojat bērnam, bet es patiešām labprāt dzirdētu šīs atbildes, kad vadu interviju.

Iekapsulēšana

Sakiet, ka mums ir programma. Tam ir daži loģiski atšķirīgi objekti, kas savstarpēji sazinās - saskaņā ar programmā definētajiem noteikumiem.

Iekapsulēšana tiek sasniegta, kad katrs objekts klasē uztur savu privāto stāvokli . Citiem objektiem nav tiešas piekļuves šim stāvoklim. Tā vietā viņi var izsaukt tikai publisko funkciju sarakstu, ko sauc par metodēm.

Tātad objekts pārvalda savu stāvokli, izmantojot metodes - un neviena cita klase tam nevar pieskarties, ja vien tas nav skaidri atļauts. Ja vēlaties sazināties ar objektu, jums jāizmanto norādītās metodes. Bet (pēc noklusējuma) jūs nevarat mainīt stāvokli.

Pieņemsim, ka mēs veidojam nelielu Sims spēli. Ir cilvēki un ir kaķis. Viņi savstarpēji sazinās. Mēs vēlamies piemērot iekapsulēšanu, tāpēc visu “kaķu” loģiku iekapsulējam aCatklasē. Tas var izskatīties šādi:

Šeit "valsts" ir kaķis ir privātie mainīgiemood , hungryun energy. Tam ir arī privāta metode meow(). To var nosaukt, kad vien vēlas, pārējās klases nevar pateikt kaķim, kad jāņog.

Ko viņi var darīt, ir noteikts valsts metodessleep() , play()un feed(). Katrs no viņiem kaut kā modificē iekšējo stāvokli un var atsaukties meow(). Tādējādi tiek izveidota saikne starp privāto valsti un publiskajām metodēm.

Tā ir iekapsulēšana.

Abstrakcija

Abstrakciju var uzskatīt par iekapsulēšanas dabisku pagarinājumu.

Objektorientētā dizainā programmas bieži ir ārkārtīgi lielas. Un atsevišķi objekti daudz sazinās viens ar otru. Tāpēc ir grūti uzturēt šādu lielu koda bāzi gadiem ilgi - ar izmaiņām ceļā.

Abstrakcija ir jēdziens, kura mērķis ir mazināt šo problēmu.

Piemērojot ieguves nozīmē, ka katrs objekts ir tikai pakļauj augsta līmeņa mehānisms, lai izmantotu to.

Šim mehānismam vajadzētu slēpt iekšējās ieviešanas detaļas. Tam vajadzētu atklāt tikai darbības, kas attiecas uz citiem objektiem.

Padomājiet - kafijas automāts. Tas dara daudz lietu un rada kaprīzus trokšņus. Bet viss, kas jums jādara, ir jāievieto kafija un jānospiež poga.

Vēlams, lai šim mehānismam būtu viegli izmantot, un tas laika gaitā reti mainītos. Padomājiet par to kā par nelielu publisko metožu kopumu, ko jebkura cita klase var saukt, “nezinot”, kā viņi strādā.

Vēl viens reāls abstrakcijas piemērs dzīvē?

Padomājiet par to, kā izmantojat tālruni:

Jūs mijiedarbojaties ar tālruni, izmantojot tikai dažas pogas. Kas notiek zem pārsega? Jums tas nav jāzina - ieviešanas informācija ir paslēpta. Jums jāzina tikai īss darbību kopums.

Ieviešanas izmaiņas - piemēram, programmatūras atjauninājums - reti ietekmē jūsu izmantoto abstrakciju.

Mantojums

Labi, mēs redzējām, kā iekapsulēšana un abstrakcija var mums palīdzēt attīstīt un uzturēt lielu koda bāzi.

Bet vai jūs zināt, kāda ir vēl viena izplatīta problēma OOP dizainā?

Objekti bieži ir ļoti līdzīgi. Viņiem ir kopīga loģika. Bet viņi nav pilnīgi vienādi. Uh ...

Tātad, kā mēs atkārtoti izmantojam kopējo loģiku un iegūstam unikālo loģiku atsevišķā klasē? Viens no veidiem, kā to panākt, ir mantošana.

Tas nozīmē, ka jūs izveidojat (bērnu) klasi, iegūstot no citas (vecāku) klases. Tādā veidā mēs veidojam hierarhiju.

Bērnu klase atkārtoti izmanto visus vecāku klases laukus un metodes (kopējā daļa) un var īstenot savu (unikālā daļa).

Piemēram:

Ja mūsu programmai ir jāpārvalda valsts un privātie skolotāji, bet arī citi cilvēki, piemēram, studenti, mēs varam ieviest šo klases hierarhiju.

Tādā veidā katra klase pievieno tikai to, kas tai nepieciešams, vienlaikus atkārtoti izmantojot kopējo loģiku ar vecāku klasēm.

Polimorfisms

Mēs esam nonākuši līdz vissarežģītākajam vārdam! Polimorfisms grieķu valodā nozīmē “daudzas formas”.

Tātad mēs jau zinām mantojuma spēku un ar prieku to izmantojam. Bet nāk šī problēma.

Pieņemsim, ka mums ir vecāku klase un dažas bērnu klases, kuras no tās manto. Dažreiz mēs vēlamies izmantot kolekciju - piemēram, sarakstu -, kurā ir visu šo klašu sajaukums. Vai arī mums ir ieviesta metode vecāku klasei, taču mēs vēlētos to izmantot arī bērniem.

To var atrisināt, izmantojot polimorfismu.

Vienkārši sakot, polimorfisms dod iespēju izmantot klasi tieši tāpat kā tās vecākus, tāpēc nav sajaukšanas ar sajaukšanas veidiem.Bet katra bērnu klase saglabā savas metodes tādas, kādas tās ir.

Parasti tas notiek, definējot (vecāku) interfeisu, kas jāizmanto atkārtoti. Tajā ir izklāstīta virkne kopēju metožu. Tad katra bērnu klase īsteno savu šo metožu versiju.

Jebkurā laikā, kad kolekcija (piemēram, saraksts) vai metode sagaida vecāku gadījumu (kur ir izklāstītas kopīgas metodes), valoda rūpējas par kopējās metodes pareizas ieviešanas novērtēšanu - neatkarīgi no tā, kurš bērns tiek nodots.

Apskatiet ģeometrisko figūru ieviešanas skici. Viņi atkārtoti izmanto kopēju saskarni virsmas laukuma un perimetra aprēķināšanai:

Ņemot šos trīs skaitļus Mantojumu vecākiem Figure Interfaceļauj jums izveidot sarakstu ar jauktas triangles, circlesun rectangles. Un izturieties pret viņiem kā pret tāda paša veida priekšmetiem.

Tad, ja šajā sarakstā tiek mēģināts aprēķināt elementa virsmu, tiek atrasta un izpildīta pareizā metode. Ja elements ir trīsstūris, trīsstūrisCalculateSurface()tiek saukts. Ja tas ir aplis - tad cirlce'sCalculateSurface()tiek saukts. Un tā tālāk.

Ja jums ir funkcija, kas darbojas ar skaitli, izmantojot tā parametru, jums tā nav jādefinē trīs reizes - vienreiz trīsstūrim, aplim un taisnstūrim.

Jūs varat to definēt vienreiz un pieņemt a Figurekā arguments. Neatkarīgi no tā, vai iet garām trīsstūrim, aplim vai taisnstūrim - tik ilgi, kamēr tie tiek ieviesti CalculateParamter(), to veidam nav nozīmes.

Es ceru, ka tas palīdzēja. Darba intervijās varat tieši izmantot šos pašus skaidrojumus.

Ja jums šķiet kaut kas joprojām grūti saprotams - nevilcinieties jautāt zemāk esošajos komentāros.

Ko tālāk?

Gatavība atbildēt uz vienu no visu laiku interviju jautājumu klasikām ir lieliska - taču dažreiz jūs nekad neaicina uz interviju.

Tālāk es pievērsīšos tam, ko darba devēji vēlas redzēt pie jaunākā izstrādātāja un kā izcelties no pūļa, meklējot darbu.

Sekojiet līdzi.