Why have class properties It just looks too much like a way to modify an object's data from outside the object, which leads to sloppy OOP programming( ) Coming from a strong OOP background with C++, selectors and modifiers seem appropriate if we are trying to be truely Object-driven.
So instead of:
Class ThisClass
'
' Data
'
Private m_sName As String
'
' Properties
'
Public Property Name() As String
Get
' Return the value stored in the local variable.
Return m_sName
End Get
Set(ByVal Value As String)
' Store the value in a local variable.
m_sName = Value
End Set
End Property
End Class
Use the following Methods instead
Class ThisClass
'
' Data
'
Private m_sName As String
'
' Selectors
'
Public Function GetName() As String
Return m_sName
End Function
'
' Modifiers
'
Public Sub SetName(ByVal p_sName As String)
m_sName = p_sName
End Sub
End Class
Is it me, or do others with a strong object-oriented background avoid Properties of classes 
Class properties: an invitation to weaker OOP programming?
DenversAllenB
Hmm... OOP is about things like classes, objects, inheritance, polymorphism, encapsulation. I don't see how properties break any of this things. After all whenever you create a property you're in fact creating one or two methods with names like get_PropertyName, set_PropertyName. They are inherited, they can be virtual, they can have access modifiers, they're just methods after all but with a different syntax.
The only problem with properties is that sometimes they may be used improperly but I've yet to see a programming feature that can't be used improperly
. For example people expect properties to behave more like a variable so they usually need to be fast, lightweight. Creating a database connection and running a SQL statement may not be the best thing to do in a property. Returning a different value in the get accessor than the value that was previously set in the set accessor again should be avoided. But I think these ideas are also true for selector/modifiers.
Above all, they have the advantage of setting a common standard. With selectors/modifiers you don't have that. For example some people use SetName/GetName, others set_Name/get_Name, others put_Name/get_Name. And then you want to make a designer and you need something like a PropertyGrid you start to ask yourself "Hmm... now what "properties" this class has Maybe they use get_name, maybe they use GetName or maybe even this class has a method called GetName but it's not intended to be treated as a property.
dr.emulator
"For the encapsulation: you're not supposed to be able to modify the data directly. And using class properties looks exactly like you are directly reading and writing data members, which is pretty much a no-no.." and "Users of a class don't make assumptions about how a class itself is implemented, and it's the class itself that has direct control over how its data is used and modified".
Properties DO NOT give you direct access to data of the class so the class itself still has direct control over its data.
Let's assume you have some class with 2 properties Enabled, Selectable. In the version 1 you use 2 boolean variables to store this properties values. In the version 2 you decide that using 2 boolean variables uses too much memory and you use one bit of the same byte for each of them. You modify the code in the set and get accessor of the property to use that byte and your class clients continue to work. They have no ideea you changed something because properties hide those implementation details just like methods.
"Yet these properties give the illusion of modifying data of objects directly, which still, even from a visual point of view, seems to violate OOP".
OOP is not something visual. The data IS or IS NOT encapsualted and that's all. And you should ask yourself for who is encapsulation important. For the creator of a class or the user of a class. I'd say that ecapsulation matters for the creator of a class. He needs to control how its class is used. The client just uses what the class has. If it has selectors and modifiers he will use them, if the class has properties he will use them, if the class has public variables he will use them.
"And what if it's a variable instead of a method I'd have to check to make sure I'm not really using a poorly written class".
And what if someone created a class that has public variables and no selector modifiers Poorly written code will always exist with or without OOP, with or without properties.
"And i've seen objects just have a "text" properties method. What if there's more than one text item "
The usual handling of this in .NET Framework is that the class has a property called Items or whatever is appropiate in a specific case and that property returns a collection which may have methods like Add, Remove etc depending on the intention of the class author.
"True, but at the expense of making them look like variables of objects. Not sure I'm comfortable with that expense, given the other confusion it can cause .. even wondering if it really is a data item, and not a property method after all."
Well... you said yourself that public data is a no no. Then there is no confusion everything that looks like data is in fact a property because there are no public variable members. Of course, now we come back to those pesky poorly written classes...
James K. Howey
Thank you for the response.
For the encapsulation: you're not supposed to be able to modify the data directly. And using class properties looks exactly like you are directly reading and writing data members, which is pretty much a no-no.. As I'm sure you know, if we're allowing the reading/writing of data members, we've violated one of the major reasons we use OOP: encapsulation. Users of a class don't make assumptions about how a class itself is implemented, and it's the class itself that has direct control over how its data is used and modified. It's one of the biggest things that makes objects so solid and robust.
Yet these properties give the illusion of modifying data of objects directly, which still, even from a visual point of view, seems to violate OOP.
And what if it's a variable instead of a method I'd have to check to make sure I'm not really using a poorly written class.
And i've seen objects just have a "text" properties method. What if there's more than one text item Seems to maintain the more robust concept of OOP by just having "SetThis" and "GetThat" methods, which avoids all of those things that make a programmer wonder when using strange new objects: are those properties or data variables
From what you're saying, you're right: it does seem to, in actuality, work just like methods. Just seems to do so while acting like it's anything but a method, which is unsettling.
True, but at the expense of making them look like variables of objects. Not sure I'm comfortable with that expense, given the other confusion it can cause .. even wondering if it really is a data item, and not a property method after all.
Thank you again for writing!
Skaladar
You brought up a lot of good points. Thank you for replying!