Thursday, April 25, 2024 05:56

Cuprins >> Programarea Orientată Pe Obiecte > Încapsularea

Încapsularea

Al doilea principiu fundamental al Programării Orientate pe Obiecte este încapsularea. Definiția sa principală se referă la acțiunea de a ascunde orice lucru care nu este esențial de lumea exterioară. Nu este foarte dificil să înțelegem faptul că nu trebuie să expunem totul atunci când construim ceva. De exemplu, dacă am fi ingineri și am proiecta o mașină, nu am dori ca utilizatorii mașinii noastre să poată accesa lucruri care nu le sunt relevante. Cu alte cuvinte, utilizatorii nu trebuie să știe despre cablarea internă, piesele mecanice etc. Nu trebuie să știe și nu ar trebui să știe despre astfel de detalii. Cablarea internă și piesele mecanice trebuie accesate numai de personalul calificat, astfel încât le-am ascunde de accesul neautorizat.

Prin urmare, folosim încapsularea din două motive principale: ascundem date neesențiale de lumea exterioară, deoarece lumea exterioară nu este interesată de aceste date, și le ascundem pentru că nu dorim ca lumea exterioară să le modifice în moduri care nu au fost intenționate.

În C#, încapsularea se realizează folosind modificatori de acces, despre care am vorbit deja. În retrospectivă, înțelegem că:

  • modificatorul de acces private este cel mai restrictiv modificator de acces, deoarece ne permite să folosim doar membri din interiorul acelui tip (o metodă privată poate fi utilizată doar din cadrul clasei care o conține). De asemenea, este modificatorul de acces implicit al membrilor, adică orice variabilă, proprietate sau metodă este marcată ca fiind implicit privată, dacă nu specificăm un modificator de acces.
  • protected este un modificator de acces similar celui private, cu o singură diferență. Membrii protejați sunt vizibili doar din interiorul clasei în care sunt declarați, și din cadrul oricăror clase care moștenesc din clasa în care sunt declarați.
  • modificatorul de acces internal ne permite să utilizăm tipuri și membri de tipuri numai din cadrul ansamblului curent. Aceasta înseamnă în principal că le putem folosi din tot proiectul nostru. Este, de asemenea, modificatorul implicit de acces pentru tipuri. Dacă declaram o clasă și nu specificăm un modificator de acces pentru aceasta, ea este marcată implicit ca intern.
  • protected internal este similar cu o combinație a modificatorilor de acces internal și protected, ceea ce înseamnă că permite utilizarea codului fie dintr-un tip derivat, fie din interiorul ansamblului curent.
  • public este cel mai puțin restrictiv modificator de acces și nu prezintă nicio restricție în ceea ce privește utilizarea tipurilor sau membrilor.

După cum vedem, avem o mulțime de niveluri la care putem impune încapsularea, expunând în mod eficient funcționalități interne numai celor ar trebui să știe despre aceasta. Încapsularea nu numai că ne permite să ascundem lucruri irelevante pentru utilizator, ne permite să și impunem comportamentul dorit. De exemplu, dacă dorim să păstrăm vârsta unei persoane, am putea declara o variabilă publică de tip int. Dar, în acest fel, utilizatorii pot atribui valori negative, ceea ce ar fi complet greșit. Nimeni nu are -5 ani. Ce putem face pentru a corecta această aberație este să declarăm variabila int ca privată și să îi atribuim valori doar printr-o proprietate sau o metodă publice. În acest fel, stocăm valoarea variabilei noastre int fără accesul utilizatorului, iar în proprietatea sau metoda unde permitem atribuirea unei valori, putem specifica condiții, cum ar fi ca vârsta să fie un număr pozitiv.

Un alt beneficiu este faptul că permite dezvoltatorilor să schimbe lucruri fără a strica funcționalitatea. De exemplu, dacă avem o clasă de tip Animal, care implementează un comportament de mers, probabil că ar avea metode precum PrimaLabaInainte(), PrimaLabaInapoi(), ADouaLabaInainte(), ADouaLabaInapoi(). Pentru ca utilizatorul să facă animalul să meargă, el ar trebui să știe secvența exactă de apelare a acestor metode, astfel încât animalul să meargă într-un mod adecvat și intenționat. Dar dacă vom decide mai târziu că animalul nostru țopăie, și nu merge? Ar trebui să schimbăm aceste metode cu TopaieInainte(), etc. Dar, dacă redenumim metodele, toate codurile care s-au bazat pe apelarea acestor metode nu ar mai ști despre noile nume, și vom primi erori. Utilizatorul va trebui să găsească și să înlocuiască fiecare apel de metodă cu noul nume și comportament. Este ceva oribil de făcut. În schimb, putem marca toate aceste metode ca private și să expunem o singură metodă publică numită Deplaseaza(). În cadrul acestei metode, putem apela orice metode private pe care dorim, care efectuează de fapt toate acțiunile necesare pentru a merge, sări, târî, etc. Ori de câte ori dorim să schimbăm acest comportament, schimbăm doar ceea ce se apelează în cadrul acestei metode Deplaseaza(), iar utilizatorii nu ar ști diferența. Din perspectiva lor, ei încă văd o singură metodă publică numită Deplaseaza(), și nimic din programele lor nu s-ar strica.

Ca o regulă, obișnuiți-vă să ascundeți cât mai mult de codurile voastre. Expuneți întotdeauna lumii exterioare doar cerințele.

Tags: , , ,

Leave a Reply



Follow the white rabbit