Voor veel Object Oriented (afgekort OO) programmeurs is gebruik van publieke attributen een ‘no-brainer’. Ze houden de attributen beschermd (protected / private) en gebruiken geen publieke attributen. Maar er zijn ook veel OO-programmeurs die ze wel gebruiken. In deze blog gaan we dieper in op de vraag: “Hoe erg is het om publieke attributen te gebruiken?”. Om de blog leesbaar te houden wordt enkel de term object gebruikt en niet de term klasse.
Wat zijn publieke attributen?
Objectattributen zijn waarden die een object heeft. Zo heeft bijvoorbeeld een verkooporder een bedrag, verkoopdatum, etc. Het object (stukje software) dat eigenaar is van een attribuut noemen we in dit artikel een eigenaar-object van het attribuut. Een ander object die het attribuut wil lezen of wijzigen noemen we in dit artikel een gebruikend object.
Doordat een eigenaar-object zijn attribuut publiek maakt, kan een gebruikend object de waarde van het attribuut direct lezen en wijzigen zonder dat een methode van het eigenaar-object wordt aangeroepen. Het eigenaar-object heeft zelf daardoor geen controle meer over het lezen en wijzigen. Zie het onderstaande schema:
Schijnvoordelen van publieke attributen
In OO programmeren is het verleidelijk om publieke variabelen te gebruiken in plaats van beschermde variabelen, want zo kan het gebruikend object direct de data wijzigen zonder dat er extra geef- en wijzigmethoden aangemaakt moeten worden.
De ogenschijnlijke voordelen van publieke attributen zijn:
- Tijdwinst: het scheelt tijd met programmeren
- Minder code: het vermindert het aantal coderegels
- Minder geheugen nodig: het kost minder geheugen, omdat de data niet gekopieerd wordt maar de echte data is direct wijzigbaar voor het gebruikend object.
… dus waarom niet?
Nou, hierom niet…
Stel dat er 2 gebruikende objecten zijn die het bedrag wijzigen van een verkooporder. Je wilt dan extra logica inbouwen, zodat het brutobedrag wordt berekend op basis van het nettobedrag. Daarvoor moet je op 2 plekken in plaats van op 1 plek de code aanpassen.
Zie in de afbeelding plek 1 en 2 waar de code gewijzigd moet worden:
Datzelfde geldt ook voor extra controles die je wilt toevoegen bij het aanpassen van het bedrag. Uiteindelijk wil je misschien helemaal niet dat het bedrag gewijzigd kan worden, want het bedrag moet berekend worden op basis van de bedragen in verkooporderregels en eventuele kortingen.
OO-principes
De verantwoordelijkheid voor een attribuut moet volledig bij het eigenaar-object liggen. Ga niet voor de korte termijn oplossing, maar houd je aan onderstaande de OO-principes:
- Gegevens verbergen (OO data hiding) door het gebruik van beschermde en private attributen en publieke methoden;
- Inkapseling (OO encapsulation) doordat alleen het eigenaar-object met eigen methodes de waarden van haar eigen attributen mag wijzigen.
- Losse koppeling (loose coupling) wordt gerealiseerd door de inkapseling. De directe bewerkingen op het attribuut wordt los gekoppeld door de methode.
Nadelen van publieke attributen
Als je je niet houdt aan de hiervoor genoemde OO-principes, dan zijn dit de gevolgen:
- Het eigenaar-object heeft geen controle meer over een attribuut, want andere objecten kunnen object attributen ook wijzigen.
- In meerdere objecten zullen mogelijk controles geprogrammeerd worden voor die variabelen, terwijl die controles thuishoren in het eigenaar-object.
- Tijdens ‘design time’ en ‘debug time’ is het lastiger om te analyseren waar een attribuut initieel gevuld wordt, waar en wanneer een attribuut gewijzigd wordt en waar een attribuut gelezen wordt.
Hoe moet het dan wel?
Zie de onderstaande afbeelding. De wijzig methode wijzigt het attribuut.
De ‘wijzig’-methode is een publieke methode en kan aangeroepen worden door de gebruikende objecten. Het ‘bedrag’-attribuut is beschermd en wordt via de ‘wijzig’-methode gewijzigd.
Voordelen van beschermde attributen De ‘wijzig’-methode bevat ook validatie, berekeningenautorisatiecontroles, wijzigingslog aanvullen en mogelijk nog meer…
Bij overerving van de klasse kan deze methode nog weer specifieker gemaakt worden voor een subklasse.
Conclusie
Alle objectgeoriënteerde programmeertalen bieden de mogelijkheid voor publieke attributen, maar wat is het antwoord op de vraag: “Gebruik van publieke attributen – Ja of Nee”. Het antwoord is “Nee, niet gebruiken.”
Heb jij of jouw organisatie een vraagstuk waarbij myBrand jou kan helpen? Neem dan contact met ons op.
