A question on properties

[Dom]

I have a class that has a System.Drawing.Rectangle as a member, called
m_Rect. I set it up as a property, like this:

get { return m_Rect;}
set { m_Rect = value;}

Now in my main code I want to do the following:

myObject.Rect.Width = width;
myObject.Rect.Height = height;

I can see why I can't -- I guess myObect.Rect.Width is calling up the
"get" and not the "set". But is there some way to do what I want?

Dom

 

[Jon Skeet [C# MVP]]

I have a class that has a System.Drawing.Rectangle as a member, called
m_Rect. I set it up as a property, like this:

get { return m_Rect;}
set { m_Rect = value;}

Now in my main code I want to do the following:

myObject.Rect.Width = width;
myObject.Rect.Height = height;

I can see why I can't -- I guess myObect.Rect.Width is calling up the
"get" and not the "set". But is there some way to do what I want?

Well, you could create your own properties which get/set the
appropriate properties in m_Rect.

Jon

 

[Dom]

Well, you could create your own properties which get/set the
appropriate properties in m_Rect.

Jon

I'm not sure I get this. Do you mean properties called "Rect_Width"
and "Rect_Height" which then changes the m_Rect member?

 

[Jon Skeet [C# MVP]]

I'm not sure I get this. Do you mean properties called "Rect_Width"
and "Rect_Height" which then changes the m_Rect member?

Yup. (I wouldn't include underscores myself, but it's entirely up to
you.)

Jon

 

[Dom]

Yup. (I wouldn't include underscores myself, but it's entirely up to
you.)

Jon

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.

My $.02

Dom

 

[Jon Skeet [C# MVP]]

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? Temporarily. Less maintainable in the long run, however.

There are lots of best practices which are costly in the short term,
but have great benefit in the long term. Not exposing public variables
is just one of them.

 

[Peter Duniho]

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