Inkapseling

"Hallo, Amigo! Ik wil de lezing van vandaag wijden aan inkapseling . Je hebt al een algemeen idee van wat het is."

Dus wat zijn de voordelen van inkapseling? Er zijn er veel, maar ik zal er vier noemen die naar mijn mening het belangrijkst zijn:

1) Geldige interne status.

Programma's hebben vaak meerdere klassen die interactie hebben met hetzelfde object. Door gelijktijdige interactie met de interne gegevens van het object kunnen ze de gegevensintegriteit van het object schenden, waardoor het object niet meer correct werkt.

Het object moet dus alle wijzigingen in zijn interne gegevens bijhouden, of beter nog: het moet degene zijn die deze wijzigingen aanbrengt.

Als we niet willen dat een klassevariabele door andere klassen wordt gewijzigd, declareren we deze privé , wat betekent dat alleen de methoden van die klasse er toegang toe hebben. Als we willen dat variabelen alleen-lezen zijn voor andere klassen, voegen we public getter toe aan deze variabelen.

We willen bijvoorbeeld dat iedereen weet hoeveel elementen er in onze collectie zitten, maar niemand mag dit zonder onze toestemming kunnen wijzigen. In dit geval declareren we een variabele private int count en een methode public getCount() .

Een juiste inkapseling garandeert dat andere klassen niet rechtstreeks toegang hebben tot de interne gegevens van onze klasse en deze bijgevolg niet kunnen wijzigen zonder dat wij hun acties kunnen controleren. Ze moeten methoden aanroepen op de klasse die de variabelen bevat die zullen worden gewijzigd.

Het is het beste om aan te nemen dat andere programmeurs uw klassen altijd zullen gebruiken op de manier die voor hen het handigst is, niet op de manier die het veiligst is voor u (of uw klas). Dit is een bron van bugs en een manier om ze te voorkomen.

2) Parametercontrole.

Soms moet u de parameters controleren die zijn doorgegeven aan de methoden van uw klasse. Stel dat we een klasse hebben die een "persoon" vertegenwoordigt en dat u de geboortedatum kunt specificeren. We moeten controleren of alle ingevoerde gegevens overeenkomen met de logica van het programma en de logica van de klasse. Er is bijvoorbeeld geen 13e maand, geen 30 februari, enz.

"Waarom zou iemand een geboortedatum van 30 februari aangeven?"

"Nou, in de eerste plaats kan het het gevolg zijn van een fout bij het invoeren van gegevens."

Ten tweede, voordat een programma op rolletjes loopt, kan het veel bugs bevatten. Zoiets kan bijvoorbeeld gebeuren.

Een programmeur schrijft code die bepaalt wie er overmorgen jarig is. Laten we zeggen dat het vandaag 3 maart is. Het programma telt 2 op bij de huidige datum en vindt iedereen die op 5 maart is geboren. Tot nu toe, zo goed.

Maar als het 30 maart is, vindt het programma niemand, aangezien er geen 32 maart is. Programma's bevatten veel minder fouten wanneer methoden parametercontrole uitvoeren."

"Ik herinner me dat toen we ArrayList bestudeerden, ik naar de code keek, en er waren controles in de get- en set-methoden om ervoor te zorgen dat de indexparameter groter is dan of gelijk is aan nul en kleiner is dan de lengte van de array. De code zou een uitzondering als de array geen element had dat overeenkomt met de index.

"Ja, dat is klassieke invoercontrole. "

3) Minder bugs bij het wijzigen van code binnen klassen.

Stel dat we een heel nuttige les hebben geschreven als onderdeel van een enorm project. Iedereen vindt het zo leuk dat andere programmeurs het op honderden plaatsen in hun eigen code zijn gaan gebruiken.

De les bleek zo nuttig te zijn dat je besloot hem te verbeteren. Maar als je een van de methoden in de klasse verwijdert, zal de code van tientallen andere programmeurs niet langer compileren. Ze zouden hun code snel moeten herschrijven. En hoe meer herschrijven er gebeurt, hoe meer kansen er zijn voor bugs. Als je de build regelmatig onderbreekt, zul je gehaat worden.

Maar als we methoden wijzigen die als privé zijn gemarkeerd, weten we dat deze methoden nergens door de code van iemand anders worden aangeroepen. We kunnen ze herschrijven en het aantal en type parameters wijzigen, en afhankelijke code zal nog steeds werken. Of het zal in ieder geval nog steeds compileren.

4) We definiëren hoe andere objecten zullen interageren met ons object.

We kunnen beperken welke acties op ons object kunnen worden ondernomen. We willen bijvoorbeeld dat slechts één instantie van een klasse wordt gemaakt, zelfs als deze op verschillende plaatsen tegelijk in het project wordt gemaakt. En we kunnen dit bereiken door inkapseling.

Door inkapseling kunnen we aanvullende beperkingen opleggen die kunnen leiden tot extra voordelen . De klasse String is bijvoorbeeld geïmplementeerd als een onveranderlijk object. Een instantie van de klasse String kan niet worden gewijzigd tussen het maken en vernietigen ervan. Alle methoden van de klasse String (remove, substring, ...) retourneren een nieuwe string en veranderen op geen enkele manier het object waarop ze worden aangeroepen.

"Heilige koe. Dus zo is het."

"Inkapseling is intrigerend."

"Daar ben ik het mee eens."