Archief - [PROG]c++ Public klasse datamember Vs Get&Set

Ik hoor van vele kanten dat het gebruik van public variabelen eigenlijk iets is wat niet gedaan word en datk beter getters en setters kan gebruiken.
Nu mijn vraag is waarom is het ene beter dan het andere?

Ten eerste hebt ge de controle om expliciet te specificeren of iets read-only, write-only of read/write is door het al dan niet implementeren van Gets & Sets. Ten tweede hebt ge een single point of access, iedereen die aan die variabele wilt moet langs de gets & sets passeren. Als je dus ooit access naar die variabele wil hooken en iets extra doen ( meestal vb een breakpoint zetten oid ), weet je waar die te zetten. Ten derde scherm je ook de implementatie van uw klasse af, als je de interne structuur van uw klasse wil veranderen kan je vb die variabele vervangen zonder uw externe interface te moeten aanpassen.

Der zullen wschl nog wel betere of intelligentere redenen zijn, maar dit is off the top of my head, public members zijn meestal idd een slecht idee hoor

Ik heb het altijd gebruikt omdat je dan (in je setters) enkele controles kan inbouwen, in een getter heb ik nooit iets echt anders gedaan dan een return-waarde van de variabele maken, maar het is redelijk ogsch dat je via een pubic getter gaat als je een private variabele zeker

ravenslayer zei:

Ik hoor van vele kanten dat het gebruik van public variabelen eigenlijk iets is wat niet gedaan word en datk beter getters en setters kan gebruiken.
Nu mijn vraag is waarom is het ene beter dan het andere?

Klik om te vergroten...

gebt blijkbaar niet goed opgelet bij de hoefman :naughty:

belangrijkste redenen heeft keats al opgenoemd (read/write en implementatie afscheiden). Nog 1 zeer belangrijk punt is dat je je get/set proces kan aanpassen.

Zo kan je bv. zorgen dat er altijd pass-by-value ipv pass-by-reference wordt gedaan (dus dat je geen referentie maar een object teruggeeft, beter voor afscherming).
Anderzijds kan je controleren of een waarde wil binnen een vooropgegeven interval ligt, ...

En in C++ is er eigenlijk bijna geen reden om het niet te gebruiken, een methode zoals pakweg getX() {return this->x; } wordt in zijn assembler equivalent toch ge-inlined door elke deftige compiler. (Je hoort soms het snelheidsargument opduiken door de overhead van een functie-call)

Wat ik wel soms hoor is dat het handig kan zijn voor bepaalde operaties, bv. bij vectoren is het handig dat je v.x+=waarde; kan doen. Dit komt dus voornamelijk voor bij wiskundige structuren en dat zijn ook zowat de enige waar ik dit soms gebruikte, puur omdat iets als v.setX(v.getX()+waarde)); soms toch iets te omslachtig is . Maar ik probeer nu zelfs dat te vermijden.

TiZon zei:

Ik heb het altijd gebruikt omdat je dan (in je setters) enkele controles kan inbouwen, in een getter heb ik nooit iets echt anders gedaan dan een return-waarde van de variabele maken, maar het is redelijk ogsch dat je via een pubic getter gaat als je een private variabele zeker

Klik om te vergroten...

Er zijn best wat voorbeelden te bedenken waar een getter wel andere zaken doet dan enkel een variabele returnen. Stel je bv voor dat je een string opslaat en als output wil je bv die string bb-code meegeven, dan kan je iets doen als "return [b ]+string+[/b ]" zonder dat je dus die bb-code tags moet opslaan (minder geheugengebruik etc). Dit is natuurlijk een simpel voorbeeld, maar komt toch wel af en toe eens voor.

killgore zei:

Wat ik wel soms hoor is dat het handig kan zijn voor bepaalde operaties, bv. bij vectoren is het handig dat je v.x+=waarde; kan doen. Dit komt dus voornamelijk voor bij wiskundige structuren en dat zijn ook zowat de enige waar ik dit soms gebruikte, puur omdat iets als v.setX(v.getX()+waarde)); soms toch iets te omslachtig is . Maar ik probeer nu zelfs dat te vermijden.

Klik om te vergroten...

Daarvoor heeft c++ operator overloading Of je schrijft een functie v.plus(waarde) waarbij je in je methode plus dus je setters en getters gebruikt... Het hoeft dus helemaal niet zo moeilijk.

tnx voor de vele comments en weet nu idd waarom het vrij belangrijk is in gebruik

nu ik heb een 2d dynamische array die ik inlaad met waarden en die stond public maar zal hiervoor dan wel een get en set functie schrijven

en @D3C0Y
Heb hem daar nog niet echt veel over horen zeggen hoor? ^^

ravenslayer zei:

en @D3C0Y
Heb hem daar nog niet echt veel over horen zeggen hoor? ^^

Klik om te vergroten...

Dat zal hoofdzakelijk aan jou liggen dan. Zie dokeos/programmeren1/lesweek10/theorie/encapsulatie.ppt voor een geheugensteuntje.

De 2 uur durende les waarin dit alles uitgelegd wordt kan volgend jaar terug gevolgd worden

Cyc1oon zei:

Daarvoor heeft c++ operator overloading Of je schrijft een functie v.plus(waarde) waarbij je in je methode plus dus je setters en getters gebruikt... Het hoeft dus helemaal niet zo moeilijk.

Klik om te vergroten...

djeez, ik ken wel degelijk operator overloading hoor. Zeg mij eens hoe jij in een vector de x-component zo schrijft zoals ik hierboven met operator overloading (een 4-d vector met dus een x,y,z,w waarde).
ty come again.

killgore zei:

djeez, ik ken wel degelijk operator overloading hoor. Zeg mij eens hoe jij in een vector de x-component zo schrijft zoals ik hierboven met operator overloading (een 4-d vector met dus een x,y,z,w waarde).
ty come again.

Klik om te vergroten...

Zo direct hocus pocus pats zal het natuurlijk wel niet gaan. Als je toch zonder veel werk zo'n waarde wil optellen kun je gewoon een extra functie toevoegen zoals ik al opgaf die *veilig* via getters/setters alles kan aanpassen. Op jouw manier gaat het goed zolang enkel die 4 waarden worden bijgehouden. Mochten er nog gerelateerde zaken worden bijgehouden die afhankelijk zijn van die waarden dan draait alles de soep in. Ook al doe jij dat nu niet, stel dat iemand na jou deze code wil aanpassen, dan moet hij ook nog eens alle code aanpassen die gebruik maakt van jouw klasse. Goed opgebouwde code kan je het dus niet noemen.

Maar goed, als je nu over 4 waarden praat die je opslaat is operator overloading in dit geval iets minder gunstig.

Gildis zei:

Dat zal hoofdzakelijk aan jou liggen dan. Zie dokeos/programmeren1/lesweek10/theorie/encapsulatie.ppt voor een geheugensteuntje.

De 2 uur durende les waarin dit alles uitgelegd wordt kan volgend jaar terug gevolgd worden

Klik om te vergroten...

Idd totally my bad en ik neem men woorden terug.
dat is hoe onwaarschijnlijk het ook mag klinken in een docent zijn oren, net de theorieles die ik gemist heb

Nuja ik steek nu meer tijd in men programmeren en ben zeker niet van plan om als IOT'er die les volgend jaar nog meetevolgen (en nu ik de info heb wss ook niet als 2de jaars als je dat niet erg vind ).

Zal wel onthouden datk int vervolg eerst de theorieslides eens doorneem alsk zo een vraag heb

nogmaal bedankt voor de reacties

ravenslayer zei:

Nuja ik steek nu meer tijd in men programmeren en ben zeker niet van plan om als IOT'er die les volgend jaar nog meetevolgen (en nu ik de info heb wss ook niet als 2de jaars als je dat niet erg vind ).

Klik om te vergroten...

That's the spirit!

Cyc1oon zei:

Maar goed, als je nu over 4 waarden praat die je opslaat is operator overloading in dit geval iets minder gunstig.

Klik om te vergroten...

indeed, en je moet rekening houden dat ik het over mathematische bewerkingen had, waar het eigenlijk maar dwaas is om sommige bewerkingen over 20 regels te splitsen (nu overdrijf ik, ik weet het). In dergelijke code kan het soms (programmatorisch) beter zijn om het oo-concept achterwege te laten . Vergeet niet dat dit vaak enkel in zeer kleine kernen komt, hoger gelegen subsystemen zullen veel vaker weer niet rechtstreeks gebruik maken van die x,y,z,w waarden maar van mooie klasses die alles integreren. Een andere optie is natuurlijk in deze kern met het friend keyword te werken (wat ik dacht ik deed in men math library).

Maar like said: ikzelf sluit alles af en doe het via omslachtige manier hoor. Reden waarom ik dit opmerkte & als vb. gaf was omdat daarover al eens gediscussieerd was. Dan zat ik in jouw plaats er TEGEN te argumenteren en die persoon (ik dacht kwitters) had eigenlijk wel ergens gelijk . Op dat vlak zijn de properties van C# een zegen, spijtig dat je die niet kan emuleren via templateprogramming ofzo (het is me toch nog niet gelukt om het doenbaar zo te doen ).

edit, ik was aan wat imageprocessing bezig vandaag in java ( ad: ) en moest met rectangle klasse werken : http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Rectangle.html . Dit is nu in zo een taal waar afscherming centraal staat .