[C#] Vraag over Properties

[Davio]

Ik heb een vraag over properties, wat is precies het verschil tussen de volgende 2:

Manier 1

C#:

public class Foo
{
    public string Naam;
}

Manier 2

C#:

public class Foo
{
    public string Naam { get; set; }
}

Via manier 1 kan ik met een object van mijn fooklasse ook zeggen: foo.Naam = "bla", niet alleen via manier 2 dus.

Of compileert het gewoon hetzelfde?

[RobIII]

1 is een public field (of variabele als je wil), 2 is een public property.
Voordeel van een property is dat je er nog wat code in kwijt kunt; zo kun je in de setter controleren of iets een geldige waarde is of een propertychanged event raisen oid en in de getter kun je bijvoorbeeld een default value returnen als de property niet geset zou zijn oid.
Daarbij kun je voor een public property bijvoorbeeld de setter private maken, dat gaat je met een public field niet lukken.

Davio schreef op vrijdag 22 oktober 2010 @ 10:42:
Of compileert het gewoon hetzelfde?

Euh, doe eens gek en bekijk de gecompileerde code eens

En waarom kan ik op Google in 2 seconden het(zelfde) antwoord vinden en jij niet?

[ Voor 72% gewijzigd door RobIII op 22-10-2010 10:48 ]

[Snake]

Een property is syntax sugar voor een getter en setter method:

C#:

public class Foo
{
    public string Naam { get; set; }
}

Wordt

C#:

public class Foo
{
    private string _naam; // deze naam wordt dus gegenereerd.
    public string get_Naam 
    {
        return this._naam;
    }

    public void set_Naam(string naam)
    {
        this._naam = naam;
    }
}

Zoals RobIII zei: bij een property kan je controlleren wat je input is, en eventueel events raisen. Dit is belangrijk bij bindings in WPF. Daarbij moet je ook je databound fields als properties exposen aan je view.

---

Bij een property kan je ook appart de getter en setter instellen.
For example:

C#:

public class Foo 
{
    public string Naam { get; private set; } // Naam kan alleen geset worden door een instantie van Foo.
}

Edit:
Blijkt dus dat er effectief in IL een .property keyword bestaat (wat is de correcte term?)

C#:

.class public auto ansi beforefieldinit Foo
    extends [mscorlib]System.Object
{
    .method public hidebysig specialname rtspecialname instance void .ctor() cil managed
    {
        .maxstack 8
        L_0000: ldarg.0 
        L_0001: call instance void [mscorlib]System.Object::.ctor()
        L_0006: ret 
    }


    .property instance string Naam
    {
        .get instance string ConsoleApplication4.Foo::get_Naam()
        .set instance void ConsoleApplication4.Foo::set_Naam(string)
    }


    .field private string <Naam>k__BackingField
    {
        .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()
    }

}

Bij de properties zie je dan de 2 functies:

C#:

.method public hidebysig specialname instance void set_Naam(string 'value') cil managed
{
    .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()
    .maxstack 8
    L_0000: ldarg.0 
    L_0001: ldarg.1 
    L_0002: stfld string ConsoleApplication4.Foo::<Naam>k__BackingField
    L_0007: ret 
}
.method public hidebysig specialname instance string get_Naam() cil managed
{
    .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()
    .maxstack 1
    .locals init (
        [0] string str)
    L_0000: ldarg.0 
    L_0001: ldfld string ConsoleApplication4.Foo::<Naam>k__BackingField
    L_0006: stloc.0 
    L_0007: br.s L_0009
    L_0009: ldloc.0 
    L_000a: ret 
}

 

 

 

 

[ Voor 64% gewijzigd door Snake op 22-10-2010 10:56 ]

[Davio]

Bedankt voor de antwoorden.

Ik gebruik properties eigenlijk bijna alleen als ik een speciale get of set nodig heb.

Bijvoorbeeld met Textboxes doe ik dan

C#:

public string Naam { get { return this.textBoxNaam.Text; } set { this.textBoxNaam.Text = value; }

Of als shorthand met een geselecteerde value in een datagrid

C#:

// User is door LINQ gegenereerde klasse
private User selectedUser { get { return this.dataGridUsers.SelectedValue as User; }

Ik vroeg mij echter af of het ook nodig / nuttig was als je alleen maar een simpele get en set nodig hebt zonder extra functionaliteit.

[whoami]

Wel of niet properties gebruiken heeft ook zijn implicaties op Xml Serializatie (public properties (die getter & setter hebben) worden geserialiseerd), serialisatie (fields worden geserializeerd), en ik dacht ook op databinding in asp.net.

[Haan]

Het exposen van velden door ze public te maken is bad practice, iig in Java en C#.

[.oisyn]

Haan schreef op vrijdag 22 oktober 2010 @ 11:54:
Het exposen van velden door ze public te maken is bad practice, iig in Java en C#.

Maar dan pas je een regel toe puur en alleen om de regel toe te passen. Semantisch is er, vanuit de oogpunt van de gebruiker, natuurlijk geen enkel verschil in een field en een property. De code ziet er ook exact hetzelfde uit. Het argument "dan kun je later extra code toevoegen in de getter/setter" gaat dan ook niet op, want je kunt er op dat moment net zo goed een property van maken en de boel recompilen. Goed, het verhaal wordt natuurlijk wat anders met interfaces (hoewel je daar sowieso niet voor fields kon kiezen) of class overrides (hoewel je daar sowieso expliciet ervoor moet kiezen of je ze virtual maakt), of het combineren van assemblies die je niet tegelijk compileert.

[pedorus]

.oisyn schreef op vrijdag 22 oktober 2010 @ 12:16:
Het argument "dan kun je later extra code toevoegen in de getter/setter" gaat dan ook niet op, want je kunt er op dat moment net zo goed een property van maken en de boel recompilen.

Dat is enkel nogal onhandig als je met iets als reflection of postsharp aan de gang gaat. Daarnaast is er geen enkele reden te bedenken voor een public field in een class, het geeft alleen maar onduidelijkheid naar andere programmeurs die geen public fields verwachten. Ook is het niet sneller, omdat c# met jit-compilers werkt die 'lege' properties gewoon weg kunnen optimaliseren.

[.oisyn]

Mijn post was dan ook geen betoog vóór het gebruik van fields

[ Voor 11% gewijzigd door .oisyn op 22-10-2010 14:57 ]

[barfieldmv]

Properties kan je uitbreiden in een DLL zonder dat alle gebruikende exe's hercompiled moeten worden.

Van een public field een property maken kost altijd een recompile van alle Exe's die gebruik maken van de nieuwe property.

Bij een property kan je extra code toevoegen die checks,logging of whatever uitvoerd wat niet kan bij een normaal veld.

Verder is het vooral theoretisch verhaal, zeker als je bedenkt dat een jit-compiler de verschillen weer grotendeels weg werkt.

[ Voor 28% gewijzigd door barfieldmv op 22-10-2010 17:08 ]

[HawVer]

Ik gebruik in windows forms met name properties om er extra attributes omheen te zetten. Verder biedt properties mij nog wat extra voordelen. Zoals ik kan weten wanneer een property van buiten de class wordt geset/ makelijk te bewerken met propertybrowser. Verder kies ik qua consistentie voor één oplossing. Maar buiten dit zie ik geen extra voordelen in properties vs. fields. Als je fields wilt gebruiken heb je mijn zegen. Properties zie ik met name om al die design time shizzle te ondersteunen. Je kan bijvoorbeeld properties faken met custom type descriptors.

Ik merk trouwens wel dat de meeste mensen geneigd zijn om properties te gebruiken. Public fields kom je niet zo gek veel tegen in C#.

[stoofpeer]

Meestal maak je private fields en public propperty`s. In die propperty`s roep je dan weer het field aan. Dit om aan het encapsulation gedeelte van OO te voldoen. (Ik zeg het heel kort door de bocht ik weet het)

[BlackHawkDesign]

Ik zie het echte antwoord hier nog niet duidelijk tussenstaan. Properties zijn namelijk ontstaan uit de behoefte naar information hiding (Wikipedia: Information hiding) Dus nog een toevoeging op jullie verhaal:

Vroeger had je alleen members. Soms wil je toegang tot die member in jouw class geven aan andere classes of wat dan ook. Een class heeft altijd een interface, namelijk een set met methodes en hun signatures. Door members te exposen naar andere classes, worden deze ook onderdeel van je interface.
Een member, bijv: int age, is ook onderdeel van je implementatie. Verschillende methodes werken met die member en doen er dingen mee. Als ik plots wil dat mijn age member een double wordt, om wat voor reden dan ook. Dan moet ik behalve dit in mijn eigen class aanpassen, ook aanpassen in de andere dingen die mijn member gebruiken. Soms weet je dit niet, dus kunnen dingen stuk gaan etc.

Toen is in de trend van information hiding het idee van getters en setters ontstaan. Je schrijft dan per member een getter en een setter (of alleen een getter, net wat je wilt.) Een getter/setter is gewoon een wrapper om je member heen die voor de afscheiding zorgt tussen je implementatie van je class en je interface van je class. Je ziet dit veel terug in java. Als je dus je implementatie verandert, in dit geval onze member age, dan hoef je niet persee je interface te veranderen. Je kan namelijk conversie toepassen in die wrapper methodes
Voorbeeld:

Java:

private int age;

public void setAge(int age){
 this.age = age;
}
public int getAge(){
return age;
}

Verandering in de implementatie

Java:

private double age;

public void setAge(int age){
 this.age = (double)age;
}
public int getAge(){
return double.toInt(age);
}

Aangezien je soms heel wat getters en setters moet schrijven, levert dit wel een hele boel code op en vaak zien die functies er zo uit als hierboven. Daarom heb je dus properties in c#. Properties is dus een verkorte versie van het eerste stukje code. Het scheelt dus heel veel code. Zo behoudt je dus je interface en kan je wel aan je implementatie van de class rommelen.

Dus mijn advies: Gebruik properties als je member data naar buiten wilt gebruiken en maak members zelf altijd private of protected.

[ Voor 57% gewijzigd door BlackHawkDesign op 23-10-2010 11:04 ]

[yade]

Properties kun je ook read-only maken en kun je definiëren in interfaces. Dat gaat met fields niet.

Bijv:

C#:

public Guid Id {get; private set;}

public string Name {get; set;}

public DateTime DayOfBirth {get; set;}

public int Age { 
   get 
   { 
      return (DateTime.Now - DayOfBirth).Years; 
   }
} 

(Uit mijn hoofd, dus er kunnen foutjes in zitten.)

[ Voor 75% gewijzigd door yade op 24-10-2010 00:15 ]

[Zeuter]

yade schreef op zaterdag 23 oktober 2010 @ 12:26:
Properties kun je ook read-only maken en kun je definiëren in interfaces. Dat gaat met fields niet.

Volgens mij kan je ze wel read-only maken door ze met const te declareren. Het nadeel is dat je ze dan wel meteen moet toekennen.

[Styxxy]

Een TimeSpan heeft geen TotalYears method . Leeftijd moet je zelf mooi berekenen.

http://msdn.microsoft.com/en-us/library/system.timespan.aspx

yade schreef op zaterdag 23 oktober 2010 @ 12:26:
Properties kun je ook read-only maken en kun je definiëren in interfaces. Dat gaat met fields niet.

Bijv:

C#:

public Guid Id {get; private set;}

public string Name {get; set;}

public DateTime DayOfBirth {get; set;}

public int Age { 
   get 
   { 
      return (DateTime.Now - DayOfBirth).TotalYears; 
   }
} 

(Uit mijn hoofd, dus er kunnen foutjes in zitten.)

[Snake]

Zeuter schreef op zaterdag 23 oktober 2010 @ 18:27:
[...]


Volgens mij kan je ze wel read-only maken door ze met const te declareren. Het nadeel is dat je ze dan wel meteen moet toekennen.

Readonly != constant.

Constant = @compiletime gekend. Readonly kan alleen geassigned worden in de constructor.

[Davio]

Snake schreef op zaterdag 23 oktober 2010 @ 21:47:
[...]

Readonly != constant.

Constant = @compiletime gekend. Readonly kan alleen geassigned worden in de constructor.

Dat klopt, er is een groot verschil tussen "const int x" en "readonly int x".

Const kun je trouwens alleen een constante waarde toekennen, je kan niet zeggen: const string appdir = Application.StartupPath. Dat kan alleen met readonly.

[Verwijderd]

Styxxy schreef op zaterdag 23 oktober 2010 @ 21:15:
Een TimeSpan heeft geen TotalYears method . Leeftijd moet je zelf mooi berekenen.

http://msdn.microsoft.com/en-us/library/system.timespan.aspx


[...]

offtopic:
Doe dan total days en deel dat door 365,25

[Snake]

Davio schreef op zaterdag 23 oktober 2010 @ 22:04:
[...]

Dat klopt, er is een groot verschil tussen "const int x" en "readonly int x".

Const kun je trouwens alleen een constante waarde toekennen, je kan niet zeggen: const string appdir = Application.StartupPath. Dat kan alleen met readonly.

Yea, en constants worden ook geinlined.

Als je:

C#:

const int x = 5;

public void Test()
{
    Console.WriteLine("x = {0}", x); 
}

doet, dan wordt dit:

C#:

public void Test()
{
    Console.WriteLine("x = {0}", 5); 
}

[yade]

Verwijderd schreef op zaterdag 23 oktober 2010 @ 22:11:
[...]

offtopic:
Doe dan total days en deel dat door 365,25

Of gewoon Years. TotalYears is niet nodig, omdat er geen eeuwen in zitten.

Hey! Er zitten helemaal geen years in! WTF?!

[ Voor 9% gewijzigd door yade op 24-10-2010 00:16 ]

[Feanathiel]

yade schreef op zondag 24 oktober 2010 @ 00:15:
[...]


Of gewoon Years. TotalYears is niet nodig, omdat er geen eeuwen in zitten.

Hey! Er zitten helemaal geen years in! WTF?!

Het aantal jaren is geen vast gegeven. De ene keer is dit 365 dagen en in een schrikkeljaar zijn dit er 366. Mogelijkheid is dus dat het 365, 365.25 of 366 dagen is. Het zelfde principe als dat er geen maanden in verwerkt zijn.

[.oisyn]

Daar is niets WTFs aan. Het zou een WTF zijn als ze er wel in zouden zitten. Aan een tijdspanne kun je namelijk helemaal niet zien hoeveel maanden of jaren het duurt, aangezien die geen vaste hoeveelheid kennen. 365 dagen vanaf 1 januari 2010 is in totaal 1 jaar, maar 365 dagen vanaf 1 januari 2008 is net geen jaar.

[yade]

Nee, meer omdat ik dácht dat het er wel in zat. Maar goed, daar gaat het helemaal niet om. Het ging om properties.

[HarmoniousVibe]

Haan schreef op vrijdag 22 oktober 2010 @ 11:54:
Het exposen van velden door ze public te maken is bad practice, iig in Java en C#.

Vroeger was dat inderdaad zo. Je moet je echter wel afvragen waarom dat een bad practice was/is en of die vlieger nog steeds op gaat. Alles draait hier om Information Hiding. Het verbergen van informatie ten behoeve van het verschaffen van een stabiele API.

Vroeger was inderdaad de enige manier om dit te bereiken het expliciet encapsuleren van private attributen in publieke getters en setters. Als er dan gedrag/code moest worden toegevoegd aan een getter/setter (de encapsulatielaag voor een attribuut) kon de client code onveranderd blijven. Concreet: customer.getAccountNumber() kan dan customer.getAccountNumber() blijven, ook al is heel de implementatie van de methode veranderd.

Sinds dat er properties kunnen worden gebruikt zijn getters en setters (en private attributen?) in principe niet meer nodig en leveren alleen maar onnodig veel werk op. Immers, een publiek attribuut kan zonder dat de API kapot wordt gemaakt worden vervangen door een property. Concreet: customer.accountNumber kan customer.accountNumber blijven, ook al is de implementatie van dit property veranderd. Zie properties maar als een soort van impliciete maner van encapsulatie, in contrast met de expliciete encapsulatie in getters en setters. Of een soort samenvoegsel van attributen en methoden met ingebouwde encapsulatie.

Dit gaat uiteraard alleen op als het vanaf het begin al de bedoeling was dat client code volledige toegang krijgt tot de attributen. In andere gevallen kun je natuurlijk beter al beginnen met een property die de desgewenste API afdwingt, anders ga je later de API semantisch inperken, ook al blijft deze syntactisch hetzelfde. Ook dit levert een 'broken' API op. Misschien is het dus beter om als vuistregel altijd maar met attributen te werken: zo veel extra werk is dit niet en het 'dwingt' de programmeur meteen na te denken over de 'toegangsrechten', ook al is het resultaat van dit denkwerk niet meer dan public string attr { get; set; }. Echter is dit niet strikt noodzakelijk. In dit geval.

Overigens vind ik de term 'property' wel enigszins ongelukkig gekozen, omdat een attribuut/member/field ook vaak wordt aangeduid met 'property'.

[ Voor 12% gewijzigd door HarmoniousVibe op 24-10-2010 16:18 ]

[pedorus]

yade schreef op zondag 24 oktober 2010 @ 00:15:
[...]


Of gewoon Years. TotalYears is niet nodig, omdat er geen eeuwen in zitten.

Hey! Er zitten helemaal geen years in! WTF?!

offtopic:
Ik zie net dat op stackoverflow bijna 2 jaar een stomme bug in het beste antwoord zat. How do I calculate someone's age in C#? Blijkbaar niet zo eenvoudig als het lijkt allemaal, moet je kijken hoeveel mensen met een fout antwoord komen...

LB06 schreef op zondag 24 oktober 2010 @ 16:04:
Sinds dat er properties kunnen worden gebruikt zijn getters en setters (en private attributen?) in principe niet meer nodig en leveren alleen maar onnodig veel werk op. Immers, een publiek attribuut kan zonder dat de API kapot wordt gemaakt worden vervangen door een property. Concreet: customer.accountNumber kan customer.accountNumber blijven, ook al is de implementatie van dit property veranderd.

Ik kan dit niet helemaal volgen. Java kent geen properties, c# dat later kwam kent ze al sinds het begin (later ook met auto-implemented properties). Daarnaast kun je in c# alleen een field vervangen in een property na hercompilatie van het stukje waarin de property wordt gebruikt, ondanks dat de syntax niet verschillend is. Een van de redenen om maar beter altijd (auto-implemented) properties te gebruiken.

[HarmoniousVibe]

Hmm sorry, ik ken properties alleen vanuit Ruby. Ik ben geen C# programmeur. Dat had ik er misschien bij moeten zeggen. Overigens zeg ik ook nergens dat java wel properties ondersteunt. Het beste wat je met java kunt is autogeneratie van getters en evt setters...

Als de client code gehercompileerd moet worden is het inderdaad beter om altijd properties te gebruiken. Overigens zeg ik dat volgens mij ook op het laatst, zij het om een andere (en minder goede) reden dan jij aanvoert . Dan heb je naast een stabiele API ook een stabiele ABI, wat ook heel wat waard kan zijn in veel gevallen.

[ Voor 9% gewijzigd door HarmoniousVibe op 24-10-2010 17:55 ]

[roy-t]

LB06 schreef op zondag 24 oktober 2010 @ 16:04:
[...]


Sinds dat er properties kunnen worden gebruikt zijn getters en setters (en private attributen?) in principe niet meer nodig en leveren alleen maar onnodig veel werk op. Immers, een publiek attribuut kan zonder dat de API kapot wordt gemaakt worden vervangen door een property. Concreet: customer.accountNumber kan customer.accountNumber blijven, ook al is de implementatie van dit property veranderd. Zie properties maar als een soort van impliciete maner van encapsulatie, in contrast met de expliciete encapsulatie in getters en setters. Of een soort samenvoegsel van attributen en methoden met ingebouwde encapsulatie.

Volgens mij is dit (iig in C#) niet waar.

[HarmoniousVibe]

Oké oké I get it! Ik kruip wel weer terug naar mijn Ruby-hoekje

Overigens klopte het strikt gezien wel wat ik zei: de API blijft stabiel. Er is geen aanpassing in de source code nodig.

[ Voor 54% gewijzigd door HarmoniousVibe op 25-10-2010 09:46 ]

[.oisyn]

roy-t schreef op zondag 24 oktober 2010 @ 21:55:
[...]


Volgens mij is dit (iig in C#) niet waar.

API wel, ABI niet.

[roy-t]

.oisyn schreef op zondag 24 oktober 2010 @ 22:36:
[...]

API wel, ABI niet.

Dus wat betekend dit nu in de praktijk?

[HarmoniousVibe]

roy-t schreef op maandag 25 oktober 2010 @ 09:31:
[...]


Dus wat betekent dit nu in de praktijk?

Dat je zowel de klasse als de client code moet recompilen. Dat hoeft geen probleem te zijn zolang alle code op 1 plaats staat, maar zodra je met RMI/RPC/whatever gaat werken kan dit wel lastig worden.

[ Voor 0% gewijzigd door HarmoniousVibe op 25-10-2010 09:44 . Reden: typo ]

[Verwijderd]

Dat je moet hercompileren als je van een field een property maakt (en andersom, denk ik), omdat andere units anders een field willen lezen/schrijven terwijl ze een call moeten maken naar de betreffende functie.

offtopic:
-edit- Sorry, redundant. Ik had even moeten refreshen.

[ Voor 15% gewijzigd door Verwijderd op 25-10-2010 09:54 ]

[roy-t]

Ja nee, maar .Oisyn doelde erop dat de API hetzelfde blijft, maar de ABI (Application Binary Interface) veranderd. Dus ik vroeg me af of je dan bijvoorbeeld .Net code niet hoeft te recompilen, maar bijvoorbeeld code die jouw code aanroept via COM wel.

[Kajel]

Ik heb eens uitgebreid door dit topic heengelezen, omdat ik momenteel bezig ben met een project voor de MS Surface en ik dus aangewezen ben op C#. Ik kom zelf uit de JAVA hoek, waar Properties niet bekend zijn.

Wat ik nog steeds niet helemaal begrijp, is het volgende:
Wat is nou helemaal het verschil tussen:

• Fields private maken en er public getter en setter methods bij schrijven.
• Properties gebruiken.

[Davio]

Kajel schreef op dinsdag 26 oktober 2010 @ 09:21:
Ik heb eens uitgebreid door dit topic heengelezen, omdat ik momenteel bezig ben met een project voor de MS Surface en ik dus aangewezen ben op C#. Ik kom zelf uit de JAVA hoek, waar Properties niet bekend zijn.

Wat ik nog steeds niet helemaal begrijp, is het volgende:
Wat is nou helemaal het verschil tussen:

• Fields private maken en er public getter en setter methods bij schrijven.
• Properties gebruiken.

Voor zover ik weet: niets. De compiler maakt voor je properties automatisch een get en een set-method. Ik ben met Objective-C voor iOS bezig en daarin bestaat dit ook en staat er letterlijk in het boek dat er gewoon een getPropname en een setPropname methode worden aangemaakt die je eventueel zou kunnen aanroepen via [klasse setPropname:waarde] evenals het normalere klasse.propname = waarde.

[Verwijderd]

Er is één cruciaal verschil: notatie. Het is makkelijker leesbaar om `apple.color = RED` te schrijven dan `apple.setColor(RED)`. Hetzelfde geldt voor `foo = apple.color` tegenover `foo = apple.getColor()`.

[ Voor 35% gewijzigd door Verwijderd op 26-10-2010 10:27 ]

[Refro]

Verwijderd schreef op dinsdag 26 oktober 2010 @ 10:26:
Er is één cruciaal verschil: notatie. Het is makkelijker leesbaar om `apple.color = RED` te schrijven dan `apple.setColor(RED)`. Hetzelfde geldt voor `foo = apple.color` tegenover `foo = apple.getColor()`.

Das natuurlijk behoorlijk subjectief

sommige mensen vinden

code:

if (ptr)
{
 /* bla */
}

Net zo lekker lezen als

code:

if (ptr != NULL)
{
 /* bla */
}

terwijl de 2e duidelijk mijn voorkeur heeft. En een getter of setter hoeven natuurlijk niet met get of set te beginnen. De parameter voor de setter hou je (als is daar in C++ vast ook een manier voor).

[Haan]

Het verschil in C# tussen properties en get/set methodes is wel wat subtieler hoor. Zo worden properties bijvoorbeeld gebruikt bij binden aan datasources, waardoor je bijv. bij een GridView automatisch kolommen krijgt obv de properties in je datasource. Dat is met get/set methodes niet mogelijk.

[Woy]

Haan schreef op dinsdag 26 oktober 2010 @ 10:53:
Het verschil in C# tussen properties en get/set methodes is wel wat subtieler hoor. Zo worden properties bijvoorbeeld gebruikt bij binden aan datasources, waardoor je bijv. bij een GridView automatisch kolommen krijgt obv de properties in je datasource. Dat is met get/set methodes niet mogelijk.

Dat is natuurlijk alleen wat meta-data die automatisch door de compiler word toegevoegd. Je zou iets dergelijks bij Java ook voor elkaar kunnen krijgen met Attributes.

.NET maakt het misschien allemaal iets makkelijker, maar het verschil met get/set methodes is echt niet zo heel groot. Al moet ik zeggen dat ik wel blij ben dat het in .NET zit

[ Voor 13% gewijzigd door Woy op 26-10-2010 11:07 ]

[.oisyn]

roy-t schreef op maandag 25 oktober 2010 @ 10:11:
Ja nee, maar .Oisyn doelde erop dat de API hetzelfde blijft, maar de ABI (Application Binary Interface) veranderd. Dus ik vroeg me af of je dan bijvoorbeeld .Net code niet hoeft te recompilen, maar bijvoorbeeld code die jouw code aanroept via COM wel.

Aangezien de binary interface verandert moet je je .net code juist wél recompilen.

[Verwijderd]

Woy: is dat metadata of is het stiekem gewoon introspection?