[alg / Delphi] Public variabele vs. property

[OZ-Gump]

Naatmate je langer bezig bent met programmeren, wordt de hoeveelheid code die je gezien hebt (en als je geluk hebt de hoeveelheid kennis die je bezit) almaar groter. Omdat ik ook wel van het bjihouden van vakliteratuur ben, ben ik al enkele keren tegengekomen dat globale variabelen eigenlijk not done zijn. Ik vraag me echter iets af over hoe je het dan oplost.....

question
Zoals gezegd is de public variabele vaak verguisd en wordt keer op keer aangegeven als zijnde een slechte oplossing voor als je applicatie-breed een variabele wilt gebruiken. Mijn vraag is wat eigenlijk het voordeel is van

Delphi:

type  TfrmMain = class(TForm)
  private
   { Private declarations }
    ComPrt : integer;
  public
    { Public declarations }
    property ComForRF : integer read ComPrt write ComPrt;
  end;

boven het gebruik van een globale variabele. De property lijkt evenzo beschikbaar als een globale variabele...? Ik kom op enkele plaatsen (internetpagina's) een voorkeur voor deze werkwijze tegen, maar vind nergens een goede verklaring waarom dit nou zoveel beter is dan een globale variabele.

Ik ben benieuwd wat de gemiddelde tweaker hier van denkt, en of ik misschien nog iets kan leren vandaag...

[ Voor 4% gewijzigd door OZ-Gump op 29-01-2004 16:06 ]

[Verwijderd]

Volgens mij is er niet echt sprake van een voordeel voor een van de twee. Sommige talen ondersteunen gewoonweg properties niet (waaronder Java). Het is dus maar net wat je gewend bent (als je Java bent begonnen en altijd getters en setters hebt geschreven, dan zal het wennen aan native properties in een andere taal lastiger zijn dan als je je hele leven lang alle properties loopt te bouwen in bijvoorbeeld Delphi).
Bij de meeste implementaties van properties, is er een mogelijkheid voor het toevoegen van extra functionaliteit aan de setter. Dit kan wel handig zijn (extra controle: bijvoorbeeld een integer die tussen 20 en 100 ligt mag wel worden geset, alle andere waarden niet).

Weet niet of er ook resourcetechnische voor en nadelen aan deze twee opties zitten? Misschien kan iemand hier meer over zeggen?

[Alarmnummer]

Bij een globale variable heb je 0.0 controle over wie er iets mee doet, en wat ermee gedaan wordt en bij getters/setter properties wel. Verschil tussen getters/setters en property bestaan imho niet afgezien van syntactische vriendelijkheid van de laatste.

*ergert zich ook nog groen en geel aan het feit dat java geen properties heeft*

[ Voor 8% gewijzigd door Alarmnummer op 29-01-2004 17:06 ]

[Weng]

Wat ik mij vaak afvraag is waarom een get/set de voorkeur krijgt boven een public variabele. Kan iemand mij dat vertellen?

Een voordeel die ik kan bedenken met een setfunctie is dat je bv een soort range kan bepalen van wat er in de variabele kan. Maar dat is meestal ook niet echt nodig.

/Edit: Hmm.. Ik geloof dat de topicstarter hetzelfde afvraagt als ik, maar dan haalt hij wel global en public door elkaar.

[ Voor 18% gewijzigd door Weng op 29-01-2004 18:46 ]

[Alarmnummer]

Weng schreef op 29 januari 2004 @ 18:43:
Wat ik mij vaak afvraag is waarom een get/set de voorkeur krijgt boven een public variabele. Kan iemand mij dat vertellen?

Je hebt dan 0.0 controle over wat er met die variable gebeurt. Je kan met getters en setters bepalen of iets gelezen of geschreven kan worden (en dus ook kiezen om bv alleen lezen te maken). Ook kan je ook functionaliteit toevoegen zoals events rondsturen als een waarde veranderd is. En je zou er bv voor kunnen kiezen om de daadwerkelijke informatie ergens anders op te slaan (bv op een andere pc). Mbv getters/setters/properties stel je een bepaald contract op voor je klass waar hij zich aan moet houden, maar hoe het geimplementeerd is maakt niet uit.

[Weng]

Alarmnummer schreef op 29 januari 2004 @ 18:49:
[...]

Je hebt dan 0.0 controle over wat er met die variable gebeurt. Je kan met getters en setters bepalen of iets gelezen of geschreven kan worden (en dus ook kiezen om bv alleen lezen te maken).

Ik bedoelde ook als je een get EN een set maakt. Maar dat kwam niet echt duidelijk naar voren in mijn vraag.

Maar bedankt voor het duidelijke antwoord op mijn vraag

[Tomatoman]

Weng schreef op 29 januari 2004 @ 18:55:
[...]


Ik bedoelde ook als je een get EN een set maakt. Maar dat kwam niet echt duidelijk naar voren in mijn vraag.

Of een property een getter en setter gebruikt of dat direct een field variable wordt aangesproken, maakt geen verschil. Dat is een kwestie van implementatie en die property is er nou juist om de implementatie voor jou te verbergen.

[ Voor 1% gewijzigd door Tomatoman op 29-01-2004 19:00 . Reden: typo ]

[Verwijderd]

Voordelen van properties tov van fields (terminologie van C#)

- Properties kunnen Read of Write only gemaakt worden door alleen de Get of Set te implementeren

- Afhankelijkheid van properties komt niet in gevaar. bijv. bij een temperatuur die in de klasse benaderbaar is via de properties Fahrenheit, Celsius en Kelvin. Deze properties zijn allemaal afhankelijk van 1 interne temperatuurwaarde.

- Afdwingen van geldige waarden in set. bijv. temperatuur (in Celsius) mag niet onder -273 komen.

- En vast nog wel meer, waar ik nu niet op kan komen.

En soms is het inderdaad niet nodig om de Get/Set constructie te gebruiken.

[Tomatoman]

Verwijderd schreef op 29 januari 2004 @ 19:02:
- Afdwingen van geldige waarden in set. bijv. temperatuur (in Celsius) mag niet onder -273 komen.

-273,15

[_Thanatos_]

Van een variabele kun je zomaar het geheugenadres veranderen, bij een property kun je dat ook wel vergeten. Maar van een property kun je ook weer geen geheugenadres opvragen (of dat een voor- of nadeel is, is ook weer discutabel) en je kunt em ook niet als "var" parameter aan een functie meegeven.

Persoonlijk vindt ik het werken met properties fijner, omdat je dan op 1 centrale plek kan regelen wat er moet gebeuren als iets de waarde ervan instelt, mocht dat ooit nodig worden. Ik heb in het verleden te vaak de fout gemaakt dat ik m'n halve source moest doorworstelen of een variabele + dezelfde code op 345 plekken te vervangen door een nette property.

[OZ-Gump]

Inderdaad, ik heb public en globaal door elkaar gehaald. En ik dacht nog wel dat ik mijn post wél goed doorgelezen had voor ik op verstuur bericht klikte. Dat neemt niet weg dat dit nuttig is om te lezen!

Dan gooi ik de discussie nu in de richting van globale variabelen en een property van een form. Iemand goede argumenten waarom de property hier de voorkeur geniet? Of blijven ook hier de argumenten van de 'events' en het controleren van eventuele ranges de belangrijkste reden om voor een property te kiezen?

[Verwijderd]

Het gebruik van properties of get en set methode, is meer dan alleen een manier om je variabelen te beschermen. Het wordt veelal ook gezien als een nette manier van programmeren.
Zoals je al aangeeft zijn er inderdaad situaties waarbij het verschil tussen een public variabelen en een properties (of private var met getter en setter) te verwaarlozen is. Maar toch is dit de meeste gebruikte manier voor programmeurs om locale variabelen van buitenaf te benaderen.

[_Thanatos_]

Ohja, een ander nadeel van globale variabelen is dat eigenlijk niet zo duidelijk in je code is, wat je aan het doen bent. Je roept bijv een variabele "sft_blabla_a" aan, maar daaruit is helemaal niet duidelijk wat je er nou mee aan het doen bent of bij welk anders tk source het hoort. Als je de property MainForm.Blabla aanroept, is gelijk duidelijk waar ie vandaan komt, waar ie staat en waar ie bij hoort. Bedenk alleen wel dat MainForm ook weer een globale variabele is...

[LordLarry]

_Thanatos_ schreef op 30 januari 2004 @ 10:12:
Bedenk alleen wel dat MainForm ook weer een globale variabele is...

Niet als je m alleen benaderd via Application.MainForm. Bedenk alleen wel dat Application ook weer een globale variable is...

[_Thanatos_]

Mooi zou idd zijn als als Application een static class was. Maar Application.MainForm moet je dan wel weer gaan casten enzo. Dus op een full-OO manier zou je zoiets krijgen

Delphi:

TMainForm(TApplication.MainForm).Blabla = 0;

Wat natuurlijk niet handig is en gelukkig niet werkt

[Tomatoman]

Een ander voordeel van het gebruik van properties, vind ik, is dat je gedwongen bent wat beter over de scope van de objecten toe behoren.

Stel dat je een unit Toegankelijk en een unit Verboden hebt. Andere units mogen wel toegang krijgen tot de unit Toegankelijk, maar niet tot Verboden. Wat nou als je een globale variabele GeluidAan in unit Verboden toch toegankelijk wilt maken? Dat lukt je alleen door Verboden toe te voegen aan de usus clause van alle overige units. Gevolg: unit Verboden is vrij toegankelijk (terwijl je dat niet wilt).

Een betere benadering is het gebruik van een class TGeluid met de property GeluidAan. TGeluid implementeer je in de unit Verboden, waar alleen de unit Toegankelijk toegang toe heeft. Mocht een andere unit het geluid aan of uit willen zetten, dan vraagt het instantie van TGeluid aan de unit Toegankelijk (waar hij ook weer als een property beschikbaar is). Daarmee kan de hele unit Verboden verborgen blijven voor de overige units.