C# property usage question

  • Thread starter Thread starter vh
  • Start date Start date
V

vh

Hi,
I'm new to C#. Most examples about properties I found are sth like the
following:
class A{
private int property;
public int Property {
get { return property; }
set { property = value; }
}
}

My question is, Can I simply do the following:
class A {
public int Property;
}

Then later, if it turns out that I need to do sth when the property is set
or get, I change it to
class A{
public int Property {
get { <do sth>; return ... }
set { <do sth>; }
}
}
This way, the code that uses A should still compile. Am I right? This way
sounds much simpler to me, you don't have to write those repetitive get&set
unless you later find out that you need. Is this the right way of using
properties? Am I missing sth here?

thanks
vh
 
vh said:
Hi,
I'm new to C#. Most examples about properties I found are sth like the
following:
class A{
private int property;
public int Property {
get { return property; }
set { property = value; }
}
}

My question is, Can I simply do the following:
class A {
public int Property;
}

Then later, if it turns out that I need to do sth when the property is set
or get, I change it to
class A{
public int Property {
get { <do sth>; return ... }
set { <do sth>; }
}
}
This way, the code that uses A should still compile. Am I right? This way
sounds much simpler to me, you don't have to write those repetitive
get&set
unless you later find out that you need. Is this the right way of using
properties? Am I missing sth here?
Click to expand...

yes, an 'o', 'm', 'e','i','n', and a 'g'.

Anyway, the primary differences are:
1) in already compiled code, changing to a property requires all dependent
code to be recompiled. Field to property is a binary breaking change

2) Reflection works differently for fields and properties and therefore will
cause code that works against one to break when it is applied against
others. It may change serialization or other systems that use reflection.

3) a field may be passed as a ref argument to a method, a property may not.
Changing the two will break any code which passes Property by ref(although
thats a bad idea over all, IMHO).

4) public fields are considered bad form in libraries, mainly due to #1 and
#2 above.

If none of these issues apply to your case, you are in the clear. Otherwise,
just get used to typing it and\or write a macro to do it for you.
 
Daniel said:
yes, an 'o', 'm', 'e','i','n', and a 'g'.
??


Anyway, the primary differences are:
1) in already compiled code, changing to a property requires all dependent
code to be recompiled. Field to property is a binary breaking change
Click to expand...

(more field-to-property points snipped).

If I read the OP right, the issue was not starting with a public field and
changing it to a property later, but starting with an empty property and
adding the "get" and "set" parts later.

Joachim
 
Hi vh,

You are right - you *could* do:

class A {
public int Property;
}

but this allows anyone to change or read the value - so there would be no
point in property accessors!

This approach is really looked down apon for a number of reasons principle
among them a subject called encapsulation - external classes shouldnt be
able to "see" the internals of a class. They should only see what the class
chooses to expose. - This prevents the client class from depending on the
implementation of the class, which may subsequently change.

For example. Imagine you have a class called age. If you let a client class
set or get age in any which way it chooses, what happens when you want to
restrict the sorts of ages that can be entered. Say you only want numbers
between 0 and 120 to be entered? In a set property, you could provide that
logic, whereas in a public variable the client classes can do whatever they
want.

Another example - quite often in larger projects you may not want client
code to be able to both set and get particular values. Often you want one or
the other.

Anyway, there are all sorts of quite technical reasons why you shouldnt do
direct access. When you begin to get more confident and want to start taking
on larger projects and want to incorporate patterns and best practive
examples, you really will want to have learned to do things the "correct"
way seeing as everyone else is doing it. Even though at the moment you may
not understand all the reasons for having to do things a particular way.

One last thing - look into OO in general and more specifically
encapsulation. This should help you understand why programmer like to
compaetmentalise everything. (Think building blocks)

HTH

Take care

Simon
 
Joachim said:
(more field-to-property points snipped).

If I read the OP right, the issue was not starting with a public field and
changing it to a property later, but starting with an empty property and
adding the "get" and "set" parts later.
Click to expand...

Reading the OP again, it turns out that I posted nonsense. Sorry for wasting
the bandwidths.

Joachim
 
Joachim Pense said:
Reading the OP again, it turns out that I posted nonsense. Sorry for
wasting
the bandwidths.
Click to expand...

np.

I do find this to be one major missing feature in C#. IMHO they should have
added a property keyword and allowed simple
public property int Property;

but...its not that way and probably never will be.
 
I think it's an important distinction, becauseit allows the caller to know
whether code is run or not.


Daniel O'Connell said:
Joachim Pense said:
Joachim said:
Daniel O'Connell [C# MVP] wrote:


Hi,
I'm new to C#. Most examples about properties I found are sth like the
following:
class A{
private int property;
public int Property {
get { return property; }
set { property = value; }
}
}

My question is, Can I simply do the following:
class A {
public int Property;
}

Then later, if it turns out that I need to do sth when the property is
set or get, I change it to
class A{
public int Property {
get { <do sth>; return ... }
set { <do sth>; }
}
}
This way, the code that uses A should still compile. Am I right? This
way sounds much simpler to me, you don't have to write those repetitive
get&set
unless you later find out that you need. Is this the right way of using
properties? Am I missing sth here?


yes, an 'o', 'm', 'e','i','n', and a 'g'.

??


Anyway, the primary differences are:
1) in already compiled code, changing to a property requires all
dependent code to be recompiled. Field to property is a binary breaking
change


(more field-to-property points snipped).

If I read the OP right, the issue was not starting with a public field
and
changing it to a property later, but starting with an empty property and
adding the "get" and "set" parts later.
Click to expand...

Reading the OP again, it turns out that I posted nonsense. Sorry for
wasting
the bandwidths.
Click to expand...

np.

I do find this to be one major missing feature in C#. IMHO they should have
added a property keyword and allowed simple
public property int Property;

but...its not that way and probably never will be.
Click to expand...
 
Bonj said:
I think it's an important distinction, becauseit allows the caller to know
whether code is run or not.
Click to expand...

Come again? Using a property still doesn't nessecerily look like a property,
changing the language to support simple properties wouldn't help here,
whatsoever.
 
Back
Top