ABAP heeft iets slims, namelijk publieke attributen die gebruikende-objecten wel kunnen lezen, maar niet mogen wijzigen.
In mijn blog “ABAP OO Gebruik publieke attributen – ja of nee” staan de argumenten om geen publieke attributen te gebruiken. Maar zijn Read-only attributen dan wel een goede keuze?
Deze optie “Read-only” maakt het toch erg verleidelijk om wel publieke attributen te gebruiken, want nu kan het gebruikende-object de waarde niet wijzigen. Zo voorkom je de ogenschijnlijke overkill aan geef-methoden (ook wel ‘getters’ genoemd). Of toch niet?
De reden om dit niet te doen, is dat je dan de controle weggeeft over het “geven” van data aan gebruikende objecten.
Waarom controle over het geven van data?
Bij het geven van data wil je de volgende mogelijkheden hebben:
- Controleren of de gebruiker de data wel mag hebben (autorisatiecontrole);
- Bepalen of de data al gelezen is uit de database (lazy loading) of nog gelezen moet worden. Om te voorkomen dat alle data van een business object uit de database gelezen wordt, kan slechts gelezen worden wat benodigd is. Hierdoor wordt het programma sneller en verbruikt het minder geheugen. Zeker bij REST-services zoals SAP-Gateway kan dit relevant zijn voor de responsetijden.
- Voor programma analyse kan het prettig zijn om breakpoints te kunnen zetten wanneer de data gegeven wordt aan een gebruikend object.
Het argument dat een read-only attribuut zorgt voor minder geheugengebruik klopt, maar weegt niet op tegen de nadelen. Bovendien zal het programma in de praktijk niet merkbaar vertragen, tenzij het enorme hoeveelheden data betreft. Echter, dan is mogelijk een ander ontwerp concept niet goed. Dan betreft het wellicht een data provider klasse in plaats van een business object klasse.
Overkill aan getter-methoden?
Je moet niet voor elk attribuut een getter-methode maken. Meestal maak je één getter methode die eventueel parameters bevatten om te bepalen welke data je wilt hebben om de hoeveelheid data te beperken.
Advies
Laat je niet verleiden om publieke variabelen te gebruiken, want bij toekomstige analyse, onderhoud en hergebruik van de objecten zal je hiervan veel hinder ondervinden.
