Properties

[SpongeBob]

I am a c++ programmer and quiet new to c sharp.
Unfortunately, i didnt understand what the adventage of a property is.

Let's assume, i have a class(Calculator) field:
int num;

Calculator c = new Calculator();
So, what for an advantage do i have if i write:
c.num = 5;
instead of :
c.Num = 5; // assuming that a property with this name and a set already
created

Thats almost the same, isn't it ?

--
Schwammkopf

[Chris Dunaway]

On Jan 26, 1:46 pm, "SpongeBob" <[e-mail]:

I am a c++ programmer and quiet new to c sharp.
Unfortunately, i didnt understand what the adventage of a property is.

Let's assume, i have a class(Calculator) field:
int num;

Calculator c = new Calculator();
So, what for an advantage do i have if i write:
c.num = 5;
instead of :
c.Num = 5; // assuming that a property with this name and a set already
created

If you will search these groups, you will find many discussions on this
issue. One reason for using a property is that you can validate the
data being put into the field. With direct field access, you cannot
control what will be assigned to that variable.

[Barry Kelly]

SpongeBob wrote:

I am a c++ programmer and quiet new to c sharp.
Unfortunately, i didnt understand what the adventage of a property is.

It permits changing the implementation after the fact.

Let's assume, i have a class(Calculator) field:
int num;

Calculator c = new Calculator();
So, what for an advantage do i have if i write:
c.num = 5;
instead of :
c.Num = 5; // assuming that a property with this name and a set already
created

Thats almost the same, isn't it ?

If you have clients (i.e. third-party code) that are compiled to use
(dynamically, like all .NET libraries) a library containing this class,
then they will have hard references to a field. If you later want to
update the library and calculate the value of the 'Num' field rather
than store it, or if you want to store the field somewhere else (maybe
in a hash table for 'sparse objects'), or if you want a read-only field,
then the fact that it's a field prevents you from doing these things.

Properties permit library authors to change the implementation of a
'field' after the fact. The reverse isn't true: once a field, always a
field.

-- Barry

--
http://barrkel.blogspot.com/

[Charles Calvert]

On Fri, 26 Jan 2007 20:46:08 +0100, "SpongeBob" <an**@sbox.tugraz.at>
wrote in <uT**************@TK2MSFTNGP05.phx.gbl>:

>I am a c++ programmer and quiet new to c sharp.
Unfortunately, i didnt understand what the adventage of a property is.

One thing that is important to understand is that the compiler creates
getters and setters for each property (assuming that both get and set
are specified). So, if you have a class with this property:

public string Foo
{
get { return m_foo; }
set { m_foo = value; }
}

The compiler will actually generate the methods get_Foo and set_Foo in
the assembly. The end result is very similar to creating your own
accessors in C++ instead of using a public member variable. The
advantage is that the syntax is nicer.

There are many advantages over public fields:

1. The get method can automatically calculate the value of the
property based on some internal data.

2. The set method can do all sorts of things, such as call member
methods to reevaluate the instance's state based on the value passed
in.

3. As others have pointed out, you can change the internal
implementation whenever you like without breaking the interface.

4. Using properties makes composition and delegation easy by allowing
you to wrap the composed class's properties in the composing class's,
just like with methods. You can't do this with public fields.

There are lots of other reasons. As Chris Dunaway suggested, check
the Google Groups archives for past discussions.
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
[phone] | Research