class properties

  • Thread starter Thread starter mp
  • Start date Start date
M

mp

trying to understand properties
normally i would create a private variable and return that in a get, assign
it in a set
class TestProperty
{
private List<string> _someList= new List<string>();
public List<string> SomeList { get{return _someList;} set{_someList
= value;} }
...}

i see in c# the type of property that doesn't use a variable (must create a
hidden var behind the scenes or something...)
class TestProperty
{
public string strProp { get; set; }
...}

I got to wondering if I was wasting a variable by using the first (more
verbose) style
so i tried it with a list but that didn't work because (naturally) the list
was null

class TestProperty
{
public List<string> SomeList { get; set; }
public TestProperty()
{
}
public void Test()
{
// A first chance exception of type
'System.NullReferenceException'
SomeList.Add ("Test1");
}
}

yet with a string it does work...although a string is also an object so not
sure why i didn't get the same null reference exception

class TestProperty
{
public string strProp { get; set; }

public TestProperty()
{
}
public void Test()
{ //this works
strProp = "Test strprop";
}
}

appreciate any background or sites that explain why the difference...
i searched msdn and most examples have the more verbose style with private
variable returned from a property
there's probably a good explanation in there somewhere but i haven't
stumbled on to it yet.
and maybe the style that doesn't use a variable isn't any more efficient
than the one that does

i imagine if the class doesn't have to interact with the value during its
lifetime other than to receive a setting from client and return it when
asked, then the variable is of not much use...
but if the class in any method needs to manipulate the variable, then the
private var is useful(though it could probably access it's own property i
would guess...so i'm not sure about that either)

thanks for any input
mark
 
I got to wondering if I was wasting a variable by using the first (more
verbose) style
so i tried it with a list but that didn't work because (naturally) the
list was null

class TestProperty
{
public List<string> SomeList { get; set; }
public TestProperty()
{
}
public void Test()
{
// A first chance exception of type
'System.NullReferenceException'
*******

SomeList.Add ("Test1");
}
}
Click to expand...

Now it'll work. See the difference? If, in your string example, you had
tried to, say, get a substring before you set the value you'd have gotten
the same error.
 
Jeff Johnson said:
Now it'll work. See the difference? If, in your string example, you had
tried to, say, get a substring before you set the value you'd have gotten
the same error.
Click to expand...

ah, but you don't have to new a string...but you do some other objects...why
is that?
i guess the system is newing the variable behind the scenes basically?

so do you think the "variable-less" property style is more efficient than
creating and returning a private variable?

thanks
mark
 
ah, but you don't have to new a string...but you do some other
objects...why is that?
Click to expand...

Syntactic sugar.

x = "Hi there";

is just a shortcut for

x = new string("Hi there");
i guess the system is newing the variable behind the scenes basically?
Exactly.

so do you think the "variable-less" property style is more efficient than
creating and returning a private variable?
Click to expand...

I don't know about "efficient." The same IL code should be getting created
behind the scenes if the ONLY thing you're doing is setting and returning
the backing variable. Ultimately it's about "good code" and "best practices"
and blah blah blah.

I like my backing variable. I like being able to shoot myself in the foot by
manipulating that variable outside the control of the setter. But that's
just me.
 
Jeff Johnson said:
ah, but you don't have to new a string...but you do some other
objects...why is that?
Click to expand...
[...]

I like my backing variable. I like being able to shoot myself in the foot
by manipulating that variable outside the control of the setter. But
that's just me.
Click to expand...

one can never have too many ways to f up.
:-)
 
trying to understand properties
normally i would create a private variable and return that in a get, assign
it in a set
class TestProperty
{
private List<string> _someList= new List<string>();
public List<string> SomeList { get{return _someList;} set{_someList
= value;} }
...}

i see in c# the type of property that doesn't use a variable (must create a
hidden var behind the scenes or something...)
class TestProperty
{
public string strProp { get; set; }
...}
Click to expand...

It does create a hidden variable.

But it does not set it.

So it is equivalent to:

class TestProperty
{
private List<string> _someList; // = new List<string>();
public List<string> SomeList { get{return _someList;}
set{_someList = value;} }
...}
I got to wondering if I was wasting a variable by using the first (more
verbose) style
so i tried it with a list but that didn't work because (naturally) the list
was null

class TestProperty
{
public List<string> SomeList { get; set; }
public TestProperty()
{
}
public void Test()
{
// A first chance exception of type
'System.NullReferenceException'
SomeList.Add ("Test1");
}
}
Click to expand...

Either the constructor needs to set SomeList.

Or the caller needs to set before calling Test.
yet with a string it does work...although a string is also an object so not
sure why i didn't get the same null reference exception

class TestProperty
{
public string strProp { get; set; }

public TestProperty()
{
}
public void Test()
{ //this works
strProp = "Test strprop";
}
}

appreciate any background or sites that explain why the difference...
Click to expand...

This does not use the null reference but instead assigns
a valid reference.
i imagine if the class doesn't have to interact with the value during its
lifetime other than to receive a setting from client and return it when
asked, then the variable is of not much use...
but if the class in any method needs to manipulate the variable, then the
private var is useful(though it could probably access it's own property i
would guess...so i'm not sure about that either)
Click to expand...

I think the most common case with a List would be to
set it in constructor and have a method that returns
an unmodifiable list and a method to add to the list.
Better encapsulation.

Arne
 
Syntactic sugar.

x = "Hi there";

is just a shortcut for

x = new string("Hi there");
Click to expand...

Not really.

That constructor does not exist and if it did, then
it would create an extra object.

Arne
 
so do you think the "variable-less" property style is more efficient than
creating and returning a private variable?
Click to expand...

No.

The difference will be insignificant.

Arne
 
I don't know about "efficient." The same IL code should be getting created
behind the scenes if the ONLY thing you're doing is setting and returning
the backing variable. Ultimately it's about "good code" and "best practices"
and blah blah blah.

I like my backing variable. I like being able to shoot myself in the foot by
manipulating that variable outside the control of the setter. But that's
just me.
Click to expand...

Where the difference really shows up is of the property is
virtual and getting overridden in a sub class, then there
can be a functional difference between field and property.
In most cases I think the behavior of direct field access
will be least surprising.

Arne
 
Back
Top