1. Inleiding
We willen de les van vandaag wijden aan inkapseling . Je weet al wat het in algemene termen is.
Wat zijn de voordelen van inkapseling? Er zijn er nogal wat, maar ik kan er vier noemen die naar mijn mening de belangrijkste zijn:
2. Geldige interne status
In programma's doen zich vaak situaties voor waarin een object interageert met verschillende andere klassen. Deze interacties met het object kunnen de gegevens in het object beschadigen, waardoor het voor het object onmogelijk wordt om te blijven werken zoals verwacht.
Als gevolg hiervan moet het object alle wijzigingen in zijn interne gegevens bijhouden, of beter nog, de wijzigingen zelf aanbrengen.
Als we niet willen dat een variabele door andere klassen wordt gewijzigd, verklaren we deze privé. Zodra we dat doen, hebben alleen de methoden van zijn eigen klasse er toegang toe. Als we willen dat de variabelen alleen-lezen zijn, moeten we een toevoegen public gettervoor de relevante variabelen.
Stel bijvoorbeeld dat we willen dat iedereen het aantal elementen in onze collectie kan weten, maar dat we niet willen dat ze de collectie kunnen wijzigen zonder onze toestemming. Vervolgens declareren we een private int countvariabele en een public getCount()methode.
Correct gebruik van inkapseling zorgt ervoor dat geen enkele klasse rechtstreeks toegang heeft tot de interne gegevens van onze klasse, waardoor wijzigingen buiten onze controle worden voorkomen. Deze wijzigingen zijn alleen mogelijk door de methoden aan te roepen van dezelfde klasse als de variabelen die 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 (voor uw klas). Dit gedrag is de bron van zowel bugs als pogingen om ze te voorkomen.
3. Methode-argumenten valideren
Soms moeten we de argumenten valideren die aan onze methoden zijn doorgegeven. Stel dat we een klas hebben die een persoon vertegenwoordigt en waarin je een geboortedatum kunt instellen. We moeten alle invoergegevens controleren om er zeker van te zijn dat ze kloppen met de logica van het programma en de logica van onze klasse. Bijvoorbeeld om een geboortedatum in een 13e maand of op 30 februari niet toe te staan, enzovoort.
Waarom zou iemand 30 februari aangeven als geboortedatum? Ten eerste kan dit een gebruikersfout zijn bij het invoeren van de gegevens. Ten tweede kan een programma veel fouten bevatten voordat het op rolletjes loopt. De volgende situatie is bijvoorbeeld mogelijk.
Een programmeur schrijft een programma dat mensen identificeert die overmorgen jarig zijn. Laten we bijvoorbeeld zeggen dat het vandaag 3 maart is. Het programma voegt het getal 2 toe aan de huidige dag van de maand en zoekt naar iedereen die op 5 maart is geboren. Het lijkt erop dat alles klopt.
Maar als het 30 maart is, zal het programma niemand vinden, omdat de kalender geen 32 maart heeft. Een programma heeft veel minder fouten als we de gegevens controleren die aan methoden zijn doorgegeven.
Weet je nog toen we de code bestudeerden ArrayListen analyseerden? We zagen dat de methoden geten controleerden of groter is dan of gelijk is aan nul en kleiner is dan de lengte van de array. setindex Bovendien genereren deze methoden een uitzondering als de index buiten de grenzen van de array valt. Dit is een klassiek voorbeeld van invoervalidatie.
4. Minimaliseren van fouten bij het wijzigen van code
Stel dat we een superhandige les hebben geschreven toen we betrokken waren bij een groot project. Iedereen vond het zo leuk dat andere programmeurs het op honderden plaatsen in hun code begonnen te gebruiken.
De les was zo nuttig dat je besloot om er wat verbeteringen aan te brengen. Maar als je methodes uit de klasse verwijdert, stopt de code van tientallen mensen met compileren. Ze zullen alles moeten herschrijven. En hoe meer wijzigingen u aanbrengt, hoe meer fouten u zult maken. Je zult veel vergaderingen verbreken en je zult gehaat worden.
Maar als we methoden wijzigen die als privé zijn gedeclareerd, weten we dat er nergens een andere klasse is die deze methoden zou kunnen aanroepen. We kunnen ze herschrijven, het aantal parameters en hun typen wijzigen, en elke afhankelijke externe code blijft werken. Nou ja, het zal tenminste compileren.
5. We beslissen hoe ons object interageert met externe objecten
We kunnen enkele van de acties beperken die met ons object kunnen worden uitgevoerd. Stel dat we willen dat een object slechts één keer wordt geïnstantieerd. Ook als deze op meerdere plekken in het project kan ontstaan. En dat kunnen we dankzij inkapseling.
Door inkapseling kunnen we extra beperkingen toevoegen , die kunnen worden omgezet in extra voordelen . De klasse is bijvoorbeeld Stringgeïmplementeerd als een onveranderlijk object. Een object van de Stringklasse is onveranderlijk vanaf het moment van creatie tot het moment van zijn dood. Alle methoden van de Stringklasse ( remove, substring, ...) retourneren een nieuwe string zonder wijzigingen aan te brengen in het object waarop ze worden aangeroepen.
Inkapseling is iets heel interessants.