Gegevens inkapseling

Gegevensinkapseling is het belangrijkste concept dat moet worden begrepen bij het programmeren met objecten. Bij objectgeoriënteerde programmering houdt data-inkapseling verband met:

• Gegevens combineren en hoe deze op één plek worden gemanipuleerd. Dit wordt bereikt door de status (de privévelden) en het gedrag (de openbare methoden) van een object.
• Alleen toestaan ​​dat de status van een object via gedrag wordt benaderd en gewijzigd. De waarden in de status van een object kunnen vervolgens strikt worden gecontroleerd.
• De details verbergen over hoe het object werkt. Het enige deel van het object dat toegankelijk is voor de buitenwereld zijn gedragingen. Wat er binnen die gedragingen gebeurt en hoe de status wordt opgeslagen, is niet zichtbaar.

Gegevensinkapseling afdwingen

Eerst moeten we onze objecten zodanig ontwerpen dat ze een staat en gedrag vertonen. We maken privévelden met de staat en openbare methoden die het gedrag vormen.

Als we bijvoorbeeld een persoonobject ontwerpen, kunnen we privévelden maken om de voornaam, achternaam en het adres van een persoon op te slaan. De waarden van deze drie velden worden gecombineerd om de status van het object te bepalen. We kunnen ook een methode maken met de naam displayPersonDetails om de waarden van de voornaam, achternaam en adres op het scherm weer te geven.

Vervolgens moeten we gedragingen uitvoeren die de status van het object openen en wijzigen. Dit kan op drie manieren worden bereikt:

• Constructor methoden. Een nieuw exemplaar van een object wordt gemaakt door een constructormethode aan te roepen. Waarden kunnen worden doorgegeven aan een constructormethode om de begintoestand van een object in te stellen. Er zijn twee interessante dingen om op te merken. Ten eerste staat Java er niet op dat elk object een constructormethode heeft. Als er geen methode bestaat, gebruikt de status van het object de standaardwaarden van de privévelden. Ten tweede kan er meer dan één constructormethode bestaan. De methoden zullen verschillen in termen van de waarden die eraan worden doorgegeven en hoe ze de initiële status van het object instellen.
• Accessor-methoden. Voor elk privéveld kunnen we een openbare methode maken die zijn waarde teruggeeft.
• Mutator methoden. Voor elk privéveld kunnen we een openbare methode maken die zijn waarde instelt. Als u wilt dat een privéveld alleen wordt gelezen, maakt u er geen mutatiemethode voor.

We kunnen het person-object bijvoorbeeld zo ontwerpen dat het twee constructormethoden heeft. De eerste neemt geen waarden aan en stelt eenvoudigweg het object in op een standaardstatus (d.w.z. de voornaam, achternaam en het adres zijn lege tekenreeksen). De tweede stelt de beginwaarden in voor de voornaam en achternaam van waarden die eraan zijn doorgegeven. We kunnen ook drie accessor-methoden maken, getFirstName, getLastName en getAddress, die eenvoudig de waarden van de bijbehorende privévelden retourneren. Maak een mutatorveld met de naam setAddress dat de waarde van het privéveld voor het adres instelt.

Ten slotte verbergen we de implementatiedetails van ons object. Zolang we ons houden aan het privé houden van de velden en het gedrag aan de buitenwereld, is er geen manier voor de buitenwereld om te weten hoe het object intern werkt.

Redenen voor inkapseling van gegevens

De belangrijkste redenen voor het gebruik van gegevensinkapseling zijn:

• De staat van een object legaal houden. Door een privéveld van een object te dwingen om te worden gewijzigd met behulp van een openbare methode, kunnen we code toevoegen aan de mutator- of constructormethode om ervoor te zorgen dat de waarde legaal is. Stel je bijvoorbeeld voor dat het persoonsobject ook een gebruikersnaam opslaat als onderdeel van zijn status. De gebruikersnaam wordt gebruikt om in te loggen bij de Java-applicatie die we bouwen, maar is beperkt tot een lengte van tien tekens. Wat we kunnen doen, is code toevoegen aan de mutatormethode van de gebruikersnaam die ervoor zorgt dat de gebruikersnaam niet op een waarde van meer dan tien tekens wordt ingesteld.
• We kunnen de implementatie van een object wijzigen. Zolang we de openbare methoden hetzelfde houden, kunnen we de werking van het object wijzigen zonder de code die het gebruikt te verbreken. Het object is in wezen een "zwarte doos" voor de code die het aanroept.
• Hergebruik van objecten. We kunnen dezelfde objecten in verschillende applicaties gebruiken omdat we de gegevens hebben gecombineerd en hoe deze op één plek worden gemanipuleerd.
• De onafhankelijkheid van elk object. Als een object onjuist is gecodeerd en fouten veroorzaakt, is het eenvoudig te testen en te repareren omdat de code zich op één plaats bevindt. In feite kan het object onafhankelijk van de rest van de applicatie worden getest. Hetzelfde principe kan worden gebruikt in grote projecten waarbij aan verschillende programmeurs de creatie van verschillende objecten kan worden toegewezen.