what is the different of the member variable and property?

  • Thread starter Thread starter win
  • Start date Start date
what is the different of the member variable and property?
Click to expand...

A member variable is a variable that is a member of a class. It is
considered bad practice to expose member variables outside of the containing
class. So, in many languages you see a pattern of declaring a set and get
method for each member variable (or field) that they want to expose to the
client code... This often looks something like this:

Class AClass
Private _id As Integer

Public Function GetId () As Integer
Return _id
End Function

Public Sub SetId (ByVal value As Integer)
_id = value
End Sub
End Class


But, VB (and C#) formalize this into a construct known as properties.
Properties are really high level abstractions for the above code, and in fact
that's basically (unnecessary details left out) what the compiler is generating
when it compiles a property.
 
win said:
what is the different of the member variable and property?


Thanks a lot.
Vincent
Click to expand...

A member variable should be a "private" declaration in the class. A
"public" property in a class allows another class to publicly address a
"private" variable in the class by using the public property (get) - to
get the value of the "private" variable from the class or do (let) - to
set value of the "private" variable in a class.

Bottom line is a member variable in a class should not be declared to be
a "public" variable. It should be declared to be a "private" variable.

If the "private" variable within a class must be exposed to another
class, then the class that has the "private" variable must implement a
"public" property so that the "private" variable can be addressed publicly.
 
Tom,

More and more I get confused why I need a property.

Especially when I see an auto implemented properties in C# then I think what
is the sense of that.
public int Tom {get;set;}
for me this is the same as
public int Tom;

In VB
Public Tom as Integer

I find them usefull to use only the set or the get, but not the set and the
get.

Now it looks for me the same as that I have learned that I have to eat with
a knive in my left hand and a fork in my right hand other wise I will get
problems.

Most people on the world eat with their hands or with sticks.

Can you eloberate this a little bit more for me?

Cor



I see use when I only use only a set or a get because then I am limiting the
 
The knife should be readed as in the right hand and the fork in the left
hand.
I have always problems with left and right.

:-)

Cor
 
public int Tom {get;set;} is an automaticaz property i.e; behind the scene
you have a _Tom variable and the code that get sets the variable is crated
for you by the compiler. Yo'ull have this also in VB10.

Now the idea is that if you expose directly a field (member variable) you
have no way to do something tis value si defined. IOn the other hand when
suign a property it llkks the same but your code runs so you have a chance
to take some action.

I you decide to swicth from the former to the later the existing code breaks
as technically this is not the same (i.e this is a rezal affection in the
first case, a call in the second case). So a good practice is to always use
properties so that if you need at a lter time to add some custom code when
then value is changed, you'll be able to do so withoput breaking the
exisitng compiled code...
Click to expand...

Which is why I make it a hard and fast rule that ALL member variables are
declared private. All access to fields are through properties, either public
or protected, etc as needed :)
 
Tom,

That does not change anything.
A public field is an accessor and a public property is an assesor.
It makes sense as it is only a get or a set which is public or as you wrote
only one of those.

But I cannot see what encapsulation is done with a public property which
only gets the value from a private field and set the given value in a
private field.

But I must miss something so some persons are writting about this that it is
very important.

(I know that a field does not show up in a property grid however I mean a
real difference when this kinds of things are not needed)

Cor
 
Tom,

That does not change anything.
A public field is an accessor and a public property is an assesor.
It makes sense as it is only a get or a set which is public or as you wrote
only one of those.

But I cannot see what encapsulation is done with a public property which
only gets the value from a private field and set the given value in a
private field.

But I must miss something so some persons are writting about this that it is
very important.

(I know that a field does not show up in a property grid however I mean a
real difference when this kinds of things are not needed)

Cor
Click to expand...

But it does make a difference Cor... If you are implying that you don't need
properties, then you are correct properties are not needed. They are as I
said, just a highlevel abstraction of a getValue/SetValue method call pair -
but, with more convenient syntax :)

The major point being made is that exposing a member variable directly to
outside of the containing class is a bad idea. For example, what happens to
all existing client code if suddenly you need to add validation to a member
field? Or you want to implement change notification? Or you realize that the
member field really should be a calculated value? I'll tell you what happens
- all the code accessing the value - even if you don't change the name breaks.
If you had just used a property in the first place, then client code would
be blisfully ignorant of the change....

Encapsulation is a good thing, because it insulates client code from changes
in implementation.
 
Tom said:
But it does make a difference Cor... If you are implying that you
don't need properties, then you are correct properties are not
needed. They are as I said, just a highlevel abstraction of a
getValue/SetValue method call pair - but, with more convenient syntax
:)

The major point being made is that exposing a member variable
directly to outside of the containing class is a bad idea. For
example, what happens to all existing client code if suddenly you
need to add validation to a member field? Or you want to implement
change notification? Or you realize that the member field really
should be a calculated value? I'll tell you what happens - all the
code accessing the value - even if you don't change the name breaks.
If you had just used a property in the first place, then client code
would
be blisfully ignorant of the change....

Encapsulation is a good thing, because it insulates client code from
changes in implementation.
Click to expand...

Yes, but removing a field and adding a property is not a change in
implementation. If there is nothing to encapsulate now, I don't create the
additional overhead now. I write code for now and not for later. If it is
not even planned to encapsulate anything in the future I don't need a
property for this.

If you plan to implement anything you wrote above, then a property is
fine. Otherwise there are too many "Ifs": If this or that will happen...
well, maybe - or maybe not? In general, I write the minimum code that I
need now and I take into account things that are planned for the future.
I don't know how to write code considering imaginary things that
might happen in the future because 1 million things can happen in the
future. I am not able to include them all now. This starts from needing
a property and ends in becoming a brick layer.

Or, back to practice, what if you will rethink the object design in future?
The class might become obsolete, so why do you write the class now at all?


Armin
 
Yes, but removing a field and adding a property is not a change in
implementation.
Click to expand...

Yes it is... If you look at it from a library developers perspective :)

If you create a class, and publish and interface that exposes a field, then
change that field access to a property, then you have broken all existing
clients if they update the library.
additional overhead now.
Click to expand...

Simple properties do not, add additional overhead. You know as well as I do
that the JIT compiler inlines access to simple properties.
I write code for now and not for later. If it is
not even planned to encapsulate anything in the future I don't need a
property for this.
Click to expand...

The whole point of encapsulation is to hide implementation details from client
code. Using properties up front insulates existing clients from
future/unknown changes. And since there is almost no runtime overhead for
simple property access - it seems like very cheap insurance.
If you plan to implement anything you wrote above, then a property is
fine. Otherwise there are too many "Ifs": If this or that will happen...
well, maybe - or maybe not? In general, I write the minimum code that I
need now and I take into account things that are planned for the future.
I don't know how to write code considering imaginary things that
might happen in the future because 1 million things can happen in the
future. I am not able to include them all now. This starts from needing
a property and ends in becoming a brick layer.
Click to expand...

Seems like your taking this to the extreme. Adding property is a simple
thing that insulates you from future changes... Again, that is the whole
point of OOD :)
Or, back to practice, what if you will rethink the object design in future?
The class might become obsolete, so why do you write the class now at all?
Click to expand...

That happens... Why do you think the framework has the ObsoleteAttribute.
Why do you think they have guidlines for adding and removing methods from
interfaces.
 
Do you mind if i am a bit dissapointed about that question ? ;-(

http://en.wikipedia.org/wiki/Encapsulation_(computer_science)

Properties are an important aspect of that concept
as a property can react towards field retrievals or settings
this is necesary for value validation , value calculations ,ability to
override , event triggering

Properties are one of the fundaments of OOP for the above reassons




Regards

Michel
 
A few other reassons


In .NET you can use the members of a specified class to bind a control, such
a combo box or a list.
this can only be done with properties

As i am a business developer and was once a commercial library developer i
follow ( try to ) conform to MSF rules
which means checking your code as if it were to be a reusable library (
OOP ) , In this context, the difference in binary calling convention
between fields and properties would matter, because you would not have the
option of simply recompiling all your callers' code.

So from my perspective public class variabels are a big red dot in code
analysis ,a absolute no go area
i just can`t understand why a coder would criple his app on forehand , as i
can do with properties what he can`t but he can`t do what i can with
properties
and after a release to the outside world he has really a problem if he sees
the light .

above is just my humble opinion

regards

Michel Posseth
 
A few other reassons


In .NET you can use the members of a specified class to bind a control, such
a combo box or a list.
this can only be done with properties

As i am a business developer and was once a commercial library developer i
follow ( try to ) conform to MSF rules
which means checking your code as if it were to be a reusable library (
OOP ) , In this context, the difference in binary calling convention
between fields and properties would matter, because you would not have the
option of simply recompiling all your callers' code.

So from my perspective public class variabels are a big red dot in code
analysis ,a absolute no go area
i just can`t understand why a coder would criple his app on forehand , as i
can do with properties what he can`t but he can`t do what i can with
properties
and after a release to the outside world he has really a problem if he sees
the light .

above is just my humble opinion

regards

Michel Posseth
Click to expand...

Very well said :)
 
Michel said:
Do you mind if i am a bit dissapointed about that question ? ;-(

http://en.wikipedia.org/wiki/Encapsulation_(computer_science)

Properties are an important aspect of that concept
as a property can react towards field retrievals or settings
this is necesary for value validation , value calculations ,ability to
override , event triggering

Properties are one of the fundaments of OOP for the above reassons
Click to expand...

Right, but it's still OOP if you use public fields, which is still an option
if none of the reasons above apply.


Armin
 
Michel said:
A few other reassons


In .NET you can use the members of a specified class to bind a
control, such a combo box or a list.
this can only be done with properties
Click to expand...

Right, but you are drawing the wrong conclusion (IMO). My conclusion is that
it's a missing feature that you can not bind to public fields.

So from my perspective public class variabels are a big red dot in
code analysis ,a absolute no go area
i just can`t understand why a coder would criple his app on forehand
, as i can do with properties what he can`t but he can`t do what i
can with properties
Click to expand...

You can always drive the bigger car because you _could_ give more people a
ride but you can also drive the smaller one because you know that you are
alone and you know that you won't give anyone a ride.


I rarely use public fields because in most cases they are not sufficient,
but I don't think they are a no-go.


Armin
 
Armin Zingler said:
Right, but you are drawing the wrong conclusion (IMO). My conclusion
is that
it's a missing feature that you can not bind to public fields.
Click to expand...

Isn't it because bindings rely on events (PropertyChanged) ?
In this case, you need to write a property to raise the event.
 
Tom Shelton said:
If you create a class, and publish and interface that exposes a field,
then
change that field access to a property, then you have broken all existing
clients if they update the library.
Click to expand...

In my experience, any thing that may have prompted the change of a field to
a property also broke the clients in ways that initially exposing the field
as a property would not have protected against.

By far the most common circumstace is a change in validation rules. If the
item is not already being validated, then having it as a property instead of
a field does not usually save the need to make changes at the client. If
the validation is actually being handled in a way that the client does not
need to know about, then it makes no difference whether it is a field or a
property. If the client does need to know about it, then the client needs
to be changed anyway.

In other words, the programming standard of always using a property instead
of a field only makes sense if there are matching standards that apply to
the use of that property - ie always providing a validationfailed routine.

In practice, any time the use of a field changed in this way I have added a
property and deprecated the field.

In my own code I prefer to always work through properties. I can't justify
imposing that as a standard, however.
 
Back
Top