Archief - [PROG] Gebruik van getters en setters

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

PsyKi

Legacy Member
Ik zet ook al mijn variabelen private en los het dan ook op via getters en setters.

Er is mij altijd aangeleerd dat dit een veel beter manier is, en dit vind ik persoonlijk ook. Je hebt veel meer controle, ..
+ wijzigingen kan je makkelijker opvangen. Uw variabele naam of type veranderen moet slechts op 1 plaats.
bvb een float die int moet worden.
Ipv in elke klasse dan een afronding te doen, moet dit nu enkel in de setter.

Wat jij zegt, getters en setters schrijven die daarna nergens gebruikt worden doe ik niet. Als er waardes toegevoegd worden vanuit die klasse zelf, hard-coded, dan gebruik ik ook gewoon = (of gewoon constantes).

.Acku.

Legacy Member
De discussie gaat eigenlijk veel verder dan dat, uw properties exposen via getters/setters maakt eigenlijk weinig uit qua encapsulatie. Als je dat echt wilt dan horen je objecten immutable te zijn, of minstens enkel gedragmethodes te exposen die de interne staat wijzigen.

killgore

Legacy Member
.Acku. zei:
De discussie gaat eigenlijk veel verder dan dat, uw properties exposen via getters/setters maakt eigenlijk weinig uit qua encapsulatie. Als je dat echt wilt dan horen je objecten immutable te zijn, of minstens enkel gedragmethodes te exposen die de interne staat wijzigen.
Voor vele objecten gaat dit op, maar voor sommige, zoals de hiervoor getoonde vectorklassen vind ik dit er wat over hoor, deze moet je wel degelijk gewoon kunnen setten en niet enkel via gedragsmethoden aanpassen.

Dat geldt eigenlijk voor extreem veel mathematische objecten :p.

Immutability is een zekere vorm van encapsulatie, maar zeker niet de enige/ultieme vorm.

Vich

Legacy Member
killgore zei:
[...] maar zeker niet de enige/ultieme vorm.
Inderdaad! Er zullen altijd uitzonderingen zijn, dat is nu eenmaal programmeren :)
Net zoals een "goto" in de meeste gevallen evil is, maar het is een feit dat er uitzonderingen zijn.

UniKorn

Legacy Member
Wat een zalige thread :) Dju ik moet hier toch meer terug komen zien. Een paar opmerkingen(ik weet dat er oude koeien bij zitten):

edit: vind het wel grappig over die "geen tijd voor analyse". Bij alle info die ik krijg voor computerwetenschappen staat er dat een computerwetenschapper in de eerste plaats een softwareONTWERPER is (dus analytisch), het programmeren is iets bijkomstig

Spijtig genoeg is dit in het echte leven niet zo. Het is inderdaad zo dat software ontwikkelen op de eerste plaats analyse is, maar als een klant kan kiezen tussen:

40 manuren voor zijn applicatie
80 manuren voor zijn applicatie

haalt de goedkoopste oplossing het. Je kan dat counteren door een goed framework the schrijven, maar de meeste managers geven je daar de tijd niet voor. Hun resultaten worden per maand gereviewed. Daarbovenop als er daarna wijzigingen in de applicatie moeten gebeuren en die duren langer brengt het meer op, dus hun kan dat eigenlijk niets schelen.

Als ik nu publieke variabelen oproep dan kan ik toch nog altijd checken of een vector leeg is of niet en geen error krijgen. Kzeg niet dat dat goed is maar ge kunt dat toch opvangen. In een game is dat niet belangerijk als ge het ergens anders opvangt.

Dat kan je inderdaad. Maar ben jij er zo zeker van dat je dat 8 weken later nog weet dat je dat moet doen? En ben je zeker dat je het op geen enkele plaats gaat vergeten? En als die controle ooit verandert omdat er een fout inzit, in welke applicatie zou je dat dan het liefste aanpassen?


class Vector2D {
public double x;
public double y;

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.
Persoonlijk hou ik mijn code liefst zo eenvoudig en duidelijk mogelijk. En vind ik
position.x += speed.x
duidelijker en makkelijker te debuggen dan
position.setX( position.getX() + speed.getX() )

Ik zou nooit mijn x en y public maken.

En op een 2D item heb je voor maar 3 functies nodig.

MoveHorizontal(int) this.position.y = 0;
MoveVertical(int) this.position.x = 0;
SetSpeed(float) this.speed = 1;
ChangeSpeedMultiplier(float) this.speed *= 0.9

Dit laat je toe om in de movehorizontal en movevertical na te gaan (stel je linksbeneden pos is 0.0) en rechtsboven = (screenwidth,screenheight) of je niet buiten je speelveld gaat, je colission te testen enzovoort. Allemaal op 1 plek.

Getters en Setters worden meestal wel gedocumenteerd, kijk maar naar alles van Microsoft, Sun, Game SDK's etc.

Idd, maar deze doc is meestal gewoon een uitleg van wat de property juist is :)

killgore

Legacy Member
UniKorn zei:
Spijtig genoeg is dit in het echte leven niet zo. Het is inderdaad zo dat software ontwikkelen op de eerste plaats analyse is, maar als een klant kan kiezen tussen:

40 manuren voor zijn applicatie
80 manuren voor zijn applicatie

haalt de goedkoopste oplossing het. Je kan dat counteren door een goed framework the schrijven, maar de meeste managers geven je daar de tijd niet voor. Hun resultaten worden per maand gereviewed. Daarbovenop als er daarna wijzigingen in de applicatie moeten gebeuren en die duren langer brengt het meer op, dus hun kan dat eigenlijk niets schelen.
Kweetet ze :p, kwou effe wijzen op het verschil "theorie (les)" <-> praktijk. Zoals ik hiervoor zei: een complete, supergrondige analyse (lees: "elke" klasse op voorhand gaan modelleren) is imho tijdsverspilling (en in het commerciële milieu geldverspilling :p).

Lang geleden trouwes, liggen de wow servers plat mssch :p?

QplQyer

Legacy Member
Tijd en geldverspilling, tot een ander team het moet overnemen en al die tijd die gewonnen is in het begin weer kwijtraakt aan het uitzoeken van hoe alles nu werkt.

Ze zeggen van formele methoden ook dat het tijdverspilling is, tot als de deur van je auto tijdens het rijden openvalt of een raket naar beneden gaat omdat er een overflow optreedt en de versnelling negatief wordt (die twee zaken zijn werkelijk gebeurd en waren te wijten aan softwarefouten).

Nu weet ik weer waarom ik niet direct zin heb om developer te worden, met zulk een mentaliteit van directeurs en managers.

killgore

Legacy Member
right

weer eens iemand die men woorden misinterpreteert.

Er is een verschil tussen zeggen : die overdreven gedetailleerde pre-analyse is onnuttig en verspilling van tijd & geld
en zeggen: "je moet helemaal niet aan analyse doen".

Is het nu zo moeilijk om te zien dat er een tussenpad is.

De vbn die jij geeft zijn extreem (de meeste programmeurs zullen nog steeds gewoon voor pc ontwikkelen) en hangen niet 100% samen met enkel pre-analyse maar ook post-analyse (met voornamelijk testen) en programmatiekennis in het algemeen.

edit: als je je code trouwens deftig becommentarieerd (waardoor je met de nodige tools docs kan laten genereren) en je hebt op voorhand deftige uml-schemas van het algemene systeem gemaakt zie ik geen probleem voor dat andere team.

QplQyer

Legacy Member
killgore zei:
De vbn die jij geeft zijn extreem (de meeste programmeurs zullen nog steeds gewoon voor pc ontwikkelen) en hangen niet 100% samen met enkel pre-analyse maar ook post-analyse (met voornamelijk testen) en programmatiekennis in het algemeen.
Het zijn extreme voorbeelden uiteraard, maar ze zijn wel voorgevallen doordat men dacht "testen is genoeg", het gaat dus niet over "voornamelijk testen", want dat is geen afdoende middel om te garanderen dat je programma correct en foutloos zal verlopen. Formele methoden zijn middelen die je gebruikt tijdens het designen van je programma om te controleren of je design klopt en naderhand om te controleren of je implementatie wel klopt met wat je wilt dat het programma doet, zonder te testen.

In verband met de edit zal het team daar wel kunnen inpikken, het probleem is waar trek je de grens van "dit modelleer ik nog wel even" en dit niet.
Als je met tijd- en geldverspilling redeneert schuift die grens nogal vaak op naar "dit is misschien toch niet nodig".

Het was dan ook niet noodzakelijk zo tegen jou specifiek bedoeld, in zijn algemeenheid sprak ik mij erover uit.

killgore

Legacy Member
Mja, tkwam persoonlijk over nadat ik dat hier had gepost.
Ik vind persoonlijk wat ik hoor van mensen in bedrijfswereld er over, dat is té weinig analyse, maar ergens wel begrijpelijk ... .

Met die voornamelijk testen bedoelde ik niet dat dat alles was, ik zei dat dat een groot deel is van uw post-analyse :p. Dit is ook niet gewoon uw programma een paar keer laten lopen maar met test units extreme situaties erop afschieten en bij mathematische methoden zeker gaan testen op overflow e.d.m. . Nuja, natuurlijk weerom: waar nodig, in de vbn die jij gaf is dat vrij noodzakelijk aangezien dat niveau nogal wat gevoeliger ligt als de gemiddelde pc-app.
Het testen op zich is met zaken als test units veel verbeterd en heeft meer en meer aandacht gekregen de laatste jaren. Het is niet meer gewoon: we laten ons programmake 100 uur lopen, proberen er van alles mee en zien of het geen fouten geeft. Er wordt meer nadruk gelegd op componentsgewijs testen. Weerom: als het nodig/mogelijk is, ik denk niet dat vele gewone softwareontwikkelaars de tijd vinden om overal unit tests voor te schrijven, maar het kan wel extreme voordelen bieden in zaken die jij bv. gaf.

Een overflow detecteren heeft btw niet zo extreem veel te maken met voorafgaande analyse in de vorm van uml-design edm. Wel met formele methoden zoals jij aangaf.
Formele methoden zijn natuurlijk belangerijk, maar zeg nu niet dat het nuttig is die op elke code toe te passen.

Heb je het btw op de ariane-5 raket :)?

QplQyer

Legacy Member
Jup Ariane 5 had ik het op.

Formele methoden toepassen zonder specificaties is niet echt mogelijk, vandaar dat UML-schema's (of andere vormen van modellen voor specificaties) daar ook reeds belangrijk zijn, zodat je een specificatie hebt van je programma waarop je heel de bazaar kan loslaten.

Persoonlijk denk ik wel dat het nuttig kan zijn om ze bijna overal te gebruiken, maar met de huidige stand van de technologie/beschikbare programma's is dat uiteraard nog niet mogelijk (omdat het tijdrovend is en voor een Datum-klasse is dat er allicht wel over, alhoewel, ik denk nu net aan de Y2K-bug, het is dus soms wel verraderlijk om bij kleine klasjes te denken dat het zinloos is), daarvoor zou het iets moeten worden ala click and proof.

UniKorn

Legacy Member
Het probleem is dat de gouden tijden over zijn. Vroeger waren de meeste contracten times and means : je wordt betaalt per dag, en duurt het langer dan voorzien dan zijn de kosten voor de klant. Nu zijn de meeste projected fixed price. Dat wil zeggen dat je op voorhand schat hoeveel dagen dat het gaat kosten, en daarna moet je het op die tijd doen. In die schattingen zitten altijd een paar dagen documenteren in, maar die dagen worden in 95% van de gevallen gebruikt om nog bugs te fixen en te testen. Dus documentatie kan je in 95% van de gevallen niet schrijven omdat het je dan extra geld kost.

En de mentaliteit van de directeurs is begrijpelijk. Als jij op het einde van het jaar een bonus krijgt van een aantal keer je loon afhankelijk van hoe je cijfers zijn, wat zou jou het dan kunnen schelen dat de programmeur moet zweten. Hij heeft uiteindelijk zijn bonus op het einde van het jaar.

Stillekesaan begint die mentaliteit wel te veranderen omdat er verschillende contracten verloren worden omdat de klant stillekesaan de termen framework, code generators enzovoort begint te kennen. Dus langzaamaan beginnen de bedrijven een deel van hun "winst" te steken in oplossingen die een pak beter herbruikbaar zijn. Op dit ogenblik hebben wij een redelijk generiek framework dat ons toelaat om op een vrij snelle manier een vrij complexe databased applicatie te ontwikkelen aangepast aan de noden van de klant.

.Acku.

Legacy Member
UniKorn zei:
Het probleem is dat de gouden tijden over zijn. Vroeger waren de meeste contracten times and means : je wordt betaalt per dag, en duurt het langer dan voorzien dan zijn de kosten voor de klant. Nu zijn de meeste projected fixed price. Dat wil zeggen dat je op voorhand schat hoeveel dagen dat het gaat kosten, en daarna moet je het op die tijd doen. In die schattingen zitten altijd een paar dagen documenteren in, maar die dagen worden in 95% van de gevallen gebruikt om nog bugs te fixen en te testen. Dus documentatie kan je in 95% van de gevallen niet schrijven omdat het je dan extra geld kost.

En de mentaliteit van de directeurs is begrijpelijk. Als jij op het einde van het jaar een bonus krijgt van een aantal keer je loon afhankelijk van hoe je cijfers zijn, wat zou jou het dan kunnen schelen dat de programmeur moet zweten. Hij heeft uiteindelijk zijn bonus op het einde van het jaar.

Stillekesaan begint die mentaliteit wel te veranderen omdat er verschillende contracten verloren worden omdat de klant stillekesaan de termen framework, code generators enzovoort begint te kennen. Dus langzaamaan beginnen de bedrijven een deel van hun "winst" te steken in oplossingen die een pak beter herbruikbaar zijn. Op dit ogenblik hebben wij een redelijk generiek framework dat ons toelaat om op een vrij snelle manier een vrij complexe databased applicatie te ontwikkelen aangepast aan de noden van de klant.

Hallo, mede-consultant ;)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan