Property... why?

[JD]

Cor, if you actually read my other post to you, you would see that we
*AGREE*. I will include what I wrote and especially pay attention to the
last sentence.

 

[Josip Medved]

However I am talking about classes which are not build to inherit, just

build for one time use.

I think that I built only few classes to be inherited. Others just got
inherited in time... If you program class like it will never be inherited,
I think that you are making one big mistake. Team work and easier upgrades
of class with properties, I will not discuss now...

 

[Cor Ligthert]

JD,

This is for me not a question of agreeing. My problem with this is, that I
see no reason "Why" I and others do something, therefore I want to know if
somebody can give an answer "Why". This is the case as MN showed. (Without
sentences as best practise).

In that sample can the property be only an accessor to the value or object
and does nothing more. Not encapsulating it or whatever. (And than not in
the cases as I have already told in this thread where you need it to
inherit, for the propertybrowser, etc etc).

However thanks for your answer.

Cor

 

[Herfried K. Wagner [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 true. 'Property with name X and data type Y' stands for "this entity
has an attribute X of data type Y". The underlying data structure that is
used for the property's implementation should be transparent for the
consumer of the class.

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

Sorry, I don't understand what you mean. The data type of a property /is/
important. It's not an implementation detail. The data structure +
algorithms used to implement the property are an implementation detail that
should be hidden (and that are hidden by a property).

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.

Well, but this has nothing to do with a property's data type. It seems that
you are mixing up "data type" with "implementation and data structures".

 

[Cor Ligthert]

Josip,

No other idea by me than yours.
Even not with a NonInheritable Public Class in the situation as you wrote.

Cor

 

[JD]

This is for me not a question of agreeing. My problem with this is, that I
see no reason "Why" I and others do something, therefore I want to know if
somebody can give an answer "Why". This is the case as MN showed. (Without
sentences as best practise).

I agree (no pun intended) thats its not a question about agreeing, but its
important to me if we are talking about the same thing, else we are wasting
each others time for nothing.

In that sample can the property be only an accessor to the value or object
and does nothing more. Not encapsulating it or whatever.

BUT I do disagree with this statement wholeheratedly. It absolutely *does*
encapsultes the implementation! If you disagree with this then we have
nothing more to talk about on this subject.

 

[Chris Dunaway]

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.

This is not necessarily true. The data type of the field is not always the
same as the property. Consider a field variable that is a byte. Suppose
this byte is to be stored in a file as a value of 1 or 0, indicating True
or False. But you want the user of your class to access a boolean to make
it easier for him. In this example, for whatever reason, the true or false
value must be stored in a file as 1 or 0 (perhaps to work with some legacy
code or some language that does not natively support booleans). You might
wish to have a Boolean property to make it easy for the user of the class.

Private m_BoolAsByte As Byte

Public Property BoolAsByte() As Boolean
Get
Return (m_BoolAsByte = 1)
End Get
Set(ByVal Value As Boolean)
If Value Then
m_BoolAsByte = 1
Else
m_BoolAsByte = 0
End If

End Set
End Property

Quite possibly. I agree that an integer field with a string property
doesn't make much sense, but there is the distinct possiblity that the
field variable is not the same type as the property, like my contrived
example above.

Another example is where you might have an integer field variable, but you
want to present the user with only a few possibilities for that value by
using an enum:

Public Enum Possibilities As Integer
FirstPossibility
SecondPossibility
ThirdPossibility
FourthPossibility
End Enum

'Field variable defined as integer
Private m_iPossibleValue As Integer

'Property defined as enum
Public Property PossibleValue() As Possibility
Get
Return CType(m_iPossibleValue, Possibility)
End Get
Set(ByVal Value As Possibility)
m_iPossibleValue = CInt(Value)
End Set
End Property

Now, I don't know how often this type of thing is needed, but my point is
that there may be legitimate reasons for the field to be a different data
type than the property. To my view, this is an endorsement of property
use.

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.

 

[Chris Dunaway]

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.

I also must disagree. You said yourself in an earlier post that the field
variable may be different than the property which I agree with. But
suppose that you simply expose the field and the users of your class
program to that and then later you need to change the implementation to a
different data type? Your users would have to recompile their code. If
you use a property, and your users were coding against that property, you
can change the field all you want without changing the property and your
users would not have to recompile.



--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.

 

[Cor Ligthert]

JD

OK, Show me than what is more encapsulated with JD1 than JD2.

\\\
Public Class main
Public Shared Sub main()
Dim my As New whatever
my.JD1 = "Whatever1"
my.JD2 = "Whatever2"
MessageBox.Show(my.JD1)
MessageBox.Show(my.JD2)
End Sub
Friend Class whatever
Private myvalue1 As String
Protected Friend JD2 As String
Friend Property JD1() As String
Get
Return myvalue1
End Get
Set(ByVal Value As String)
myvalue1 = Value
End Set
End Property
End Class
End Class
///

Cor

 

[Herfried K. Wagner [MVP]]

OK, Show me than what is more encapsulated with JD1 than JD2.

\\\
Public Class main
Public Shared Sub main()
Dim my As New whatever
my.JD1 = "Whatever1"
my.JD2 = "Whatever2"
MessageBox.Show(my.JD1)
MessageBox.Show(my.JD2)
End Sub
Friend Class whatever
Private myvalue1 As String
Protected Friend JD2 As String
Friend Property JD1() As String
Get
Return myvalue1
End Get
Set(ByVal Value As String)
myvalue1 = Value
End Set
End Property
End Class
End Class
///

It's a difference in semantics.

Classes are entities.
Properties are attributes of an entitiy.
Methods are operations an entitiy can perform.

BTW: Variables have disadvantages over properties, for example, they cannot
be overridden.

Variables are semantically /not/ attributes, they are an implementation
detail and should not be used in a class' interface.

 

[Herfried K. Wagner [MVP]]

I also must disagree. You said yourself in an earlier post that the field
variable may be different than the property which I agree with. But
suppose that you simply expose the field and the users of your class
program to that and then later you need to change the implementation to a
different data type? Your users would have to recompile their code. If
you use a property, and your users were coding against that property, you
can change the field all you want without changing the property and your
users would not have to recompile.

Full ACK. Even simple properties remain /properties/.

 

[Cor Ligthert]

Herfried,

BTW: Variables have disadvantages over properties, for example, they
cannot be overridden.

Again an advantage, however I am all the time telling that I see a lot
advantages. However I see not why in some cases it should be used when I see
no advantage, and than the answer is than, it is not OOP because that is
good practise

Cor

 

[Gerry O'Brien [MVP]]

PLONK!

--
Gerry O'Brien
Visual Basic .NET MVP

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

 

[Larry Serflaten]

Again an advantage, however I am all the time telling that I see a lot
advantages. However I see not why in some cases it should be used when I see
no advantage, and than the answer is than, it is not OOP because that is
good practise

Why do you find every event has 'sender' and 'e' ???

(Consistancy is good design....)

LFS

 

[Cor Ligthert]

Larry,

Why do you find every event has 'sender' and 'e' ???

(Consistancy is good design....)

You know that we seldom misagreed, and as well not in this above, but what
you show needs nothing extra to write.

However I am looking for an answer "why". Consistensy can be an answer in
it, but because it are a lot of rows is in this situation am I in doubt if
the medicin is not worser than the disease.

It is a long thread by the way and you can get the idea that it is important
for me, the only thing for me is that I want to know a better reason "why" I
do it.

Cor

 

[Herfried K. Wagner [MVP]]

It is a long thread by the way and you can get the idea that it is
important for me, the only thing for me is that I want to know a better
reason "why" I do it.

Reusability.

 

[Cor Ligthert]

Herfried,

No it is when all those benefits facts are not true, than there is something
as good practise however why?

I have a lot of reasons when a property can be used and when it has
advantages, so I keep me on that good practise. However why should it when I
cannot see any advantage as all.

Good practise has often led to bad code, just because the reason of that
good practise was gone and people did it just because they where used to it.
By instance because it had to be done in a program language which could not
function without that.

Did you see the sample I made for that for JD.

Cor

 

[Larry Serflaten]

However I am looking for an answer "why". Consistensy can be an answer in
it, but because it are a lot of rows is in this situation am I in doubt if
the medicin is not worser than the disease.

No one call see into the future, yet it is a good idea to plan ahead. It makes
good sense to design applications that allow for future expansion, easier
matenance, and upgrades, and the rest. Consider using accessors as leaving
your options open, whether you need to do validation, or not. If you use
a field instead of a public property, you cannot add validation without breaking
your public interface. You may may think you will never need to validate some
boolean, or other data type but again, no one can see the future. Plus closing
the door on validation also closes the door on logging changes, or a large number
of other things you can do with a property, that will not be possible with a field
member.

As I indicated in my last post, consistancy is good design. There are many
times when properties are the right choice, and there are no instances when
a field is needed for which a property will not work. That alone should show
you that always using properties removes the work you do when you decide
if a member should be a field or property. Make them all properties and no
decision is needed, so that decision work is completed, before you even
lift a finger to write the code!

If you want a challenge, you might open up the VS macro editor and create
a macro command that will add property accessors from selected private
variables. With that done, you only need declare the private members and
select them before calling your macro to add the public property code!

In other words, you type in these:

Private m_Name As String
Private m_Age As Integer

And, after selecting them, you run your new macro which will add the
following to the document:

Public Property Name() As String
Get
Return m_Name
End Get
Set(ByVal Value As String)
m_Name = Value
End Set
End Property

Public Property Age() As Integer
Get
Return m_Age
End Get
Set(ByVal Value As String)
m_Age = Value
End Set
End Property


LFS

 

[Cor Ligthert]

Larry,

I leave it by this, however how many times have you planned ahead while even
the programlanguage you was using dispapeared after a while or was not used
anymore. Let us even not speak of the computer and the operatingssystems.

We agree of course both about consistenty however your other answers are
true, however I am too much been disapointed in past because of changes that
nobody could predict, and where from no influence. It is not the work by the
way, it is more the amount of rows I see. I like very compact code. A reason
why I use maybe more classes than others.



However thanks for the try

Cor

 

[Cor Ligthert]

Unreadable.

We agree of course both about consistenty however your other answers are
true, however I am too much been disapointed in past because of changes
that nobody could predict, and where from no influence.

We agree of course both about consistency, however I have seen to much
changes in past that nobody could predict and which completly destroyed
every work done for the future. Therefore I do not believe in, (better I am
even against) trying to do work what maybe can be good for an unpredictable
change in future.