Property... why?

[Gerry O'Brien [MVP]]

See below...

--
Gerry O'Brien
Visual Basic .NET MVP

In that case, you should declare a method with an explicit name (not a
name of a field) which take the value and perform the changes that will be
operated on the class and other classes;
that will be clear for the creator of the class and other developpers that
will use it.

What kind of a name would you suggest? You don't HAVE to use the name
of the field but it is more intuitive. It makes no difference what you call
it as other developers may or may not understand it anyway. It is then up
to you as the original developer of the class to ensure that you have
properly commented your code so that the descriptions show up in the Object
Browser.

It's a bad technique;

Seriously wrong here. Every book on OOP will tell you exactly what Bob
has stated here.

Encapsulating data means also that no one should know what's the type of
your field; I don't think that's what is used with properties.

No it does not. Encapsulation means to hide to implementation of
it. In other words, how the value is assigned within the class. What
purpose would it serve to hide the data type? What you are saying then is
that you would declare a field to be of type integer and then declare a
property for that field to accept a string value. Then in your property set
procedure you would convert the string to an integer?? That makes no sense.

 

[Gerry O'Brien [MVP]]

Well that was a wonderful story Cor. I'm glad you like it.

I stand by what I say as I practice what I preach. I am not blind nor am I
close minded. I speak from what I have experienced and am not influenced by
others opinions until I have verified for myself.

I agree with what Bob has stated and as will many others who have been
programming in OOP for some time.

I find it extremely strange that there should be such a disagreement on what
I considered to be standard OOP technique.

Please, enlighten us all in your wondrous ways of coding so that we may go
forth and be more knowledgeable.

 

[JD]

What about .NET framework using properties throughout all of .NET libraries?
Cause confusion to the developers? Bad technique? Troubles? Day to day
usage, I haven't encountered any problems yet.

Also take a look at Partition V Annexes document, sections on "properties
versus methods" and "property usage guidelines".

 

[Cor Ligthert]

Gerry,

If you are referring to why some programmers prefer using properties to
public fields, then I can tell you why I do it.

1) It is good OOP to encapsulate your member variables.

Yes here is my question "why" we do that in VBNet

2) I prefer to run checks on the data passed into my property procedures
to ensure that the data values are correct for my variables.

Not discussed by me in this thread, even stated

3) It is sort of like creating business logic in a seperate tier. You can
change how the internals work without affecting previously written
applications that subscribe to a specific programming interface. ie, if I
want to change how I store a variable, it is much easier to do so with
properties than if the variable were exposed publicly.

Not discussed by me in this thread, even stated

Even if a property procedure only uses simple get and set routines, I
still write it that way as a matter of code consistency.

This is the only question why I ask "why" we do that, I see no benefits.

Being consistent without reasons does not have to be an advantage. Not doing
it would by instance directly tell that something about the variable.

Cor

 

[Cor Ligthert]

inline...

Why are than parts not discussible and is directly told that someone who
thinks about those, that he is directly inexpirienced. In my opinion do you
have to be expirienced to be able to discuss something.

Doing things because it is always done in the way it was does not lead to
progress.

That is my thought,

Cor

 

[JD]

Why are than parts not discussible and is directly told that someone who
thinks about those, that he is directly inexpirienced. In my opinion do you
have to be expirienced to be able to discuss something.

Doing things because it is always done in the way it was does not lead to
progress.

Its not that "its always done".

The OP asked "why properties?". As Bob, Gerry and others have said,
properties provide encapsulation, period. If you think direct variable
access provides equal or better encapsulation, you would be wrong and I
would look at the definition of encapsulation.

Did the OP ask "do we have to use properties?". No, and no one here is
claiming that, BUT, encapsulation is one of the pillars of object oriented
programming. If you are doing object oriented programming, properties
provide encapsulation, and thats important. If you argue this point, then
you don't know object oriented programming.

But if you are not doing object oriented programming, then encapsulation
isn't that important, and the use and importance of properties may
fluctuate.

 

[Cor Ligthert]

JD.

Means JD the advocacy of the MVP's from Microsoft?

I can assure you that most MVP's are able to speak for themself.

It can be that Djake was meaning with "Why" what you told, however as long
that he did not it can be as well what I suppose it can be, because what I
have seen as answers in this thread is very basic and directly from that old
OOP Bibble. However it is possible that you are as well believing that the
world is flat and I will never argue about believe, because that is
something you do or don't.

Cor

 

[MN]

What kind of a name would you suggest? You don't HAVE to use the name
of the field but it is more intuitive.

Intuitive to know that your property is modifying a specified field;
But the aim is that other developpers don't have to know that they are
modifying a specified field.

No it does not. Encapsulation means to hide to implementation of
it. In other words, how the value is assigned within the class. What
purpose would it serve to hide the data type?

How the value is assigned within the class = hide the data type;
it's equivalent.

What you are saying then is that you would declare a field to be of type
integer and then declare a property for that field to accept a string
value. Then in your property set procedure you would convert the string
to an integer??

Yes because a developper that uses my class don't have to know witch kind of
structure I'm using to store data in my class.

That makes no sense.

So Encapsulation has no sense for you

 

[MN]

What about .NET framework using properties throughout all of .NET
libraries?
Cause confusion to the developers?

I don't say that

Bad technique?

As It's explained and used like :
Public property field as type
get
Return theField
end get
set (byval Value as type)
theField = Value
End set
End property
Yes it's a bad technique.

Troubles?

I don't say that

Day to day usage, I haven't encountered any problems yet.

Have you experienced all possible things?
It's not my case, and in my little experience I encountered some problems.
But this is not the subject of the thread; The question was : "why to use
property get and property set to
access a value in a class, insted of access the value directly?"
And I tried to answer to it.

Also take a look at Partition V Annexes document, sections on "properties
versus methods" and "property usage guidelines".

Thanks for the link;

 

[Cor Ligthert]

1) It is good OOP to encapsulate your member variables.

Yes here is my question "why" we do that often in VBNet

With what I mean, "why" should we do that when it does not encapsulate at
all.

Trying to make this more clear with somehing not yet stated in this thread,
when my class is build to be inherited, than I find properties a big
benefit.

However I am talking about classes which are not build to inherit, just
build for one time use.

Cor

 

[Cor Ligthert]

Garry,

Please, enlighten us all in your wondrous ways of coding so that we may go
forth and be more knowledgeable.

Can you give samples of that. I almost never show something here that is not
OOP or do you want me to explain it more so that you can understand it.

I use almost forever properties in samples or tell that I let them out where
it is standard, I only asking myself "why" am I doing that in some cases.

Cor

 

[JD]

I can assure you that most MVP's are able to speak for themself.

Isn't this a discussion? Or is the great Cor again making another mandate
who is supposed to participate?

 

[JD]

As It's explained and used like :
Public property field as type
get
Return theField
end get
set (byval Value as type)
theField = Value
End set
End property
Yes it's a bad technique.

Sorry I disagree, this is not a bad technique. If the property remains, but
the underlying data structure changes within the class, then clients
accessing the property, and not the underlying member variable, do not have
to change their code, only the underlying implementation changes but the
abstraction remains.

The whole thing about good object design is that clients do not need to know
about the implementation. A well designed class does not need setXXX or
getXXX to inform developers that they are using a method. And any bad
programming that can happen within a property, like making a call to the DB,
can easily happen within a setXXX/getXXX method. Thats more indicative of
bad programming and not a reflection on the property technique itself.

If you are worried about the performance of the simple property example
above versus direct access to the member variable, there is probably a good
chance the whole thing is inlined when JIT'd and is not costing you
anything. But at this point I'm taking a guess since I don't have a debugger
on this machine.

Have you experienced all possible things?
It's not my case, and in my little experience I encountered some problems.
But this is not the subject of the thread; The question was : "why to use
property get and property set to
access a value in a class, insted of access the value directly?"
And I tried to answer to it.

The question was not just what you stated above, but also "What's the
usefulness of property statements in VB.NET?". Again answer being
encapsulation.

Thanks for the link;

Sorry. If you installed the framework then you have it on your harddrive.
Mine its "C:\Program Files\Microsoft.NET\SDK\v1.1\Tool Developers
Guide\docs".

 

[Cor Ligthert]

I leave you to MN,

He is telling in my opinion exactly about this the same as me.

Cor

 

[Gerry O'Brien [MVP]]

Listen Cor, I won't get into a pissing match over this with you. It is as
plain as the nose on your face. It is "recommended best practice". I told
you "why" I do it.

You are free to choose your own method. Do so.

 

[Gerry O'Brien [MVP]]

Inheritance is of one of the three major comcepts in OOP. To say that your
class will not be inherited does not take away the benefit of declaring your
fields private and using pubilc accessor methods.

If you have a variable as public and you are the only one assigning values
to that field, then public is perfectly fine. It just does not follow what
are well known "good" OOP programming practices. That is all we are trying
to state.

As in most things in programming, there is no real right or wrong answer.
If you solution produces the desired output and you use public fields, then
your code is "correct". If I use private fields and public accessor methods
and produced the desired output, then my code is also "correct".

The real "why" of it in my mind is simple. OOP is about code reuse. How
many times will you write a class that could be reused or inherited? In
..NET, it's a good possibility. By being consistent in code writing, your
code is much easier to maintain. It just makes sense.

 

[Gerry O'Brien [MVP]]

--
Gerry O'Brien
Visual Basic .NET MVP

Intuitive to know that your property is modifying a specified field;
But the aim is that other developpers don't have to know that they are
modifying a specified field.

That's right. All they have to know is that they are modifying a
property. Simple.

How the value is assigned within the class = hide the data type;
it's equivalent.

No it is not. If your field data type is a string, you must pass a
string into your property because your property will also be a string type.

 

[Gerry O'Brien [MVP]]

If you almost always use properties, then you need to ask yourself why, not
us. If you can't find your answer or you want to come on here and argue
with others telling you why they do it, this space can be better used to
help those that want it.


Thread ended.

 

[Cor Ligthert]

Listen Cor, I won't get into a pissing match over this with you. It is as

plain as the nose on your face. It is "recommended best practice". I
told you "why" I do it.

You are free to choose your own method. Do so.

Gerry,

You do not have to tell me what method I should use.

I am telling all the time that I use the standard methods, so I do not see
why I should change.

I tell with that in this thread that I do not understand why I do it,
however I do it only because it is written as good practise.

I know and told in this thead a lot of reasons for using properties. However
exactly as MN showed in this thread I have my doubt with one and was hoping
somebody could clarify that to me with something else than "It is good
practise".

Helping people I with the kind of answers you give I have seen more, but
keeping your mouth shut is in my opinion than better.

I am really not waiting on somebody as you who only repeats telling the same
and tells that I am using a wondrous ways of coding, who himself did never
show something in this newsgroup.

Certainly from someone as you who comes with this kind of great OOP advices
in this newsgroup. And let me doubt that he uses OOP himself therefore and
even more what he writes above in this message.

http://groups.google.com/[email protected]

Cor

 

[Cor Ligthert]

"Gerry O'Brien [MVP]"

What are you trying to tell with this what I not already told, I have the
same question as MN, when you do not understand that, than do not give basic
answers that are knowed by most regulars in this newsgroup.

Cor