Archief - [PROG] Gebruik van getters en setters

kwitters · 6 jun 2006

passero zei:
Ook is het niet echt volgens de regels van OOP om variabelen public te zetten.

Enkel de compiler legt je regels op, de rest is allemaal vrij

. Het zou makkelijk zijn moest er een regel zijn van "gebruik altijd get/set, en nooit public members" of omgekeerd "gebruik steeds public members, en vergeet get/set". Was het allemaal maar zo simpel, dan moesten we niet meer nadenken en gewoon brainless coden

. Realiteit is dat je gewoon moet kijken wat het beste werkt in welke situatie. Als ik bijvoorbeeld een vector classe implementeer, zou dit als volgt gaan:

class Vector2D {
public double x;
public double y;

inline bool operator==( const Vector2D& other ) {
...
}

Ik zie geen enkele reden om hier get/set te gebruiken. Dit kost enkel tijd, zowel in implementatie/debugging/documenting/run/... . Op deze manier hou je de classe gewoon eenvoudig. Er zijn andere gevallen waar het wel aan te raden is om get/set te gebruiken, bijvoorbeeld wanneer je member aan bepaalde voorwaarden moet voldoen, die je eerst wil controleren.

Een goeie programmeur weegt af wat in welke situatie het beste werkt

.

Bubbling Zombie · 6 jun 2006

kwitters zei:
Enkel de compiler legt je regels op, de rest is allemaal vrij . Het zou makkelijk zijn moest er een regel zijn van "gebruik altijd get/set, en nooit public members" of omgekeerd "gebruik steeds public members, en vergeet get/set". Was het allemaal maar zo simpel, dan moesten we niet meer nadenken en gewoon brainless coden . Realiteit is dat je gewoon moet kijken wat het beste werkt in welke situatie. Als ik bijvoorbeeld een vector classe implementeer, zou dit als volgt gaan:

class Vector2D {
public double x;
public double y;

inline bool operator==( const Vector2D& other ) {
...
}

Ik zie geen enkele reden om hier get/set te gebruiken. Dit kost enkel tijd, zowel in implementatie/debugging/documenting/run/... . Op deze manier hou je de classe gewoon eenvoudig. Er zijn andere gevallen waar het wel aan te raden is om get/set te gebruiken, bijvoorbeeld wanneer je member aan bepaalde voorwaarden moet voldoen, die je eerst wil controleren.

Een goeie programmeur weegt af wat in welke situatie het beste werkt .

-> getters en setters documenteer je niet. Meer nog, als ik getters en setters gedocumenteerd zou zien, zou ik denken dat de andere een retard was die mij als retard aanziet.

-> debugging oO. Ja, maakt veel uit natuurlijk:
klasse.variable = blabla; ipv klasse.setVariable(blabla);

-> implementatie: meneer werkt nog met notepad?

een goeie (oo)programmeur weet wat encapsulatie is, iets wat je straal negeert als je public variabelen gaat gebruiken.

Ice · 6 jun 2006

kwitters zei:
Enkel de compiler legt je regels op, de rest is allemaal vrij . Het zou makkelijk zijn moest er een regel zijn van "gebruik altijd get/set, en nooit public members" of omgekeerd "gebruik steeds public members, en vergeet get/set". Was het allemaal maar zo simpel, dan moesten we niet meer nadenken en gewoon brainless coden . Realiteit is dat je gewoon moet kijken wat het beste werkt in welke situatie. Als ik bijvoorbeeld een vector classe implementeer, zou dit als volgt gaan:

class Vector2D {
public double x;
public double y;

inline bool operator==( const Vector2D& other ) {
...
}

Ik zie geen enkele reden om hier get/set te gebruiken. Dit kost enkel tijd, zowel in implementatie/debugging/documenting/run/... . Op deze manier hou je de classe gewoon eenvoudig. Er zijn andere gevallen waar het wel aan te raden is om get/set te gebruiken, bijvoorbeeld wanneer je member aan bepaalde voorwaarden moet voldoen, die je eerst wil controleren.

Een goeie programmeur weegt af wat in welke situatie het beste werkt .

Stel nu dat ge na een paar maand besluit dat je intern in uw vector class de gegevens op een andere manier wil bijhouden.
Ondertussen wordt uw klasse al in tientalle andere klassen gebruikt.
Als je nu getters/setters had gebruikt had ge intern de wijzigingen kunnen doen zonder dat dit extern zichtbaar was.
In dit geval gade alle klassen moeten aanpassen die gebruik maken van uw Vector.

passero · 6 jun 2006

Ice zei:
Stel nu dat ge na een paar maand besluit dat je intern in uw vector class de gegevens op een andere manier wil bijhouden.
Ondertussen wordt uw klasse al in tientalle andere klassen gebruikt.
Als je nu getters/setters had gebruikt had ge intern de wijzigingen kunnen doen zonder dat dit extern zichtbaar was.
In dit geval gade alle klassen moeten aanpassen die gebruik maken van uw Vector.

Idd, dat is dus de reden waarom ik altijd getters en setters schrijf voor variabelen die buiten de klasse aanspreekbaar moeten zijn.
het is nu eenmaal flexibel als je later zaken wil aanpassen.

Het is ook zo dat wanneer binnen uw klasse bepaalde variabelen hebt die enkel maar binnen de eigen klasse mogen gewijzigd worden en enkel maar geraadpleegd mogen worden van buitenaf, dan heb je zowieso een getters nodig, geen setter en een private variabele. Anders als die public staat kan je er ook mee doen wat je wil.

.Acku. · 6 jun 2006

killgore zei:
jij bedoelt met constanten final statics?

Tis maar dat dit in bv. c++ en java constanten beetje verschillend zijn .

edit: final vergeten

final statics idd, de enige variabelen die public mogen zijn binnen Java (of dus constants in het algemeen in OOP).
Wat anderen zeggen ivm 'performantie', 'RAD' e.d is een erfenis uit de tijd dat er nog geen degelijke compilers en IDE's waren. Code first, optimize later. Die drang naar performance tuning is zo oldskool. Een compiler kan even goed een get/set methode inlinen via JIT.

den Acid Burn · 6 jun 2006

Ice zei:
Stel nu dat ge na een paar maand besluit dat je intern in uw vector class de gegevens op een andere manier wil bijhouden.
Ondertussen wordt uw klasse al in tientalle andere klassen gebruikt.
Als je nu getters/setters had gebruikt had ge intern de wijzigingen kunnen doen zonder dat dit extern zichtbaar was.
In dit geval gade alle klassen moeten aanpassen die gebruik maken van uw Vector.

AIM is doomed :unsure:

.Acku. · 6 jun 2006

Inderdaad, neem nu dat K3 er iemand bijneemt (een zwarte, voor het educatief multicultureel karakter) en je moet wegens performantieredenen je datamodel veranderen van directe variabeele toegang (OudeVrijster Kristel, Karen...) veranderen naar een collectie zoals Dump <OudeVrijster> onzeVierHuppelkutjes, dan is zowat gans uw K3(4) spel naar de haaien.
F-a-i-l-l-i-e-t.

jodeman · 6 jun 2006

.Acku. zei:
Inderdaad, neem nu dat K3 er iemand bijneemt (een zwarte, voor het educatief multicultureel karakter) en je moet wegens performantieredenen je datamodel veranderen van directe variabeele toegang (OudeVrijster Kristel, Karen...) veranderen naar een collectie zoals Dump <OudeVrijster> onzeVierHuppelkutjes, dan is zowat gans uw K3(4) spel naar de haaien.
F-a-i-l-l-i-e-t.

LOL

killgore · 6 jun 2006

kwitters zei:
Enkel de compiler legt je regels op, de rest is allemaal vrij . Het zou makkelijk zijn moest er een regel zijn van "gebruik altijd get/set, en nooit public members" of omgekeerd "gebruik steeds public members, en vergeet get/set". Was het allemaal maar zo simpel, dan moesten we niet meer nadenken en gewoon brainless coden . Realiteit is dat je gewoon moet kijken wat het beste werkt in welke situatie. Als ik bijvoorbeeld een vector classe implementeer, zou dit als volgt gaan:

class Vector2D {
public double x;
public double y;

inline bool operator==( const Vector2D& other ) {
...
}

Ik zie geen enkele reden om hier get/set te gebruiken. Dit kost enkel tijd, zowel in implementatie/debugging/documenting/run/... . Op deze manier hou je de classe gewoon eenvoudig. Er zijn andere gevallen waar het wel aan te raden is om get/set te gebruiken, bijvoorbeeld wanneer je member aan bepaalde voorwaarden moet voldoen, die je eerst wil controleren.

Een goeie programmeur weegt af wat in welke situatie het beste werkt .

Dan maak je een methode normalize ergens in een andere klasse die een vector ontvangt en krijg je ineens een divide-by-zero exception

.
(khad da voorbeeld hier al voor gegeven

).

Tyfius · 6 jun 2006

Tegenwoordig kost dat toch gene tijd meer. Ik heb kwa Java alleen ervaring met eclipse, en daar konde getters en setters auto generaten, in VS.NET zal da ook wel gaan, en in MonoDevelop komt die functionaliteit ook (als ik tremor nog wa push).

killgore · 6 jun 2006

als het aankomt op auto-generaten en refactoring mag je eens lachen met vs als het op c/c++ development aankomt.

passero · 6 jun 2006

lang leve together op dat gebied

jodeman · 6 jun 2006

killgore zei:
Dan maak je een methode normalize ergens in een andere klasse die een vector ontvangt en krijg je ineens een divide-by-zero exception .
(khad da voorbeeld hier al voor gegeven ).

niet als je in die normalize methode gaat kijken of een vector al dan niet leeg is (wat ge beter wel doet).

killgore · 6 jun 2006

jodeman zei:
niet als je in die normalize methode gaat kijken of een vector al dan niet leeg is (wat ge beter wel doet).

Het is veel logischer (imho) dat je vna in het begin zorgt dat je enkel geldige vectors kan terugkrijgen ipv altijd opnieuw controle te gaan uitvoeren.

kwitters · 6 jun 2006

killgore zei:
Je kon natuurlijk controle doen voor het normaliseren, nog beter echter was dit enkel via setter toegangkelijk maken waardoor de vector nooit een nul-vector kan zijn.

Met welke reden zou je de controle niet in de normalize method steken? Als je dit via de set method gaat inperken, hoe kan je dan trouwens uberhaupt nog een nul-vector aanmaken??? Met jou classe is het onmogelijk een snelheidsvector x=0,y=0,z=0 te hebben.

jodeman · 6 jun 2006

ja dat snap ik ook niet. Zo ga je heel veel divide by 0 errors in de code krijgen. Zeker als iemand anders uw code gaat hergebruiken is dat een nachtmerrie.

In heel de java api wordt constant op invoer gecheckt, niet alleen via da getters en de setters hoor.

.Acku. · 6 jun 2006

Getters en setters mogen enkel hetgeen doen waarnaar ze genoemd zijn, namelijk getten en setten. Ze mogen in geen enkel geval business-logica bevatten, en liefst ook geen andere code die exceptions kan werpen. In Java is dat zo omdat het anders geen Bean-conventie methoden meer zijn.

Vich · 6 jun 2006

Bubbling Zombie zei:
-> getters en setters documenteer je niet. Meer nog, als ik getters en setters gedocumenteerd zou zien, zou ik denken dat de andere een retard was die mij als retard aanziet.

Stel dat je een member hebt die GetIndex() heet en een int teruggeeft... dan kan het toch best handig zijn om te documenteren dat die int "-1" is als er iets fout gegaan is of niet beschikbaar is?

een goeie (oo)programmeur weet wat encapsulatie is, iets wat je straal negeert als je public variabelen gaat gebruiken.

... en daar is niks mis mee in het voorbeeld van Killgore

Ice zei:
Stel nu dat ge na een paar maand besluit dat je intern in uw vector class de gegevens op een andere manier wil bijhouden.
Ondertussen wordt uw klasse al in tientalle andere klassen gebruikt.
Als je nu getters/setters had gebruikt had ge intern de wijzigingen kunnen doen zonder dat dit extern zichtbaar was.
In dit geval gade alle klassen moeten aanpassen die gebruik maken van uw Vector.

lol! De interne voorstelling van een vector veranderen

Maar even serieus:
Als die verandert, dan moet je vaak ook je getters en setters veranderen, omdat die bvb niet meer hetzelfde type teruggeeft

En in dat geval moet je evengoed alle andere klassen aanpassen.
Maar to be honest: als zoiets gebeurt, dan gebeurt dat omdat iemand het programma slecht ontworpen heeft en zoiets geeft áltijd extra werk.

kwitters zei:
Met welke reden zou je de controle niet in de normalize method steken? Als je dit via de set method gaat inperken, hoe kan je dan trouwens uberhaupt nog een nul-vector aanmaken??? Met jou classe is het onmogelijk een snelheidsvector x=0,y=0,z=0 te hebben.

Waarom niet? Simpelweg omdat die method ERG vaak wordt aangeroepen en dat kost CPU tijd, zeker in een spel.
Daarom maak je dus bijvoorbeeld een ::Normalize() en :

afeNormalize() aan, want soms weet je zéker dat de vector geen nul-lengte heeft en dan kan je gewoon ::Normalize gebruiken

kwitters · 6 jun 2006

Vich zei:
Waarom niet? Simpelweg omdat die method ERG vaak wordt aangeroepen en dat kost CPU tijd, zeker in een spel.
Daarom maak je dus bijvoorbeeld een ::Normalize() en :afeNormalize() aan, want soms weet je zéker dat de vector geen nul-lengte heeft en dan kan je gewoon ::Normalize gebruiken

Volledig mee akkoord, maar dat neemt niet weg dat het vrij absurd is om een nul-vector te verbieden met de set method.

.Acku. · 6 jun 2006

Controle op null of zero length is nu niet echt een bottleneck oO

Archief - [PROG] Gebruik van getters en setters

kwitters

Legacy Member

Bubbling Zombie

Legacy Member

Ice

Legacy Member

passero

Legacy Member

.Acku.

Legacy Member

den Acid Burn

Legacy Member

.Acku.

Legacy Member

jodeman

Legacy Member

killgore

Legacy Member

Tyfius

Legacy Member

killgore

Legacy Member

passero

Legacy Member

jodeman

Legacy Member

killgore

Legacy Member

kwitters

Legacy Member

jodeman

Legacy Member

.Acku.

Legacy Member

Vich

Legacy Member

kwitters

Legacy Member

.Acku.

Legacy Member