de Alexander Petkov

Ați observat cum se pun mereu aceleași întrebări clișeu la interviurile de angajare – mereu și iar?

Sunt sigur că știi la ce mă refer.

De exemplu:

Unde te vezi peste cinci ani?

sau, și mai rău:

Care consideri că este cea mai mare slăbiciune a ta?

Uf … dă-mi o pauză. Răspunsul la această întrebare consider o mare slăbiciune! Oricum, nu punctul meu de vedere.

ad-banner

Oricât de banale ar fi aceste întrebări, ele sunt importante, deoarece oferă indicii despre tine. Starea ta mentală actuală, atitudinea ta, perspectiva ta.

Când răspundeți, ar trebui să fiți atenți, deoarece puteți dezvălui ceva pe care îl regretați ulterior.

Astăzi vreau să vorbesc despre un tip similar de întrebare din lumea programării:

Care sunt principiile principale ale programării orientate pe obiecte?

Am fost de ambele părți ale acestei întrebări. Este unul dintre acele subiecte care se întreabă atât de des încât nu îți poți permite să nu știi.

Dezvoltatorii junior și entry-level trebuie să răspundă de obicei. Pentru că intervievatorul este o modalitate ușoară de a spune trei lucruri:

  1. S-a pregătit candidatul pentru acest interviu?
    Puncte bonus dacă auziți un răspuns imediat – arată o abordare serioasă.
  2. Candidatul a trecut de faza de tutorial?
    Înțelegerea principiilor programării orientate pe obiecte (OOP) arată că ați trecut dincolo de copiere și lipire din tutoriale – vedeți deja lucrurile dintr-o perspectivă superioară.
  3. Înțelegerea candidatului este profundă sau superficială?
    Nivelul de competență pentru această întrebare este adesea egal cu nivelul de competență pentru majoritatea celorlalte materii. Aveți încredere în mine.
Cum sa explicam conceptele de programare orientate pe obiecte unui
Cum arată un dezvoltator entry-level după ce a pus această întrebare!

Cele patru principii ale programării orientate pe obiecte sunt încapsularea, abstractizare, moştenire, și polimorfism.

Aceste cuvinte pot părea înfricoșătoare pentru un dezvoltator junior. Iar explicațiile complexe, excesiv de lungi din Wikipedia, dublează uneori confuzia.

De aceea vreau să ofer o explicație simplă, scurtă și clară pentru fiecare dintre aceste concepte. Poate suna ca ceva ce îi explici unui copil, dar mi-ar plăcea să aud aceste răspunsuri atunci când conduc un interviu.

Conţinut

Incapsularea

Să spunem că avem un program. Are câteva obiecte diferite din punct de vedere logic, care comunică între ele – conform regulilor definite în program.

Incapsularea se realizează atunci când fiecare obiect își păstrează starea privat, în interiorul unei clase. Alte obiecte nu au acces direct la această stare. În schimb, ei pot apela doar o listă de funcții publice – numite metode.

Deci, obiectul își gestionează propria stare prin metode – și nicio altă clasă nu o poate atinge decât dacă este permis în mod explicit. Dacă doriți să comunicați cu obiectul, ar trebui să utilizați metodele furnizate. Dar (în mod implicit), nu puteți schimba starea.

Să presupunem că construim un mic joc Sims. Sunt oameni și există o pisică. Ei comunică între ei. Vrem să aplicăm încapsularea, deci încapsulăm întreaga logică „pisică” într-un Cat clasă. Poate arăta astfel:

Cum sa explicam conceptele de programare orientate pe obiecte unui
Puteți hrăni pisica. Dar nu poți schimba direct cât de foame este pisica.

Aici „starea” pisicii este variabile private mood, hungry și energy. Are și o metodă privată meow(). Poate suna ori de câte ori vrea, celelalte clase nu pot spune pisicii când trebuie să miaune.

Ce pot face este definit în metode publice sleep(), play() și feed(). Fiecare dintre ele modifică cumva starea internă și poate invoca meow(). Astfel, se face legătura între statul privat și metodele publice.

Aceasta este încapsularea.

Abstracție

Abstracția poate fi gândită ca o extensie naturală a încapsulării.

În proiectarea orientată pe obiecte, programele sunt adesea extrem de mari. Și obiectele separate comunică foarte mult între ele. Așadar, este dificil să menții o bază de cod mare așa de ani de zile – cu schimbări pe parcurs.

Abstracția este un concept care vizează ușurarea acestei probleme.

Aplicarea abstractizării înseamnă că fiecare obiect ar trebui numai expuneți un mecanism la nivel înalt pentru utilizarea acestuia.

Acest mecanism ar trebui să ascundă detaliile interne de implementare. Ar trebui să dezvăluie doar operațiuni relevante pentru celelalte obiecte.

Gândiți-vă – un aparat de cafea. Face multe lucruri și face zgomote ciudate sub capotă. Dar tot ce trebuie să faceți este să puneți cafea și să apăsați un buton.

De preferință, acest mecanism ar trebui să fie ușor de utilizat și să se schimbe rar în timp. Gândiți-vă la acesta ca la un set mic de metode publice pe care orice altă clasă le poate numi fără a „ști” cum funcționează.

Un alt exemplu real de abstractizare?
Gândiți-vă la modul în care utilizați telefonul:

1611741487 746 Cum sa explicam conceptele de programare orientate pe obiecte unui
Telefoanele mobile sunt complexe. Dar utilizarea lor este simplă.

Interacționați cu telefonul dvs. utilizând doar câteva butoane. Ce se întâmplă sub capotă? Nu trebuie să știți – detaliile implementării sunt ascunse. Trebuie doar să cunoașteți un set scurt de acțiuni.

Modificările de implementare – de exemplu, o actualizare software – afectează rareori abstractizarea pe care o utilizați.

Moştenire

OK, am văzut cum încapsularea și abstractizarea ne pot ajuta să dezvoltăm și să menținem o bază de cod mare.

Dar știți care este o altă problemă obișnuită în proiectarea OOP?

Obiectele sunt adesea foarte asemănătoare. Împărtășesc logica comună. Dar nu sunt în întregime la fel. Uf …

Deci, cum reutilizăm logica comună și extragem logica unică într-o clasă separată? O modalitate de a realiza acest lucru este moștenirea.

Înseamnă că creați o clasă (copil) derivând dintr-o altă clasă (părinte). În acest fel, formăm o ierarhie.

Clasa copil reutilizează toate câmpurile și metodele clasei părinte (partea comună) și își poate implementa propria (parte unică).

De exemplu:

1611741487 891 Cum sa explicam conceptele de programare orientate pe obiecte unui
Un profesor privat este un tip de profesor. Și orice profesor este un tip de persoană.

Dacă programul nostru trebuie să gestioneze profesori publici și privați, dar și alte tipuri de oameni, cum ar fi studenții, putem implementa această ierarhie de clase.

În acest fel, fiecare clasă adaugă doar ceea ce este necesar pentru ea, în timp ce reutilizează logica comună cu clasele părinte.

Polimorfism

Am ajuns la cel mai complex cuvânt! Polimorfismul înseamnă „multe forme” în greacă.

Deci, știm deja puterea moștenirii și o folosim cu fericire. Dar vine această problemă.

Să presupunem că avem o clasă părinte și câteva clase copil care moștenesc de la ea. Uneori dorim să folosim o colecție – de exemplu o listă – care conține un amestec de toate aceste clase. Sau avem o metodă implementată pentru clasa părinte – dar am dori să o folosim și pentru copii.

Acest lucru poate fi rezolvat prin utilizarea polimorfismului.

Pur și simplu, polimorfismul oferă o modalitate de a utiliza o clasă exact ca părintele său, astfel încât nu există confuzie cu tipurile de amestecare. Dar fiecare clasă de copii își păstrează propriile metode așa cum sunt.

Acest lucru se întâmplă de obicei prin definirea unei interfețe (părinte) pentru a fi reutilizată. Acesta prezintă o grămadă de metode comune. Apoi, fiecare clasă de copii își implementează propria versiune a acestor metode.

De fiecare dată când o colecție (cum ar fi o listă) sau o metodă așteaptă o instanță a părintelui (unde sunt evidențiate metodele comune), limbajul se ocupă de evaluarea implementării corecte a metodei comune – indiferent de ce copil este trecut.

Aruncați o privire la o schiță a implementării figurilor geometrice. Acestea reutilizează o interfață comună pentru calcularea suprafeței și a perimetrului:

1611741487 453 Cum sa explicam conceptele de programare orientate pe obiecte unui
Triunghiul, cercul și dreptunghiul pot fi utilizate acum în aceeași colecție

Având aceste trei figuri care moștenesc părintele Figure Interface vă permite să creați o listă de mixte triangles, circles, și rectangles. Și tratați-le ca pe același tip de obiect.

Apoi, dacă această listă încearcă să calculeze suprafața unui element, metoda corectă este găsită și executată. Dacă elementul este un triunghi, al triunghiului CalculateSurface() se numește. Dacă este un cerc – atunci cercul lui CalculateSurface() se numește. Si asa mai departe.

Dacă aveți o funcție care funcționează cu o figură folosind parametrul său, nu trebuie să o definiți de trei ori – o dată pentru un triunghi, un cerc și un dreptunghi.

Puteți să-l definiți o dată și să acceptați un Figure ca argument. Indiferent dacă treceți un triunghi, un cerc sau un dreptunghi – atâta timp cât acestea sunt implementate CalculateParamter(), tipul lor nu contează.

Sper că acest lucru a ajutat. Puteți utiliza direct aceleași explicații exact la interviurile de angajare.

Dacă găsiți ceva încă dificil de înțeles – nu ezitați să întrebați în comentariile de mai jos.

Ce urmeaza?

Să fii pregătit să răspunzi la una dintre întrebările clasice ale interviurilor din toate timpurile este minunat – dar uneori nu te sună niciodată pentru un interviu.

În continuare, mă voi concentra asupra a ceea ce vor angajatorii să vadă la un dezvoltator junior și cum să iasă în evidență din mulțime atunci când caută locuri de muncă.

Rămâneți aproape.

1611741487 839 Cum sa explicam conceptele de programare orientate pe obiecte unui
Ți-a plăcut citirea? Dacă vrei să mă sprijini, îmi poți cumpăra o cafea 🙂