Încapsulare

"Bună, Amigo! Vreau să dedic prelegerea de astăzi încapsulării . Ai deja o idee generală despre ce este."

Deci, care sunt avantajele încapsulării? Sunt multe, dar voi sublinia patru care sunt, în opinia mea, cele mai importante:

1) Stare internă validă.

Programele au frecvent mai multe clase care interacționează cu același obiect. Interacționând simultan cu datele interne ale obiectului, acestea pot încălca integritatea datelor obiectului, determinând ca obiectul să nu mai funcționeze corect.

Așadar, obiectul trebuie să urmărească orice modificări ale datelor sale interne sau, mai bine, ar trebui să fie cel care să facă acele modificări.

Dacă nu dorim ca o variabilă de clasă să fie schimbată de alte clase, atunci o declarăm private , ceea ce înseamnă că numai metodele acelei clase o pot accesa. Dacă dorim ca variabilele să fie doar în citire pentru alte clase, atunci adăugăm getter public acestor variabile.

De exemplu, am dori ca toată lumea să știe câte elemente există în colecția noastră, dar nimeni nu ar trebui să o poată schimba fără permisiunea noastră. În acest caz, declarăm o variabilă private int count și o metodă public getCount() .

Încapsularea adecvată garantează că alte clase nu pot accesa direct datele interne ale clasei noastre și, în consecință, nu le pot modifica fără ca noi să le putem controla acțiunile. Ei trebuie să apeleze metode din clasa care conține variabilele care vor fi modificate.

Cel mai bine este să presupunem că alți programatori îți vor folosi întotdeauna cursurile în modul care le este cel mai convenabil, nu în modul care ar fi cel mai sigur pentru tine (sau clasa ta). Aceasta este o sursă de bug-uri și o modalitate de a le preveni.

2) Verificarea parametrilor.

Uneori trebuie să verificați parametrii trecuți în metodele clasei dvs. De exemplu, să presupunem că avem o clasă care reprezintă o „persoană” și puteți specifica data nașterii acesteia. Ar trebui să verificăm că orice date transmise corespund logicii programului și logicii clasei. De exemplu, nu există luna a 13-a, 30 februarie etc.

„De ce ar indica cineva o dată de naștere de 30 februarie?”

„Ei bine, în primul rând, ar putea fi rezultatul unei erori de introducere a datelor”.

În al doilea rând, înainte ca un program să funcționeze ca un ceasornic, poate avea o mulțime de erori. De exemplu, s-ar putea întâmpla așa ceva.

Un programator scrie cod care determină cine are ziua de naștere poimâine. Să presupunem că astăzi este 3 martie. Programul adaugă 2 la data curentă și îi găsește pe toți cei care s-au născut pe 5 martie. Până acum, e bine.

Dar când vine 30 martie, programul nu găsește pe nimeni, deoarece nu există 32 martie. Programele sunt mult mai puțin greșite atunci când metodele efectuează verificarea parametrilor."

„Îmi amintesc, când am studiat ArrayList, m-am uitat la codul său și au existat verificări în metodele get și set pentru a ne asigura că parametrul index este mai mare sau egal cu zero și mai mic decât lungimea matricei. Codul ar arunca un excepție dacă tabloul nu avea un element corespunzător indexului.

„Da, asta este verificarea clasică a intrărilor. ”

3) Mai puține erori la schimbarea codului în cadrul claselor.

Să presupunem că am scris o clasă cu adevărat utilă ca parte a unui proiect uriaș. Tuturor le place atât de mult încât alți programatori au început să-l folosească în sute de locuri în propriul cod.

Clasa s-a dovedit a fi atât de utilă încât ați decis să o îmbunătățiți. Dar dacă scapi de oricare dintre metodele din clasă, codul a zeci de alți programatori nu se va mai compila. Ar trebui să-și rescrie rapid codul. Și cu cât se întâmplă mai multe rescriere, cu atât există mai multe oportunități pentru erori. Dacă rupeți în mod regulat construcția, veți fi urât.

Dar dacă schimbăm metodele marcate ca private, știm că aceste metode nu sunt apelate de codul altcuiva nicăieri. Le putem rescrie și modifica numărul și tipul parametrilor, iar codul dependent va funcționa în continuare. Sau cel puțin se va compila în continuare.

4) Definim modul în care alte obiecte vor interacționa cu obiectul nostru.

Putem restricționa ce acțiuni pot fi întreprinse asupra obiectului nostru. De exemplu, am putea dori să fie creată o singură instanță a unei clase – chiar dacă este creată în mai multe locuri simultan în proiect. Și putem realiza acest lucru folosind încapsularea.

Încapsularea ne permite să impunem restricții suplimentare care s-ar putea transforma în beneficii suplimentare . De exemplu, clasa String este implementată ca obiect imuabil . O instanță a clasei String nu poate fi modificată între crearea și distrugerea acesteia. Toate metodele clasei String (remove, substring, ...) returnează un șir nou și nu schimbă în niciun fel obiectul pe care sunt apelate.

"Vacă sfântă. Deci așa este."

„Încapsularea este intrigantă”.

"Sunt de acord."