[C#] this.Property of this.property

[Verwijderd]

Wat is gebruikelijk? Binnen je class verwijzen naar de private property of verwijzen naar de public property?

C#:

private int maxsize;
public int Maxsize
{
   get { return maxsize; }
   set { maxsize = value; }
}

private bool IsLargerThan(int size)
{
    return size > Maxsize; 
   // return size > maxsize;
}

Is het ene beter dan het ander of maakt het niet zoveel uit?

[lier]

Het netste is om via je getter en setter de private properties te benaderen. Met name als je in de logica voor het getten en setten een wijziging maakt, blijkt hiervan het voordeel.

[pistole]

Denkend aan verwaarloosbare kleine en weggecompileerde overhead zou ik de private nemen.
Maar is dat een heel topic waard?

edit:
lier's opmerking snijdt meer hout

[ Voor 16% gewijzigd door pistole op 21-04-2008 13:33 ]

[Cloud]

Vaak gebruikt men daarvoor wel de public property ja. Zo hoef je maar op één punt de implementatie te veranderen, mocht dat nodig zijn. Stel je voor, dat er bijvoorbeeld nog meer code uitgevoerd moet worden als MaxSize verandert. Natuurlijk gebeurt dit met veel properties nooit, maar dan is je code al wel voorbereid.

Het maakt verder niet veel uit, maar het is wel netter, imho.

[Big Womly]

Je klasse is op de hoogte van zijn eigen variabelen en heeft ook de verantwoordelijkheid over zijn eigen variabelelen. Ik laat het direct verwijzen naar de private property, zeker in dit geval want het maakt echt totaal geen verschil (geen checks, geen loops, ...) enkel heb je nu een procedureoproep meer.

edit: lier en wolkje hebben wel een punt... Ik ga mijn manier van werken wat aanpassen

[ Voor 13% gewijzigd door Big Womly op 21-04-2008 13:35 ]

[BikkelZ]

Het hangt er van af, als er code in je get / set zit voor checking and sanitizing, dan moet je daar al je ongecheckte code doorheen halen, dus ook bijvoorbeeld via de constructor. Eigenlijk moeten alle variabelen die van buiten komen die bewaard worden of naar buiten gaan altijd via deze encapsulation functies heen gehaald worden.

Ik heb toch wel vaker meegemaakt dat ik alsnog iets anders wilde doen en daarom wel iets wilde doen met data die naar buiten ging of juist naar binnen, en dan ben je opeens 20 lowercase referenties aan het bijwerken.

[roy-t]

Waarom gebruik je nu uberhaupt 2 properties? Het hele nut van accesmodifiers is toch juist dat je op deze manier niet meer allemaal extra dingen hoeft te maken zoals getters en setters.

Het enige wat ik me kan voorstellen is bang zijn voor pass by reference, maar dat gaat via zo'n contructie ook fout. (en is natuurlijk nvt op een int, maar bijvoorbeeld hé)

Dus tja..

[Haan]

Grappig, ik zat me dit een paar dagen geleden ook al af te vragen Ik gebruikte zelf meestal de Property, wat lier zegt is ook zeker een reden om dat te doen.

@roy-t: waarschijnlijk gebruik je zelf geen C#?

[ Voor 13% gewijzigd door Haan op 21-04-2008 13:38 ]

[Verwijderd]

Haan schreef op maandag 21 april 2008 @ 13:36:
Grappig, ik zat me dit een paar dagen geleden ook al af te vragen Ik gebruikte zelf meestal de Property, wat lier zegt is ook zeker een reden om dat te doen.

@roy-t: waarschijnlijk gebruik je zelf geen C#?

Het is zelfs een standaard way of work volgens Microsoft! Eigenlijk vind ik zelfs dat je voor je private een underscore moet zetten voor de leesbaarheid!

[ Voor 11% gewijzigd door Verwijderd op 21-04-2008 13:40 ]

[Verwijderd]

roy-t schreef op maandag 21 april 2008 @ 13:35:
Waarom gebruik je nu uberhaupt 2 properties? Het hele nut van accesmodifiers is toch juist dat je op deze manier niet meer allemaal extra dingen hoeft te maken zoals getters en setters.

Het enige wat ik me kan voorstellen is bang zijn voor pass by reference, maar dat gaat via zo'n contructie ook fout. (en is natuurlijk nvt op een int, maar bijvoorbeeld hé)

Dus tja..

uhm zelfs met getter en setter blijft het voor object types by ref.... Je kan een object niet by val over kloppen.. tenminste niet in c#. je zou het hele object moeten clonen, en dan wel per property, want de clone functie werkt niet.....

[Snake]

Sinds C# 3.0 zijn er automatic properties. Dat wil zeggen:

C#:

public String SurName { get; set; }
public String Name { get; set; }
public String ID { get; private set; }

public void CalculateID()
{
   this.ID = this.SurName + this.Name + this.GenerateRandomID();
}

private int GenerateRandomID()
{
   //generate ID based on contents of DB 
   return ID;
}

Dan hebt ge die private var dus niet meer Dus gewoon de Propertie. Wel handig die C#

[apokalypse]

Ik vraag me het soms ook af, maar ik gebruik juist intern de privates, omdat:

• De klasse is verantwoordelijk voor zijn eigen gedrag, en mag dus overal aan zitten
• De public properties zijn voor de buitenwereld, niet voor intern.
• Als je een public property weghaalt, kan dit anders problemen opleveren met het interne gedrag. (niet gewenst)
• Meer consistent; men kan altijd de privates gebruiken. Anders wordt het een combi van publics & privates.

[Niemand_Anders]

Property geeft een zeer lichte extra overhead ten opzichte van property, maar dat weegt zeker niet op tegen de voordelen van Property. Sinds c# 3.0 kun je ook op deze manier (read/write)properties declaren

code:

public int MaxSize { get; set; }

Je hebt dan geen (bekende) interne variabele welke je kunt gebruiken en op het moment dat de setter extra controle nodig heeft (bijv. waarde moet altijd positief zijn) kan kun je altijd nog een custom getter en setter implementatie maken zonder dat de rest van je applicatie (code) wijzigt. De interne waarde wordt dan ook maar door 1 code blok aangepast en dat maakt debugging in geval van problemen ook eenvoudiger.

Mijn advies: Gebruik altijd de public properties.

[roy-t]

Verwijderd schreef op maandag 21 april 2008 @ 13:41:
[...]


uhm zelfs met getter en setter blijft het voor object types by ref.... Je kan een object niet by val over kloppen.. tenminste niet in c#. je zou het hele object moeten clonen, en dan wel per property, want de clone functie werkt niet.....

Ehm.. lees post, staat in dat het bij primitives (value types in C#) pass by value is, maar dat ik het als voorbeeld aangeef, ik impliceer dus indirect dat het pass by ref is, en ik zeg dat je afscherming van pass by value zo dus niet werkt!

Verder bedoel ik het dus zoals Snake (2 post hoger) zegt.

En gebruik ik eigenlijk alleen maar C#.

apokalypse schreef op maandag 21 april 2008 @ 13:42:
Ik vraag me het soms ook af, maar ik gebruik juist intern de privates, omdat:

• De klasse is verantwoordelijk voor zijn eigen gedrag, en mag dus overal aan zitten
• De public properties zijn voor de buitenwereld, niet voor intern.
• Als je een public property weghaalt, kan dit anders problemen opleveren met het interne gedrag. (niet gewenst)
• Meer consistent; men kan altijd de privates gebruiken. Anders wordt het een combi van publics & privates.

Ik vond uberhaupt dat je er over nadacht (wat aangeeft dat je zeker op een goed programmeer niveau zit) het al vreemd dat je het zo deed zonder ondebouwing, ik had geen idee dat dit de standaard microsoft way to go is.

-Maar eigenlijk vind ik dat alleen punt 1 stand houd (wat wel meteen groot voordeel is) Ik had er niet bij nagedacht dat als je bij een getter of setter de data echt veranderd dat ook voor het object zelf gebeurt. (tsja ik gebruik zelf nauwelijks properties omdat ik vanuit mijn studie Java leer met getters en setters en dan in C# nogwel is vergeet dat dit niet hoeft + vaak het werken met rauwe data het makkenlijkste vind)

-Dat public properties voor de buitenwereld zijn (exclusief) vind ik meer filosofisch dan programmeer technisch een punt, ik neem aan dat er voor de compiler nauwelijks overhead/verschil is in een variabele afschermen (of niet) voor de buitenwereld.

-Verder als een public zowel een public als een private is en je wil geen public var meer dan haal je niet de public weg maar zet je er private voor ipv public.. dit vind ik dus helaas een non argument

-Je laatste punt volg ik niet, "je kan de privates altijd gebruiken" een object kan zowel de eigen public als ook zijn eigen private properties altijd gebruiken?


Maar ik vind dat je met punt 1 een heel goed argument hebt, zodra een variabele veranderd moet worden voor de buitenwereld is het handig om met properties icm een public en private variabele te werken. Echter als het slechts een simpele getter of setter is kun je ze zelfs beter gewoon weglaten

[Verwijderd]

Niemand_Anders schreef op maandag 21 april 2008 @ 13:48:
Property geeft een zeer lichte extra overhead ten opzichte van property, maar dat weegt zeker niet op tegen de voordelen van Property. Sinds c# 3.0 kun je ook op deze manier (read/write)properties declaren

code:

public int MaxSize { get; set; }

Nog mooier zelfs kwam ik laatst achter. Dit werkt ook!

code:

public int MaxSize { get; private set; }

Dan heb je dus een property MaxSize die een public get en een private set heeft

't fijne van deze manier van properties maken is dat 't super simpel in elkaar zit, en dat als je uiteindelijk toch een wat uitgebreidere get en/of set wilt maken je alvast voorbereid bent. Ook zijn properties natuurlijk nodig voor de databinding hier en daar...

[apokalypse]

-Dat public properties voor de buitenwereld zijn (exclusief) vind ik meer filosofisch dan programmeer technisch een punt, ik neem aan dat er voor de compiler nauwelijks overhead/verschil is in een variabele afschermen (of niet) voor de buitenwereld.

Programmeren is ook filosofisch. De compiler maakt het echt niet uit of je een net (OO) design maakt, of gewoon imperatief programmeert. Voor wij mensen meestal wel

-Verder als een public zowel een public als een private is en je wil geen public var meer dan haal je niet de public weg maar zet je er private voor ipv public.. dit vind ik dus helaas een non argument

Maar dus het interne gedrag wordt dan afhankelijk van het 'uiterlijk' naar de buitenwereld. Natuurlijk is het aanpassen misschien niet veel werk, maar dit klopt naar mijn mening niet.

-Je laatste punt volg ik niet, "je kan de privates altijd gebruiken" een object kan zowel de eigen public als ook zijn eigen private properties altijd gebruiken?

Als je probeert de public properties te gebruiken, kan dit niet altijd. Sommige properties zijn alleen voor intern gebruik => je gebruik dus private en public properties door elkaar.
Terwijl als je altijd de privates gebruikt, is dit geen 'probleem'. Je gebruikt altijd de privates => meer consistent. Puur design technisch probleem

meeste van mijn argumenten zijn dus vanuit code design. Wat de compiler denkt kan me niet zo boeie

[Killemov]

Vanuit OO-standpunt is extern gebruik van fields af te raden. Voor intern gebruik is het direct benaderen van fields handiger ...

offtopic:
De IsLargerThan(int size) is private dus niet aanroepbaar?
Is het standaard MicroSoft/C# notatie om methods met een hoofdletter te laten beginnen?
(Ik ben zelf Javaan vandaar.)

[roy-t]

apokalypse schreef op maandag 21 april 2008 @ 14:02:
[...]

Programmeren is ook filosofisch. De compiler maakt het echt niet uit of je een net (OO) design maakt, of gewoon imperatief programmeert. Voor wij mensen meestal wel

Mwah nee hier overtuig je me nog niet mee. Maargoed zolang het om kleine objecten of primitives gaan zijn beide opties goed, maar zodra je grotere objecten gaat gebruiken wil je toch het liefst zo min mogenlijk geheugen claimen.

Maar dus het interne gedrag wordt dan afhankelijk van het 'uiterlijk' naar de buitenwereld. Natuurlijk is het aanpassen misschien niet veel werk, maar dit klopt naar mijn mening niet.

Hmm, nee, je interne gedrag blijft exact hetzelfde, immers public of private veranderd niets voor het interne gedrag, het externe gedrag veranderen (door een public te deleten of als je er maar 1 hebt die private te maken) veranderd wel en uiteidenlijk eindig je met exact dezelfde situatie, een private

Als je probeert de public properties te gebruiken, kan dit niet altijd. Sommige properties zijn alleen voor intern gebruik => je gebruik dus private en public properties door elkaar.
Terwijl als je altijd de privates gebruikt, is dit geen 'probleem'. Je gebruikt altijd de privates => meer consistent. Puur design technisch probleem

meeste van mijn argumenten zijn dus vanuit code design. Wat de compiler denkt kan me niet zo boeie

Ok, point taken, hier kan ik me in vinden en dit treed natuurlijk vooral op als je al properties gebruikt, maargoed je overtuigd me langzaam aan, mooie discussie trouwens


@Killemov, inderdaad Java -> methodA, C# MethodA ik stond er zelf ook van te kijken dat al die rare Javanen met een kleine letter begonnen , imho is het handig om methods met een hoofdletter te doen, variabelen beginnen immers al met een kleine letter

En de IsLargetThan is zowel van uit 'public space' als 'private space' te gebruiken hoor

[ Voor 9% gewijzigd door roy-t op 21-04-2008 14:21 ]

[Verwijderd]

Killemov schreef op maandag 21 april 2008 @ 14:18:
Vanuit OO-standpunt is extern gebruik van fields af te raden. Voor intern gebruik is het direct benaderen van fields handiger ...

offtopic:
De IsLargerThan(int size) is private dus niet aanroepbaar?
Is het standaard MicroSoft/C# notatie om methods met een hoofdletter te laten beginnen?
(Ik ben zelf Javaan vandaar.)

private = alleen aan te roepen door het object zelf.

Conventie: private methode/property beginnen met kleine letter, public met hoofdletter.

Dus in het voorbeeld van de TS had het ofwel
private isLargerThan() of
public IsLargerThan() moeten zijn .

[Verwijderd]

Verwijderd schreef op maandag 21 april 2008 @ 14:41:
[...]

private = alleen aan te roepen door het object zelf.

Conventie: private methode/property beginnen met kleine letter, public met hoofdletter.

Dus in het voorbeeld van de TS had het ofwel
private isLargerThan() of
public IsLargerThan() moeten zijn .

Wow.. ook voor methodes een verschillende manier van CamelCasing. Wij houden het gewoon bij HoofdLetterMethod() hoor

Waarom ik het vraag: laatst is hier een programmeur vertrokken. Hij gebruikt vooral verwijzen naar de private property. Zelf verwijs ik ook liever naar de Public, juist omdat er in de getter wel eens wat logica kan staan.

Theoretisch bestaat er wel een kans op stack-overflow als je altijd naar de public properties wijst. Maar dan moet je wel erg je best doen. Voorbeeldje:

C#:

        
private DateTime lastPaymentDate;
/// <summary>
/// Last possible Payment date for customer for this order
/// </summary>
public virtual DateTime LastPaymentDate
{
   get
   { 
      if (this.LastActionDate != null)
      {
         return LastActionDate; 
      }
      else
      {
         return lastPaymentdate;
      }
    }
    set { lastPaymentDate = value; }
}

private DateTime lastActionDate;
/// <summary>
/// Last possible date the user is allowed to change the order
/// </summary>
public virtual DateTime LastActionDate
{
   get 
   { 
       if (this.LastPaymentDate != null)
       {
           return lastPaymentDate; 
       }
       else
       {
           return lastActionDate;
       }
   }
   set 
   { 
      lastActionDate = value; }
   }
}

[roy-t]

Verwijderd schreef op maandag 21 april 2008 @ 15:17:
[...]

Das geen stack overflow, das een infinite loop (ok ok het is ook een stack overflow )

Maar deze erorr is niet inherent aan het gebruik van properties an sich vind ik zo . Hoewel het wel een geniepige fout is, als er geen debuggers bestonden zou je er snel over heen lezen helemaal als de code niet onder elkaar stond.

[Face_-_LeSS]

Vaak is het zeer afhankelijk van de situatie.

Private properties die puur als getters en setters functioneren zijn naar mijn mening redelijk zinloos. Gebruik dan gewoon direct het veld.

Wanneer er meer achter een property zit, dan komt het ook voor dat in sommige gevallen de property gebruikt moet worden en soms gewoon het veld (Denk aan events in een property die niet altijd gefired moeten worden).

Soms is een property alleen een berekening, dan moet je die wel gebruiken.

Bij mij loopt het vaak door elkaar, maar dat is helemaal niet erg zolang je maar documenteert

[Verwijderd]

Verwijderd schreef op maandag 21 april 2008 @ 15:17:
[...]


Wow.. ook voor methodes een verschillende manier van CamelCasing. Wij houden het gewoon bij HoofdLetterMethod() hoor

Nouja zeg, "wow"...zo spannend is het allemaal niet hoor.

Ik gebruik gewoon consequent de regel CamelCase voor public en camelCase voor private .

Al heb je wel gelijk wat "Microsoft conventies" betreft...visual studio maakt inderdaad standaard private methodes (event handlers bijv.) ook met een hoofdletter aan.

[ Voor 17% gewijzigd door Verwijderd op 21-04-2008 16:12 ]

[Niemand_Anders]

Verwijderd schreef op maandag 21 april 2008 @ 16:10:
[...]

Nouja zeg, "wow"...zo spannend is het allemaal niet hoor.

Ik gebruik gewoon consequent de regel CamelCase voor public en camelCase voor private .

Al heb je wel gelijk wat "Microsoft conventies" betreft...visual studio maakt inderdaad standaard private methodes (event handlers bijv.) ook met een hoofdletter aan.

De .NET coding standaard wat betreft naam geving is PascalCasing voor alles, behalve camelCasing voor variabelen en parameters. Zie ook MSDN --> .NET Framework development --> General Reference --> Design Guidelines --> Guidelines for names --> Capitalization conventions.

Hierop afwijken zorgt alleen maar voor verwarring en typo's als eigen code en MS code door elkaar wordt gebruikt. Zeker als in team verband wordt ontwikkelt.

[apokalypse]

Face_-_LeSS schreef op maandag 21 april 2008 @ 16:08:
Bij mij loopt het vaak door elkaar, maar dat is helemaal niet erg zolang je maar documenteert

Beter code dat geen commentaar nodig heeft, is meestal beter dan veel commentaar

roy-t schreef op maandag 21 april 2008 @ 14:18:
[...]

@Killemov, inderdaad Java -> methodA, C# MethodA ik stond er zelf ook van te kijken dat al die rare Javanen met een kleine letter begonnen , imho is het handig om methods met een hoofdletter te doen, variabelen beginnen immers al met een kleine letter

Ik ben erg ervaren met Java alsmede C#. Ik weet niet wat ik handiger vind. Als je je maar aan de taal conventies houd. (switchen, dat is het minst handigst).

roy-t schreef op maandag 21 april 2008 @ 14:18:
[...]

Hmm, nee, je interne gedrag blijft exact hetzelfde, immers public of private veranderd niets voor het interne gedrag, het externe gedrag veranderen (door een public te deleten of als je er maar 1 hebt die private te maken) veranderd wel en uiteidenlijk eindig je met exact dezelfde situatie, een private

Ik vind het een voordeel dat je public properties kan weggooien, zonder over het interne gedrag na te denken.

Maar nu ontopic,
Ik weet dat sommige refactor-tools (voor C#), automatisch interne code willen aanpassen voor nieuw gemaakt (public) properties. Dus wellicht is het toch een of andere guideline.

[Verwijderd]

Ja maar heb je daar camelCasing voor nodig? ik moet eerlijk zeggen dat ik aan het keyword 'public' en 'private' ook wel zie of het een public of eh.. private method is

[apokalypse]

Verwijderd schreef op maandag 21 april 2008 @ 17:00:
Ja maar heb je daar camelCasing voor nodig? ik moet eerlijk zeggen dat ik aan het keyword 'public' en 'private' ook wel zie of het een public of eh.. private method is

Handig als je deze var gebruikt in je code.

Netzoals veel C#--ers, een underscore voor een private field zetten. Erg handig. Het is geen officiële conventie, maar MS guru's doen het ook. En daar zitten aardig wat slimme gasten tussen

[Verwijderd]

Verwijderd schreef op maandag 21 april 2008 @ 17:00:
Ja maar heb je daar camelCasing voor nodig? ik moet eerlijk zeggen dat ik aan het keyword 'public' en 'private' ook wel zie of het een public of eh.. private method is

Oh, en bij een private int x of public int x kan je dat opeens niet meer zien

Het is dat je niet 2x dezelfde naam kan declareren, anders zou je verhaal niet opgaan .

[ Voor 11% gewijzigd door Verwijderd op 21-04-2008 17:05 ]

[IJsbeer]

Je hebt het niet nodig, maar handig is het wel. Zeker als je de propertie verderop in de code gebruikt, of je code later naleest. Ik zou het irritant vinden als ik eerst met mjin muis over de property moet hoveren om te zien of het de public of private is.

Als je het dus maar consequest gebruikt, maakt het niet zoveel uit. Het liefst conformeren aan de algemene MS standaard.

[H!GHGuY]

apokalypse schreef op maandag 21 april 2008 @ 13:42:
Ik vraag me het soms ook af, maar ik gebruik juist intern de privates, omdat:
[list]
• De klasse is verantwoordelijk voor zijn eigen gedrag, en mag dus overal aan zitten

Juist. Maar als je implementatie voor setter "Property" verandert dan wil je hoogstwaarschijnlijk ook dat de meeste, zoniet alle, private code zich ook aan die implementatie houdt.
Als je properties gebruikt is dit gratis.

Ik gebruik enkel de private fields rechtstreeks als ik echt doelbewust afwijk van de setter implementatie voor het desbetreffende veld. Je kan dan ook meteen uit de code afleiden dat daar echt wel iets speciaal gebeurt.

• De public properties zijn voor de buitenwereld, niet voor intern.

Helemaal niet mee eens (enquete stijl).
Properties vormen een deel van je encapsulation en verzorgen dat je object dan ook niet in een ongeldige staat kan komen. Gebruik maken van die properties geeft dus het voordeel dat er verificatie gedaan wordt op elke verandering.

• Als je een public property weghaalt, kan dit anders problemen opleveren met het interne gedrag. (niet gewenst)

Helemaal niet mee eens. Als je een public property weghaalt, dan wijzig je de interface van je object en is de kans groot dat je nog meer code moet aanpassen dan het eigen object. Bovendien wil je op zo'n moment alle code die gebruik maakt van die property eenvoudig kunnen localiseren (Dat alleen al is bij een IDE als VS een voordeel, wanneer je "find all references" doet) om het gebruik van je klasse te corrigeren met het gewijzigde gedrag.
Meer nog: als je een public property weghaalt is de kans groot dat je ook het achterliggende field weghaalt.

• Meer consistent; men kan altijd de privates gebruiken. Anders wordt het een combi van publics & privates.
[/list]

Helemaal niet mee eens: Meer consistent: Gebruik enkel de properties, anders wordt het een combi van publics en privates. gebruik enkel de privates wanneer je echt een uitzondering wil tov de property.

[mOrPhie]

Doorgaans zou ik voor het aanspreken van de Property kiezen, maar ik zou ook zeggen dat het afhangt van de situatie.

In de ctor van een class doe je de initialisatie van fields. Je zou dit heel goed direct kunnen doen, zonder het gebruik van de Property. Je weet immers precies wat je eraan hangt. Wellicht wil je dan niet eens dat de Property iets met de waarde doet. Ben je echter businesslogica aan het implementeren met input van buitenaf, dan zou het beter kunnen zijn om de Property te gebruiken, zodat eventuele business-rules die erin verwerkt zijn worden meegenomen.

Volgens mij is hier niet één antwoord op te geven dus. Het hangt helemaal af van wat je beoogt te doen. Als een property een pure read en assignment is, dan optimaliseert de compiler dat prima weg, dus dat is ook niet bepaald een reden om ergens voor te kiezen. Het zal puur een functionele zijn.

Bedenk ook waar de getter en setter properties vandaan komen. Ze zijn bedacht, omdat in het verleden (in java) "string GetXXX()" en "SetXXX(string value)" methods gemaakt werden, zodat de publieke ontsluiting van fields kon worden gecontroleerd, met bijvoorbeeld businessrules. Het was echter prima mogelijk dat je vanuit de class zelf de field zelf aansprak, in plaats van via de Get of Set methods.

[ Voor 18% gewijzigd door mOrPhie op 22-04-2008 11:22 ]

[DrDelete]

Properties in combi met private field is aan te raden indien het een typische datacontainer is. Indien je een API schrijft met properties, verwacht je over het algemeen een snelle response indien je de property(-getters) raadpleegt. Indien ik een property getter overweeg waar complexere logica in zit of een call doet naar externe componenten, met naar verhouding een lange verwerkingstijd, dan ga ik over naar functions.

In jouw voorbeeld zou ik dan verwijzen naar de private field, te meer omdat je geen complexe handling in de property getter hebt. Zodra je complexere if statements of andere componenten gaat gebruiken in de property-getter, raad ik je aan om een function "GetMaxSize()" te maken en deze aan te roepen in de "IsLargerThan" function. Dit laatste advies gaat al helemaal op indien de code in een component komt die overerfbaar is, waardoor je de GetMaxSize function virtual kunt maken!


Een goed boek waarin dit soort vraagstukken in staan is: Framework Design Guidelines, van Brad Abrams e.a.

[Verwijderd]

@DrDelete: Dank voor de uitleg!

Mijn volgende vraag was inderdaad wanneer je overstapt van Property naar Method, die vraag beantwoord je: ik heb nu Properties in mijn code die ook externe componenten aanspreken. Die kan ik dan inderdaad beter meteen veranderen naar Methods. Ik ga eens reviews bekijken van dat boek.

[apokalypse]

H!GHGuY schreef op maandag 21 april 2008 @ 22:08:
Helemaal niet mee eens. Als je een public property weghaalt, dan wijzig je de interface van je object en is de kans groot dat je nog meer code moet aanpassen dan het eigen object. Bovendien wil je op zo'n moment alle code die gebruik maakt van die property eenvoudig kunnen localiseren (Dat alleen al is bij een IDE als VS een voordeel, wanneer je "find all references" doet) om het gebruik van je klasse te corrigeren met het gewijzigde gedrag.
Meer nog: als je een public property weghaalt is de kans groot dat je ook het achterliggende field weghaalt.

mbv interface wel goed punt, maar je zorgt dus voor meer werk bij onderhoud. Nou dat is een goed ontwerp...

H!GHGuY schreef op maandag 21 april 2008 @ 22:08:
Helemaal niet mee eens: Meer consistent: Gebruik enkel de properties, anders wordt het een combi van publics en privates. gebruik enkel de privates wanneer je echt een uitzondering wil tov de property.

Dat is niet meer consistent, maar ook consistent. En het is meer werk en dus meer onderhoud. Kortom, zelfde resultaat, meer nadelen.

Overdreven veel properties maken, zodat je er intern mee kan werken ipv gewoon het field te gebruiken, is naar mijn mening totaal niet de bedoeling van properties.

[Woy]

Ik gebruik ook altijd de properties, behalve als ik bewust de logica die in die properties zit wil omzeilen.

Dit omdat je meestal als je vanuit je code een property wijzigt dat het hetzelfde gedrag vertoont als dat je het van buitenaf veranderd ( Bijvoorbeeld iets van een OnChanged event firen ). Als je daarvoor het private field in plaats van de Property gebruikt moet je die code dupliceren, en dat is IMHO niet echt mooi.

Als ik bewust van die richtlijn afwijk omdat ik wil dat er ander gedrag optreed zal ik het private field gebruiken en zet ik in commentaar erbij waarom er ander gedrag verwacht word.

Hierboven word ook aangehaald dat een property verwijderd kan worden, echter lijkt het mij dan ook dat je juist wilt weten welke code afhankelijk is van die code. Eventueel kan je er dan altijd nog voor kiezen om de access modifier van de property alleen te wijzigen.

[H!GHGuY]

apokalypse schreef op dinsdag 22 april 2008 @ 14:43:
[...]
mbv interface wel goed punt, maar je zorgt dus voor meer werk bij onderhoud. Nou dat is een goed ontwerp...

Of er meer werk moet verricht worden valt te betwijfelen, maar zelfs al is het zo, dan nog zal dit niet het meest significante werk zijn. Bovendien denk ik dat in zo'n geval het verplicht worden van de compiler errors op te lossen de developer ook verplicht om elk stuk dependant code te bekijken en herevalueren op correctheid.

Het "extra werk" (als dit er al is) rendeert volgens mij dan ook op dezelfde manier.

Dit is bvb ook een van de redenen waarom ik voorstander ben van het veranderen van namen wanneer de semantiek van een klasse/functie/field verandert: je bent verplicht om dan elk gebruik te evalueren op correctheid.

[...]
Dat is niet meer consistent, maar ook consistent. En het is meer werk en dus meer onderhoud. Kortom, zelfde resultaat, meer nadelen.

Overdreven veel properties maken, zodat je er intern mee kan werken ipv gewoon het field te gebruiken, is naar mijn mening totaal niet de bedoeling van properties.

Even consistent... OK Ik doelde misschien meer op "duidelijker in code waar een uitzondering zit, nl wanneer je toch het field rechtstreeks aanspreekt om de logica te omzeilen." zoals ondertussen rwb ook zegt.

Het is ook niet de bedoeling om properties te maken voor elke field enkel en alleen voor de vorm.
Je doet dit om:
- dat het field exposed(public) moet worden naar externe klassen
- dat er logica aan de get/set methodes vasthangt (bvb een event of bounds checking ...)
- ...

Ik hoop dat je volgend argument niet is dat dit meer werk geeft wanneer je de aan een field een nieuwe property koppelt, want in de meeste gevallen doe je dat dan met een van de redenen hierboven opgesomd zodat je ook in jouw geval (meestal fields, tenzij logica uit property nodig) elk gebruik moet evalueren of je de property al dan niet wil gebruiken.
Als dit tijdens initiele development gebeurt moet je je in deze situatie bovendien afvragen of je design wel voldoet, aangezien een interface aanpassing nodig was.

[Verwijderd]

mOrPhie schreef op dinsdag 22 april 2008 @ 11:16:
Bedenk ook waar de getter en setter properties vandaan komen. Ze zijn bedacht, omdat in het verleden (in java) "string GetXXX()" en "SetXXX(string value)" methods gemaakt werden, zodat de publieke ontsluiting van fields kon worden gecontroleerd, met bijvoorbeeld businessrules.

Borland Delphi 1 (uit de 16-bits DOS/Windows 3.11 tijd) had al getters en setters, alleen heten ze daar (nog steeds) read en write.

Delphi:

property XXX: string read GetXXX write SetXXX;

Getters/setters zijn niet gekomen omdat Java 't eerst verkeerd deed, maar omdat 't gewoon hoort in een goede OO implementatie van een framework.

Overigens spreek ik binnen een instance de private fields uitsluitend aan wanneer 't nodig is om de business logic van vooral setters te omzeilen. De overhead van property -> field is meestal verwaarloosbaar, en wanneer je weet hoe je class inelkaar zit, weet je ook wanneer je de setter aan moet spreken en wanneer niet (bij het instantieren van een property bv.).

[Zyphrax]

Zelf hanteer ik dit:

Fields:
In de klasse zelf gewoon fields gebruiken. Tenzij een property praktischer is. In een ASPX pagina kan het bijvoorbeeld handig zijn om voor waarden de Sessie/ViewState te raadplegen. Telkens een property gebruiken vanuit de klasse zelf kan overdone zijn. Je hoeft bijv. lang niet bij iedere actie te controleren of de waarde NULL is of andere validaties die je externe klasses op wilt leggen.

Notatie met een underscore ervoor, camelCase.
Voorbeeld:

code:

private int _deathCount;

Properties:
Raadpleeg nooit van buitenaf direct je fields. Je verliest hiermee de mogelijkheid om validaties/informatie verrijking toe te passen op de waarden die geset/geget worden. Plus het geeft je gemakkelijk de mogelijkheid om te bepalen welke klassen toegang hebben tot de waarden. Zoals DrDelete al aangeeft properties moeten vrij snel/vrij simpel een resultaat aan kunnen bieden, anders is het gebruik van een methode aan te raden.

Notatie in PascalCase.
Voorbeeld:

code:

public int DeathCount {
   get { return _deathCount; }
   internal set { _deathCount = value; }
}

Mocht je eens je code willen laten beoordelen adhv een vaste set regels, dan kan je FxCop downloaden. Deze geeft advies in hoe je je code kunt verbeteren en best practices toepast. Sommige regels zijn wat overdreven (o.a. overal Cultures aan meegegeven en gezeur over het gebruik van generic Lists) de laatste versie is alweer een beetje gedateerd geloof ik, maar het kan een eye-opener zijn.

FXCop download pagina @ Microsoft

[ Voor 11% gewijzigd door Zyphrax op 22-04-2008 21:20 ]

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 98% gewijzigd door Ruudjah op 01-12-2009 23:00 ]

[Verwijderd]

Ruudjah schreef op dinsdag 22 april 2008 @ 23:53:
Leuk, maar wat is hiervan het voordeel? De compiler maakt er onder water net zo hard twee functions van (als je een getter en een setter definieert), dus ik zie het voordeel niet zo? Het nadeel is dat je de voordelen van een property overboord gooit.

Ik kan me voorstellen dat je op een gegeven moment een methode gaat gebruiken omdat het gebruiken van een property qua performance nog wel eens een hoop gevolgen kan hebben. Voor een simpele get/set van een field scheelt 't natuurlijk 3x niks, maar als er een flinke bewerking in je property zit kan 't veel uitmaken (vooral als je in loops terecht komt enzo ). Een methode is wat dat betreft duidelijker, zie je gelijk dat je met een call te maken hebt.

Je hebt echter ook weer gelijk dat je dan de voordelen van de property constructie weggooid. Zelf maak ik gewoon altijd een afweging, en 9 van de 10 keer kom ik toch echt uit op een property (met al dan niet public/private modifiers).

[Verwijderd]

Ruudjah schreef op dinsdag 22 april 2008 @ 23:53:
Fields public maken is niet slim, en wel hierom:

Leuk en handig relaas, maar in dit topic heeft nog niemand het idee geopperd om fields public te maken. En dat dat bad practice is weten de meesten ook wel, zelfs zonder de MS best practices handleiding erbij te moeten pakken...

[curry684]

Verwijderd schreef op maandag 21 april 2008 @ 13:28:
Wat is gebruikelijk? Binnen je class verwijzen naar de private property of verwijzen naar de public property?

Hier is geen best practice voor. Een class is zelf 1 geheel en daarmee 100% vrij in of hij intern besluit de variabele te raken of de potentiele side-effects van de property voor lief neemt. Iemand die de code wijzigt dient zich ten allen tijde bewust te zijn van de effecten die dit binnen de class heeft. Dat heet het black box concept: properties zijn juist bedoeld om internals af te schermen, wat internals verder doen is puur een praktische vraag.

De meeste 'voordelen' van het intern benaderen van properties die in dit topic genoemd worden zijn volstrekt onzinnig als je het black box concept correct meeneemt, en gaat voorbij aan de potentiele nadelen die eraan zitten - denk hierbij aan value checks die exceptions gooien terwijl je intern nu net wel die 'van buitenaf illegale waarde' erin wil zetten of zelf endless recursions indien side-effects van een setter of getter een interne functie aanroepen die weer de eigen property aanpast:

C#:

public int SomeValue
{
  set 
  {
    this.SetCheckedValue(value);
  }
}

private void SetCheckedValue(int value)
{
  if(value > 50)
    value = 50;
  this.SomeValue = value;   // oops kaboom stack overflow
}

All in all is het benaderen van een property een bewuste keuze van de class developer (die kiest per geval of ie side effects nodig heeft of direct de waarde moet wijzigen) of een onbewuste keuze van de implementor (die alleen toegang heeft tot de public property en dus correct met een black box handelt). In het ruime merendeel van de gevallen zal de class developer uit de oogpunten van performance en controle dienen te kiezen voor de variabele direct benaderen.

[ Voor 4% gewijzigd door curry684 op 23-04-2008 00:31 ]

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 148% gewijzigd door Ruudjah op 01-12-2009 23:00 ]

[Verwijderd]

curry684 schreef op woensdag 23 april 2008 @ 00:28:
De meeste 'voordelen' van het intern benaderen van properties die in dit topic genoemd worden zijn volstrekt onzinnig als je het black box concept correct meeneemt, en gaat voorbij aan de potentiele nadelen die eraan zitten

'volstrekt onzinnig' als qualificatie is m.i. volstrekt onzinnig, of op z'n minst discutabel.
Voor de meeste handelingen vanuit een black box is 't goed om jezelf ook als een black box te benaderen. Alleen wanneer je zeker weet dat je van de spelregels van je eigen black box af wil wijken heb je een reden om direct in de ingewanden van die black box te roeren.
Kan zijn dat jij denkt dat je vaker dat recht heb dan ik, maar 'onzinnig' is relatief...

[curry684]

H!GHGuY schreef op maandag 21 april 2008 @ 22:08:
[...]

Helemaal niet mee eens (enquete stijl).
Properties vormen een deel van je encapsulation en verzorgen dat je object dan ook niet in een ongeldige staat kan komen. Gebruik maken van die properties geeft dus het voordeel dat er verificatie gedaan wordt op elke verandering.

Dit is pertinente onzin trouwens. De staat van een object dient geldig te zijn voor en na een modificatie of method call op het object. Tijdens de operatie mag het object, thread-safety even buiten beschouwing, zich in iedere staat bevinden die hem goed dunkt. Het is dus onzin om in een private method strak af te dwingen dat het object in een valide staat dient te zijn omdat dit pas relevant wordt bij het verlaten van de functie. Ter voorbeeld een class Rectangle (getters verwijderd voor helderheid):

C#:

public class Rectangle {
private int left, top, right, bottom;

public int Left { set { left = (value > right ? right : value); } };
public int Top { set { top = (value > bottom ? bottom : value); } };
public int Right { set { right = (value < left ? left : value); } };
public int Bottom { set { bottom = (value < top ? top : value); } };

public void Set(Point tl, Point br)
{
  Left = tl.x;
  Top = tl.y;
  Bottom = br.y;
  Right = br.x;
}
}

Je hoeft geen Einstein te zijn om te bedenken dat deze constructie wild onvoorspelbare bugs kan opleveren afhankelijk van wat je aan Set meegeeft en de huidige waardes zijn.

[curry684]

Verwijderd schreef op woensdag 23 april 2008 @ 00:42:
[...]
Voor de meeste handelingen vanuit een black box is 't goed om jezelf ook als een black box te benaderen. Alleen wanneer je zeker weet dat je van de spelregels van je eigen black box af wil wijken heb je een reden om direct in de ingewanden van die black box te roeren.

De black box maakt zijn eigen spelregels en heeft per definitie volledige toegang tot zijn eigen ingewanden. Dit is de hele gedachte achter het gangbare public/protected/private model dat de meeste OOP-omgevingen implementeren: dat een class ongelimiteerde toegang tot zijn eigen properties heeft omdat hij dat behoeft.

Als je een class moet beschermen tegen z'n eigen internals is het zaak die internals af te splitsen naar een losse class waar je van inherit zodat je niet bij z'n private onderdelen kunt al zou je willen, dat is stukken beter en zuiverder dan je krampachtig ervan weerhouden om in een method of property de internals waar je 'by definition' het volste recht toe hebt om ze te wijzigen te gebruiken.

[Vaudtje]

Licht off topic, maar:

Verwijderd schreef op maandag 21 april 2008 @ 14:41:
[...]
private = alleen aan te roepen door het object zelf.

In Java is private class scope, niet object scope.
Zo kun je bijvoorbeeld ook in een static context (hier de main(...)) nog bij je eigen private members.
Hiermee blijft het black box-principe behouden, want je kunt nog steeds alleen met een black box bij je privates.

Java:

public class PrivateDemo {
    private String txt = "foo!";
    public static void main(String[] args) {
        PrivateDemo a = new PrivateDemo();
        a.txt = "bar!";
        System.out.println(a.txt);//bar!
    }
}

[farlane]

Zoals altijd is hier geen altijd van toepassing, soms kun je niet anders dan het field gebruiken binnen de class omdat het bv alleen een getter heeft.

Nog mooier zelfs kwam ik laatst achter. Dit werkt ook!

code:

public int MaxSize { get; private set; }

Ik zie niet wat hier nou zo mooi aan is eerlijk gezegd. Eerst zegt je code dat er een public property is en daarna zegt het oh nee alleen de get is public, de set niet.

Ergens bekruipt me het gevoel dat C# last gaat krijgen van wat naar mijn idee een feature creep aan het worden is.

[Verwijderd]

farlane schreef op woensdag 23 april 2008 @ 16:35:
Zoals altijd is hier geen altijd van toepassing, soms kun je niet anders dan het field gebruiken binnen de class omdat het bv alleen een getter heeft.


[...]


Ik zie niet wat hier nou zo mooi aan is eerlijk gezegd. Eerst zegt je code dat er een public property is en daarna zegt het oh nee alleen de get is public, de set niet.

Ergens bekruipt me het gevoel dat C# last gaat krijgen van wat naar mijn idee een feature creep aan het worden is.

Wat is precies het verschil met
public Bla { get { return bla; } }


Daar zeg je ook: hey, ik heb een publiek iets...maar je mag het alleen lezen.
Komt toch op hetzelfde neer ?

[bigbeng]

Een private setter mag door de class zelf wel gebruikt worden. Dat is conceptueel wel iets anders dan er is geen setter.

[whoami]

farlane schreef op woensdag 23 april 2008 @ 16:35:
Zoals altijd is hier geen altijd van toepassing, soms kun je niet anders dan het field gebruiken binnen de class omdat het bv alleen een getter heeft.


[...]


Ik zie niet wat hier nou zo mooi aan is eerlijk gezegd. Eerst zegt je code dat er een public property is en daarna zegt het oh nee alleen de get is public, de set niet.

Het mooie eraan, is dat je niet meer dit hoeft te typen:

code:

private int _myInteger;

public int MyInteger
{
     get
     {
          return _myInteger;
     }
}

Die automatic properties zorgen er dus voor dat je een hoop minder tikwerk hebt als je properties gewoon niets anders doen dan een variable setten of returnen. Eens er meer logica achter komt te zitten, kan je die auto-properties natuurlijk niet meer gebruiken.

Dat je die 'private set' bij een auto property er nog moet bijtypen, is natuurlijk nodig omdat je anders die property (achterliggende variable) binnen je class natuurlijk nooit kunt assignen.

[Verwijderd]

whoami schreef op woensdag 23 april 2008 @ 16:44:
[...]

Het mooie eraan, is dat je niet meer dit hoeft te typen:

code:

private int _myInteger;

public int MyInteger
{
     get
     {
          return _myInteger;
     }
}

Die automatic properties zorgen er dus voor dat je een hoop minder tikwerk hebt als je properties gewoon niets anders doen dan een variable setten of returnen. Eens er meer logica achter komt te zitten, kan je die auto-properties natuurlijk niet meer gebruiken.

Dat je die 'private set' bij een auto property er nog moet bijtypen, is natuurlijk nodig omdat je anders die property (achterliggende variable) binnen je class natuurlijk nooit kunt assignen.

Precies. Alhoewel ik het wel met farlane eens ben is dat ze bij C# op moeten passen dat ze niet té veel 'hippe' language constructs moeten gaan verzinnen, omdat dan op een gegeven moment de taal steeds moeilijker te lezen wordt (omdat je veel verschillende abstracte manieren hebt om een bepaalde situatie te verkrijgen).

In principe moet dit ook kunnen (niet getest, dus pin me er niet op vast )

code:

int MaxSize { public get; private set; }

Nevermind... Werkt niet. Persoonlijk zou ik een dergelijke manier niet lelijk vinden, omdat 't wat explicieter laat zien wat de bedoeling is van je get en set. Kan natuurlijk niet omdat als je de property geen access modifier meegeeft hij per definitie al niet meer public is. Dan mag je dat niet meer overrulen.

[ Voor 11% gewijzigd door Verwijderd op 23-04-2008 17:55 ]

[farlane]

Verwijderd schreef op woensdag 23 april 2008 @ 16:37:
[...]

Wat is precies het verschil met
public Bla { get { return bla; } }


Daar zeg je ook: hey, ik heb een publiek iets...maar je mag het alleen lezen.
Komt toch op hetzelfde neer ?

Nee, dat is iets anders

whoami schreef op woensdag 23 april 2008 @ 16:44:
[...]

Het mooie eraan, is dat je niet meer dit hoeft te typen:

Dat je die 'private set' bij een auto property er nog moet bijtypen, is natuurlijk nodig omdat je anders die property (achterliggende variable) binnen je class natuurlijk nooit kunt assignen.

Ik snap waarom ze het gedaan hebben, ik snap niet de manier waarop ze het gedaan hebben. Waarom nog die public aan de 'buitenkant' van de property als je bij de setter expliciet vermeldt dat hij private is? Waarom dan niet zoals Tedkees schrijft:

code:

int MaxSize { public get; private set; }

Dan spreekt de code zichzelf in ieder geval niet tegen.


_{Ik schaar deze onder dezelfde noemer als de switch/break .}

[whoami]

Hmm, mja, waarom, geen idee. Compiler-technisch misschien ? Die verwacht een modifier aan het begin van de declaratie, en als die er niet is, wordt de default modifier gebruikt (private in dit geval) ?
In .NET 2.0 kon je ook al dit doen:

code:

public int MaxSize
{
    get
    {
        return _maxSize;
    }
    private set
    {
         _maxSize = value;
    }
}

Dus, ze breiden daar ook gewoon op voort.

Ik schaar deze onder dezelfde noemer als de switch/break .

Wat is er mis met switch / break ?

[ Voor 11% gewijzigd door whoami op 23-04-2008 21:32 ]

[H!GHGuY]

curry684 schreef op woensdag 23 april 2008 @ 00:43:
[...]

Dit is pertinente onzin trouwens. De staat van een object dient geldig te zijn voor en na een modificatie of method call op het object. Tijdens de operatie mag het object, thread-safety even buiten beschouwing, zich in iedere staat bevinden die hem goed dunkt. Het is dus onzin om in een private method strak af te dwingen dat het object in een valide staat dient te zijn omdat dit pas relevant wordt bij het verlaten van de functie.

OK, kan ik je in volgen.

Ter voorbeeld een class Rectangle (getters verwijderd voor helderheid):

C#:

public class Rectangle {
private int left, top, right, bottom;

public int Left { set { left = (value > right ? right : value); } };
public int Top { set { top = (value > bottom ? bottom : value); } };
public int Right { set { right = (value < left ? left : value); } };
public int Bottom { set { bottom = (value < top ? top : value); } };

public void Set(Point tl, Point br)
{
  Left = tl.x;
  Top = tl.y;
  Bottom = br.y;
  Right = br.x;
}
}

Je hoeft geen Einstein te zijn om te bedenken dat deze constructie wild onvoorspelbare bugs kan opleveren afhankelijk van wat je aan Set meegeeft en de huidige waardes zijn.

Behalve dat de Set methode niet echt doet wat je er van verlangt, is en blijft je Rectangle een geldige staat behouden aangezien je nooit left > right of bottom > top krijgt.

Naast het feit dat je hier normaal een width en een height gebruikt (maar dat wat je zelf ook maar al te best) is dit net een situatie waar ik een uitzondering zou maken en toch de fields gebruiken met de nodige validatie op de parameters.
De reden is natuurlijk duidelijk: je verandert niet alleen Left maar ook Right, dus is de controle die in Left en Right gedaan wordt nogal onzinnig aangezien ze tov de huidige staat checken. Dus is het hier logisch dat je de logica in de properties "corrigeert".

C#:

public class Rectangle {
private int left, top, right, bottom;

public int Left { set { left = (value > right ? right : value); } };
public int Top { set { top = (value > bottom ? bottom : value); } };
public int Right { set { right = (value < left ? left : value); } };
public int Bottom { set { bottom = (value < top ? top : value); } };

public void Set(Point tl, Point br)
{
  if (tl.x > br.x || tl.y > br.y)
    throw new ArgumentException("Points do not describe a valid rectangle.");

  left = tl.x;
  right = br.x;
  top = tl.y;
  bottom = br.y;
}
}

Wie deze code leest weet meteen dat de checks hier omzeild worden en ziet ook meteen waarom.

Maar dan wel:

C#:

public int Area
{
  get
  {
     return Height * Width;
  }
}
public int Height
{
  get
  {
     return Top - Bottom;
  }
}
public int Width
{
  get
  {
     return Right - Left;
  }
}
public void ResizeToBoundingSquare()
{
   if (Height > Width)
      Right = Left + Height;
   else
      Top = Bottom + Width;
}

[ Voor 6% gewijzigd door H!GHGuY op 23-04-2008 22:10 ]

[roy-t]

Ruudjah schreef op woensdag 23 april 2008 @ 00:31:
[...]

Ik zou zweren dat ik heb gelezen dat twee mensen voor data-only properties public fields aanraden. Kan het alleen nergens meer teruglezen
Overigens kom ik het nog (veel te) vaak tegen, public fields. Laatst ook weer, ik moest developers zelfs ervan overtuigen dat het bad practice is.

Ik heb het idd 1x aangeraden. Imho:

C#:

public Object o { get { return o; } set { o = value; } }

Is toch voor de compiler / in de code / in Visual Studio exact het zelfde gedrag als:

C#:

public Object o

Ik wilde aangeven dat je niet moet overdrijven met fields, als het echt zo simpel is dat er een 'naakte' getter en setter is EN er waarschijnlijk nooit een andere manier nodig zal zijn is een gewoon public field helemaal niet verkeerd.

verder gebruik ik natuurlijk vaak getters, setters en properties, maar je moet dat soort dingen niet over-usen

[whoami]

roy-t schreef op woensdag 23 april 2008 @ 22:16:
[...]


Ik heb het idd 1x aangeraden. Imho:

C#:

public Object o { get { return o; } set { o = value; } }

Is toch voor de compiler / in de code / in Visual Studio exact het zelfde gedrag als:

C#:

public Object o

Niet als het op databinding aankomt...

[curry684]

H!GHGuY schreef op woensdag 23 april 2008 @ 22:05:
Behalve dat de Set methode niet echt doet wat je er van verlangt, is en blijft je Rectangle een geldige staat behouden aangezien je nooit left > right of bottom > top krijgt.

Die Set methode doet exact wat je verlangt: de Rectangle vullen uit 2 points die topleft en bottomright beschrijven. Een heel valide method die iets heel logisch doet. Maar toch gaat ie hiermee wel op z'n muil:

C#:

Rectangle rect = new Rectangle;
rect.Set(50, 50, 100, 100);
rect.Set(150, 150, 250, 250);

Na deze code zal de rectangle (100, 100, 250, 250) bevatten als data, en dat is natuurlijk een afschuwelijke bug Of de implementatie top is is een tweede, feit is dat dit een bug is door verkeerde validaties binnen de black box doordat de functie Set niet accepteert dat hij de macht moet nemen. Een schoolvoorbeeld dus van 'moet op de variabelen zelf werken'.

[roy-t]

whoami schreef op woensdag 23 april 2008 @ 22:35:
[...]
Niet als het op databinding aankomt...

??


Ik heb even gegoogled maar over C# databinding kom ik eigenlijk alleen websites over SQLDatabases binden aan objecten tegen, wat bedoel je in deze context precies met databinding en hoe heeft een property daar invloed op het gedrag?

[whoami]

Moet je dit eens uittesten:

C#:

public class User
{
    public string UserName;

    public User( string userName )
    {
        this.UserName = userName;
    }
}

public class UserWithProperties
{
    public string UserName
    {
        get;
        set;
    }

    public UserWithProperties( string userName )
    {
        UserName = userName;
    }
}

C#:

private void button1_Click( object sender, EventArgs e )
{
        List<User> list1 = new List<User> ();
        list1.Add (new User ("whoami"));
        list1.Add (new User ("roy-t"));

        List<UserWithProperties> list2 = new List<UserWithProperties> ();
        list2.Add (new UserWithProperties ("whoami"));
        list2.Add (new UserWithProperties ("roy-t"));

        dataGridView1.DataSource = list1;
        dataGridView2.DataSource = list2;
}

[ Voor 4% gewijzigd door whoami op 24-04-2008 09:51 ]

[roy-t]

whoami schreef op donderdag 24 april 2008 @ 09:50:
Moet je dit eens uittesten:

C#:

public class User
{
    public string UserName;

    public User( string userName )
    {
        this.UserName = userName;
    }
}

public class UserWithProperties
{
    public string UserName
    {
        get;
        set;
    }

    public UserWithProperties( string userName )
    {
        UserName = userName;
    }
}

C#:

private void button1_Click( object sender, EventArgs e )
{
        List<User> list1 = new List<User> ();
        list1.Add (new User ("whoami"));
        list1.Add (new User ("roy-t"));

        List<UserWithProperties> list2 = new List<UserWithProperties> ();
        list2.Add (new UserWithProperties ("whoami"));
        list2.Add (new UserWithProperties ("roy-t"));

        dataGridView1.DataSource = list1;
        dataGridView2.DataSource = list2;
}

(get en set even ingevuld met "get{return lala;} set{lala=value;}" maargoed dat bedoelde je natuurlijk)

En ik krijg inderdaad ander gedrag, een hele dikke stackoverflow bij het gebruik van properties

Waarom weet ik eigenlijk niet precies, hoe behandelt een DataGridView die list? dat hij zo vaak via de list de waarden leest (recursief zelfs?) en dat er dan een stack overflow ontstaat. Wat ontzettend vreemd..

Wel handig info Whoami!

Ik heb btw nooit eerder een List<> gebruikt als data voor een DataGridView, is het normaal dat als ik alleen de code voor de normale (propertyloze) code uitvoer de dataGridView gewoon leeg blijft? Ondanks DataGridView1.DataSource = List1?

[ Voor 7% gewijzigd door roy-t op 24-04-2008 11:22 ]

[H!GHGuY]

curry684 schreef op donderdag 24 april 2008 @ 00:46:
[...]

Die Set methode doet exact wat je verlangt: de Rectangle vullen uit 2 points die topleft en bottomright beschrijven. Een heel valide method die iets heel logisch doet. Maar toch gaat ie hiermee wel op z'n muil:

C#:

Rectangle rect = new Rectangle;
rect.Set(50, 50, 100, 100);
rect.Set(150, 150, 250, 250);

Na deze code zal de rectangle (100, 100, 250, 250) bevatten als data, en dat is natuurlijk een afschuwelijke bug Of de implementatie top is is een tweede, feit is dat dit een bug is door verkeerde validaties binnen de black box doordat de functie Set niet accepteert dat hij de macht moet nemen. Een schoolvoorbeeld dus van 'moet op de variabelen zelf werken'.

Maw: de set doet niet wat je verwacht.
Je verwacht een rectangle te hebben met 150,150-250,250, maar krijgt een rectangle met 100,100 -> 250,250. Dat is wat ik bedoelde, dat is wat jij bedoelde. Maar zoals ik aangaf: die code zou ikzelf ook met de fields hebben geschreven omdat het daar overduidelijk is dat je de logica van de properties omzeilt.

Daarom ook dat ik een tegenvoorbeeldje gaf.

[Woy]

roy-t schreef op donderdag 24 april 2008 @ 11:20:
[...]


(get en set even ingevuld met "get{return lala;} set{lala=value;}" maargoed dat bedoelde je natuurlijk)

En ik krijg inderdaad ander gedrag, een hele dikke stackoverflow bij het gebruik van properties

Waarom weet ik eigenlijk niet precies, hoe behandelt een DataGridView die list? dat hij zo vaak via de list de waarden leest (recursief zelfs?) en dat er dan een stack overflow ontstaat. Wat ontzettend vreemd..

Wel handig info Whoami!

Ik heb btw nooit eerder een List<> gebruikt als data voor een DataGridView, is het normaal dat als ik alleen de code voor de normale (propertyloze) code uitvoer de dataGridView gewoon leeg blijft? Ondanks DataGridView1.DataSource = List1?

Als je een DataGridView bind aan een IEnumerable zal hij alle properties van je Object als collumns genereren ( AutoGenerateColumns ).

Dat je een stackoverflow krijgt is denk een foutje in je implementatie van je properties ( In je setter of getter weer de property aangeroepen in plaats van het field? ).

De fields worden niet gebind en de properties wel. Dat is wat whoami wil zeggen.

[whoami]

Hmm, die automatic properties blijken niet te werken op structs ....

code:

public struct StructA
{
     public int Bliep
     {
          get;
          private set;
     }

     public StructA( int bliep )
     {
         this.Bliep = bliep;
     }
}

Resulteert in een

Backing field for automatically implemented property must be fully assigned before controls is returned to the caller. Consider calling the default constructor from a constructor initializer

Yeahyeah, default constructors in structs is een no-go.

wtf.

dan maar weer op de 'old fashioned' way verder...

Edit:

huh, expliciet een default constructor toevoegen aan een struct gaat dus idd niet:

code:

public struct StructA
{
     public StructA() {}
}

levert dus een compiler-error op.

Echter, ik kan in m'n constructor wel de 'default constructor' expliciet gaan aanroepen, ik mag 'm gewoon niet zelf definieren.

Dit lost het probleem dus op:

code:

struct StructA
{
     public int A { get; set; }
   
     public StructA( a ) : this()
     {
         A = a;
     }
}

[ Voor 32% gewijzigd door whoami op 04-05-2008 12:41 ]

[farlane]

Lijkt me dat je voor de duidelijkheid dan maar geen auto-properties in structs moet gebruiken. Anyways, waren structs niet eigenlijk als POD's bedoeld?

[Verwijderd]

roy-t schreef op woensdag 23 april 2008 @ 22:16:
[...]
Ik heb het idd 1x aangeraden. Imho:

C#:

public Object o { get { return o; } set { o = value; } }

Is toch voor de compiler / in de code / in Visual Studio exact het zelfde gedrag als:

C#:

public Object o

Whoami heeft een punt dat binding op properties werkt, maar dit is niet de hoofdreden om fields niet public te maken.

De hoofdreden is dat je interface naar de buitenwereld (de API) van een public field anders is bij een property, ze zijn binary incompatible.

Als ik tegen een dll van jou praat met public fields en jij verandert enkele public fields in properties, omdat er extra logica nodig is, dan ben ik verplicht om mijn code opnieuw te compilen, ondanks dat ik geen regel code hoef aan te passen.

[whoami]

farlane schreef op zondag 04 mei 2008 @ 14:16:
Lijkt me dat je voor de duidelijkheid dan maar geen auto-properties in structs moet gebruiken. Anyways, waren structs niet eigenlijk als POD's bedoeld?

forgive my ignorance maar POD ?

Edit:
ok: plain old data.
Tja, ik heb een struct nodig om een 'value type' te implementeren. Idd, gewoon plain old data, maar dat neemt niet weg dat ik een constructor nodig heb. (Ik wil een immutable value type, maar ik wil 'm wel een waarde geven bij het instantieren. Cfr een DateTime in .NET).

Verder snap ik niet wat je bedoeld met 'waren structs niet bedoeld als POD's. Ik bedoel, .... wat dan ? Mag een struct dan geen ctor hebben van jou ?

[ Voor 43% gewijzigd door whoami op 04-05-2008 14:49 ]