Dom wrote:
Well, this proves the point I made earlier. If gets and sets do
nothing but return a variable and set a variable, it's easier to just
make it public.
Easier? Sure. More appropriate? Probably not, though that depends on
how concerned you are about the encapsulation of your implementation.
In the example you gave, the code that works is a little more complicated:
myObject.Rect = new Rectangle(width, myObject.Rect.Height);
myObject.Rect = new Rectangle(myObject.Rect.Width, height);
Or less literally, but more efficient:
myObject.Rect = new Rectangle(width, height);
But it can easily be done, and without exposing the class's implementation.
You are right that, assuming all your get and set methods do is return
and set a member variable, it's easier to just make the variable public.
But writing simple get and set methods aren't _that_ much harder, they
don't make the code that uses the property _that_ much harder, and they
do have design advantages over simply exposing the member variable as
public.
Note also that the Rectangle struct is a bit of an anomaly. That is, by
convention it is preferable that value types are immutable. Not all
are, and of course the Rectangle falls into this mutable category. But
more generally, since value types are often not mutable in the first
place, exposing the member variable as a public member wouldn't change
the basic behavior anyway; you'd still have to set the whole thing at
once, just as you do with properties.
So, while your observation holds true for the Rectangle struct, and a
handful of other struct types, for many other struct types it's not true
that there's any practical advantage of a public member over a property.
Pete