W
win
what is the different of the member variable and property?
Thanks a lot.
Vincent
Thanks a lot.
Vincent
T
Tom Shelton
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.
M
MBUnit
win said:
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.
C
Cor Ligthert[MVP]
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
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
C
Cor Ligthert[MVP]
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
hand.
I have always problems with left and right.
Cor
M
Michel Posseth [MCP]
Encapsulation is one verry important reasson
regards
Michel
A
Armin Zingler
Michel said:
Encapsulate what?
Armin
T
Tom Shelton
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
C
Cor Ligthert[MVP]
Same reply as Armin
Cor
Cor
Michel Posseth said:
C
Cor Ligthert[MVP]
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
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
T
Tom Shelton
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.
A
Armin Zingler
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.
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
T
Tom Shelton
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.
Simple properties do not, add additional overhead. You know as well as I do
that the JIT compiler inlines access to simple properties.
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.
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
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.
M
Michel Posseth [MCP]
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
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
M
Michel Posseth [MCP]
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
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
T
Tom Shelton
Very well said
A
Armin Zingler
Michel said:
Right, but it's still OOP if you use public fields, which is still an option
if none of the reasons above apply.
Armin
A
Armin Zingler
Michel 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.
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
F
Fred
Armin Zingler said:
Isn't it because bindings rely on events (PropertyChanged) ?
In this case, you need to write a property to raise the event.
J
James Hahn
Tom Shelton said:
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.