Why use properties?

[Daniel Jin]

Re: Why use properties?



"James Curran" wrote:
[color=blue]
> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> news:MPG.1c1ab4 ce9f48c26798ba3 1@msnews.micros oft.com...
>[color=green]
> > Yes, so long as you don't mind the change in interface. That's the key
> > thing - do you want to maintain interface compatibility as far as
> > possible, or not? I like to on principle, personally.[/color]
>
> But... Are we changing the interface? If a class user were to write
> myObject1.Sales Total = 100.00f;
> it's irrelevant to him if SalesTotal is implemented as a public variable or
> as a property. Nor will he notice if it's changed. (though he will have to
> recompile)
>[/color]

but can you require all production code be recompiled to your changes? I
think that's rather unrealistic.

[Joachim Pense]

Why use public member variables (was: Why use properties?)

Janaka wrote:
[color=blue]
>
> However why is it necessary to create a property if a public member
> variable
> will do. For example:
> public int SalesTotal;
>
> rather than
>
> private int salesTotal;
> public int SalesTotal
> {
> get {return salesTotal;}
> set {salesTotal=val ue;}
> }[/color]

And we got sensible answers, in particular: if you later have to change your
public member variable into a property because get and set become more
complex, you'll have to recompile all calling code.

And, to have your code consistend, you should not mix properties and public
member variables.

OK, so it makes sense to use properties. But why are public member variables
even allowed then? What might be a reason to consider using them?

Joachim

[Frank Hileman]

Re: Why use public member variables (was: Why use properties?)

Here is the rule of thumb we use:

- If a public instance member in an assembly, especially one to be reused by
outside users, always go for a property.

- If an internal Type in an assembly, determine if there are some good
reasons before making a property (error checking, centralization of logic
are good reasons). These will be compiled every time anyway, so the
"recompile" argument doesn't hold.

- If a private Type only used by one other enclosing Type, prefer a public
field, unless there is some other good reason (centralization of logic).
This is the most likely situation where you might use a public field, for
example on an internal lightweight struct definition. The struct used as a
hashtable bucket is a good example.

- Static readonly data may be faster if presented as a public const field.

So there are uses for public fields. If you don't need a property, you can
save a bit of code. But the uses are rare.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor


"Joachim Pense" <spam-collector@pense-online.de> wrote in message
news:coqh3i$ot7 $02$2@news.t-online.com...[color=blue]
> Janaka wrote:
>[color=green]
>>
>> However why is it necessary to create a property if a public member
>> variable
>> will do. For example:
>> public int SalesTotal;
>>
>> rather than
>>
>> private int salesTotal;
>> public int SalesTotal
>> {
>> get {return salesTotal;}
>> set {salesTotal=val ue;}
>> }[/color]
>
> And we got sensible answers, in particular: if you later have to change
> your
> public member variable into a property because get and set become more
> complex, you'll have to recompile all calling code.
>
> And, to have your code consistend, you should not mix properties and
> public
> member variables.
>
> OK, so it makes sense to use properties. But why are public member
> variables
> even allowed then? What might be a reason to consider using them?
>
> Joachim[/color]

[Tom Porterfield]

Re: Why use properties?

On Fri, 3 Dec 2004 12:13:10 -0500, James Curran wrote:
[color=blue]
> But the question was, "what's the advantage of a property if all I need (for
> now) is simple assignment?".
>
> private int salesTotal;
> public int SalesTotal
> {
> get {return salesTotal;}
> set {salesTotal=val ue;}
> }
>
> is better than
>
> public int SalesTotal;
>
> because I might want to change the get/set at some time in the future is a
> false lead, as I could convert the latter into the former at any time.[/color]

Can you do it so easily? You are thinking in a very closed minded manner.
Do you assume that everyone who uses your class will be a language that
hides the actual get/set methods of a property behind direct access? Yes,
in C# if you code a property with a get and set then you can access that
directly via Class.Property. Not all languages support that. In some that
may appear instead as Class.get_Prope rty and Class.set_Prope rty. You will
have already forced a recompile of anyone who uses your object. For those
using a language other than C# or VB you may have also forced them to
change their code. Good design dictates encapsulating access to member
variables through properties. The amount of extra work is extremely small
and the payoff in maintenance is potentially substantial.

Along the same lines I have seen recommendations that you should never
write a public constructor for any of your objects. You should leave the
constructor of your object private, and add a static method that returns an
instance of your object. This would mean that anyone who uses your object
would have to ask you specifically for that instance. The reasoning for
this is again to protect against future modifications that you can not
anticipate today. For example, possibly in some future scenario you end up
with several forms of your object, each coded for a variation of the
scenario for which the first was coded. By coding a method that returns an
instance of your object rather than allowing it to be created directly you
now have control of which variation of your object to return. If the
variations get rather numbered, you can easily delegate the instance
creating method to a factory object that at initial development was not
even considered.

Food for thought.
--
Tom Porterfield