Jeste li primijetili kako se ista pitanja o klišejima uvijek postavljaju na razgovorima za posao - uvijek iznova?
Sigurna sam da znate na što mislim.
Na primjer:
Gdje se vidite za pet godina?ili, još gore:
Što smatrate svojom najvećom slabošću?Uf ... daj mi predah. Odgovor na ovo pitanje smatram velikom slabošću! Svejedno, nije moja poanta.
Koliko god pitanja poput ovih bila trivijalna, ona su važna jer daju tragove o vama. Vaše trenutno stanje uma, vaš stav, vaša perspektiva.
Kad odgovarate, budite oprezni jer ćete možda otkriti nešto zbog čega ćete kasnije požaliti.
Danas želim razgovarati o sličnoj vrsti pitanja u svijetu programiranja:
Koji su glavni principi objektno orijentiranog programiranja?Bio sam s obje strane ovog pitanja. To je jedna od onih tema koja se toliko često pita da si ne možete dopustiti da ne znate.
Na to obično moraju odgovoriti mlađi i početni programeri. Jer je anketar jednostavan način da kaže tri stvari:
- Je li se kandidat pripremao za ovaj intervju?
Bonus bodovi ako odmah čujete odgovor - pokazuje ozbiljan pristup.
- Je li kandidat prošao fazu podučavanja?
Razumijevanje načela objektno orijentiranog programiranja (OOP) pokazuje da ste otišli dalje od kopiranja i lijepljenja iz vodiča - stvari već vidite iz više perspektive.
- Je li razumijevanje kandidata duboko ili plitko?
Razina kompetencije po ovom pitanju često je jednaka razini kompetencije za većinu ostalih predmeta . Vjeruj mi.
Četiri principa objektno orijentiranog programiranja su enkapsulacija , apstrakcija , nasljeđivanje ,i polimorfizam .
Ove riječi mogu zvučati zastrašujuće za mlađe programere. A složena, pretjerano duga objašnjenja u Wikipediji ponekad udvostruče zbrku.
Zato želim dati jednostavno, kratko i jasno objašnjenje za svaki od ovih pojmova. Možda zvuči kao nešto što djetetu objasnite, ali zapravo bih volio čuti ove odgovore kad provedem intervju.
Kapsulacija
Recimo da imamo program. Ima nekoliko logički različitih objekata koji međusobno komuniciraju - prema pravilima definiranim u programu.
Inkapsulacija se postiže kada svaki objekt drži svoje stanje privatnim , unutar klase. Ostali objekti nemaju izravan pristup ovom stanju. Umjesto toga, oni mogu pozvati samo popis javnih funkcija - nazvanih metoda.
Dakle, objekt upravlja vlastitim stanjem pomoću metoda - i nijedna ga druga klasa ne može dodirnuti ako to nije izričito dopušteno. Ako želite komunicirati s objektom, trebali biste se koristiti navedenim metodama. Ali (prema zadanim postavkama) ne možete promijeniti stanje.
Recimo da gradimo majušnu Sims igru. Postoje ljudi i postoji mačka. Međusobno komuniciraju. Želimo primijeniti enkapsulaciju, tako da svu "mačju" logiku enkapsuliramo uCatrazred. To može izgledati ovako:
Tu se „stanje” mačka je privatna varijablemood , hungrya energy. Ima i privatnu metodu meow(). Može ga nazvati kad god želi, ostali razredi ne mogu reći mački kada da mijauče.
Što mogu učiniti, definirano je u javnim metodamasleep() , play()i feed(). Svatko od njih nekako modificira unutarnje stanje i može se pozivati meow(). Tako je napravljena obveza između privatne državne i javne metode.
Ovo je inkapsulacija.
Apstrakcija
Apstrakciju možemo smatrati prirodnim produžetkom inkapsulacije.
U objektno orijentiranom dizajnu programi su često izuzetno veliki. I odvojeni predmeti puno međusobno komuniciraju. Stoga je teško održavati veliku bazu koda poput ove godinama - s promjenama na putu - teško.
Apstrakcija je koncept kojim se želi ublažiti ovaj problem.
Primjena apstrakcije znači da bi svaki objekt trebao izložiti samo mehanizam visoke razine za njegovu upotrebu.
Ovaj bi mehanizam trebao sakriti detalje o internoj provedbi. Treba otkriti samo operacije relevantne za ostale objekte.
Razmislite - aparat za kavu. Radi puno stvari i stvara neobične zvukove ispod haube. Ali sve što trebate je staviti kavu i pritisnuti tipku.
Poželjno je da ovaj mehanizam bude jednostavan za upotrebu i da se rijetko mijenja tijekom vremena. Shvatite to kao mali skup javnih metoda koje bilo koja druga klasa može nazvati, a da "ne zna" kako rade.
Još jedan stvarni primjer apstrakcije?
Razmislite o načinu na koji koristite telefon:
S telefonom komunicirate pomoću samo nekoliko gumba. Što se događa ispod haube? Ne morate znati - detalji implementacije su skriveni. Trebate znati samo kratki niz radnji.
Promjene u implementaciji - na primjer, ažuriranje softvera - rijetko utječu na apstrakciju koju koristite.
Nasljeđivanje
U redu, vidjeli smo kako nam enkapsulacija i apstrakcija mogu pomoći u razvoju i održavanju velike baze kodova.
No, znate li što je još jedan uobičajeni problem u dizajniranju OOP-a?
Predmeti su često vrlo slični. Oni dijele zajedničku logiku. Ali nisu potpuno isti. Uf ...
Pa kako ponovno upotrijebiti zajedničku logiku i izdvojiti jedinstvenu logiku u zasebnu klasu? Jedan od načina da se to postigne je nasljeđivanje.
To znači da ste stvorili (podređenu) klasu izvedenom iz druge (roditeljske) klase. Na taj način formiramo hijerarhiju.
Podređena klasa ponovno koristi sva polja i metode nadređene klase (zajednički dio) i može implementirati svoja (jedinstveni dio).
Na primjer:
Ako naš program treba upravljati javnim i privatnim učiteljima, ali i drugim vrstama ljudi poput učenika, možemo primijeniti ovu hijerarhiju razreda.
Na taj način svaka klasa dodaje samo ono što joj je potrebno, dok ponovno koristi zajedničku logiku s roditeljskim klasama.
Polimorfizam
Došli smo do najsloženije riječi! Polimorfizam na grčkom znači "mnogo oblika".
Dakle, već znamo snagu nasljeđa i rado je koristimo. Ali tu dolazi do ovog problema.
Recimo da imamo roditeljski razred i nekoliko podređenih razreda koji ga nasljeđuju. Ponekad želimo koristiti zbirku - na primjer popis - koja sadrži kombinaciju svih ovih klasa. Ili imamo metodu implementiranu za roditeljski razred - ali voljeli bismo je koristiti i za djecu.
To se može riješiti uporabom polimorfizma.
Jednostavno rečeno, polimorfizam daje način da se klasa koristi točno kao njezin roditelj, tako da nema zabune s vrstama miješanja.Ali svaki dječji razred drži vlastite metode kakve jesu.
To se obično događa definiranjem (nadređenog) sučelja koje će se ponovno koristiti. Opisuje hrpu uobičajenih metoda. Zatim svaka podređena klasa implementira svoju verziju ovih metoda.
Svaki put kada zbirka (poput popisa) ili metoda očekuje primjerak roditelja (gdje su istaknute uobičajene metode), jezik se brine o procjeni ispravne provedbe uobičajene metode - bez obzira na to koje je dijete dodano.
Pogledajte skicu provedbe geometrijskih figura. Ponovno koriste zajedničko sučelje za izračunavanje površine i opsega:
Nakon što je ove tri figure naslijediti od roditelja Figure Interfaceomogućuje stvaranje popisa mješovita triangles, circlesi rectangles. I ponašajte se prema njima kao prema istoj vrsti predmeta.
Zatim, ako ovaj popis pokušava izračunati površinu za element, pronalazi se i izvršava ispravna metoda. Ako je element trokut, trokutCalculateSurface()Zove se. Ako je to krug - onda cirlceCalculateSurface()Zove se. I tako dalje.
Ako imate funkciju koja operira sa figurom koristeći njen parametar, ne morate je definirati tri puta - jednom za trokut, krug i pravokutnik.
Možete ga jednom definirati i prihvatiti a Figurekao argument. Prolazite li pored trokuta, kruga ili pravokutnika - sve dok primjenjuju CalculateParamter(), njihov tip nije važan.
Nadam se da je ovo pomoglo. Ta potpuno ista objašnjenja možete izravno koristiti na razgovorima za posao.
Ako vam je nešto još uvijek teško razumjeti - nemojte se ustručavati pitati u komentarima ispod.
Što je sljedeće?
Spremnost za odgovor na jedno od klasičnih pitanja svih intervjua je sjajna - ali ponekad vas nikad ne pozovu na razgovor.
Dalje, usredotočit ću se na ono što poslodavci žele vidjeti kod mlađeg programera i na to kako se istaknuti iz mase prilikom traženja posla.
Pratite nas.
