Simple property/field question
- Thread starter olsonpm
- Start date
It is recommended, with very few exceptions, that you never publicly expose member fields. Using the short version of a property is much faster to code than the long version (even with intellisense writing the bulk for you; prop TAB TAB), but can of course only be used when you don't have additional code to do in getter/setter. Most designer interaction with types uses property members only.
A few more mentioned here: Properties vs Fields
You can also find much feedback about this on the web, perhaps also even more reasons, just about every VB developer has asked that same question before you.
A few more mentioned here: Properties vs Fields
You can also find much feedback about this on the web, perhaps also even more reasons, just about every VB developer has asked that same question before you.
To me, the reasons for not using a public variable are all apparent in a public shorthand property. There are no getters/setters (which means no abstraction) and they are still available for everyone. The only positives seem to correlate with how the language handles properties vs fields - ignoring the problem with public variables in the first place.
"You can also find much feedback about this on the web, perhaps also even more reasons, just about every VB developer has asked that same question before you."
I realize my initial question wasn't asking what I wanted to know - I apologize for that. The question assumed that you wouldn't want to use public variables, which I didn't make clear. I did look however, and couldn't find the answer after about 20 minutes.
I realize my initial question wasn't asking what I wanted to know - I apologize for that. The question assumed that you wouldn't want to use public variables, which I didn't make clear. I did look however, and couldn't find the answer after about 20 minutes.
Last edited:
I guess I want to know why they made a shorthand public property since it seems as if it were a step backwards. Making a property used to force people to make get/set, but with shorthand it doesn't.
A property is a property. The shorthand version you use when you need a property and have nothing else to add to the standard property layout that has a getter/setter and a private backing field. Why force developers to waste time writing redundant code?
Why wouldn't this recommendation apply? (that so many people agree upon)
"It is recommended, with very few exceptions, that you never publicly expose member fields."
What makes it more secure/more abstract from simply having a public variable?
I keep thinking we're on the same page, but I guess not.
"It is recommended, with very few exceptions, that you never publicly expose member fields."
What makes it more secure/more abstract from simply having a public variable?
I keep thinking we're on the same page, but I guess not.
That's back to the reply in post 2 (I think)... for what the uses are for properties vs fields. A field can not be a substitution for a property, simply because it is not a property.
Ulg, that article just misses my question for the single reason: it doesn't address why public variables were recommended against in the first place. All it says is how many more features a property carries with it than a variable, and why switching between the two causes subtle code changes that one might not expect. In the article, he even says the following:
"Clearly both will expose an object’s state to the outside world, and can be read/modified using the exact same syntax."
That is what I'm confused about. If they both expose the object's state to the outside world and are both modifiable - shouldn't they _both_ be advised against? Hence, they shouldn't have made the public property shorthand in the first place?
"Clearly both will expose an object’s state to the outside world, and can be read/modified using the exact same syntax."
That is what I'm confused about. If they both expose the object's state to the outside world and are both modifiable - shouldn't they _both_ be advised against? Hence, they shouldn't have made the public property shorthand in the first place?
Not sure why you bring up this 'shorthand' issue, is it just a way of declaring a property. It is still a property like any other property, the compiler generates the private fields and the getter/setter and the code to get/set the value of the private field when the property is accessed. It's not the first time simplified syntax has been introduced to make things easier for the VB developer, you know.
Why did they decide to categorize type members into methods, properties, events and fields? Things are named and organized by their logical nature, and these elements have distict purpose. Basically methods perform actions, fields holds object state, properties is a mechanism to interact with object state, and events provide notifications. From there on everything is designed to work by this perspective.
Why did they decide to categorize type members into methods, properties, events and fields? Things are named and organized by their logical nature, and these elements have distict purpose. Basically methods perform actions, fields holds object state, properties is a mechanism to interact with object state, and events provide notifications. From there on everything is designed to work by this perspective.
But, as much as public variables have a bad rap and are advised against in virtually every tutorial there is - this is a new feature that avoids that disclaimer, since I have not seen it anywhere that 'using this shorthand is a bad thing'. Are you saying that even though both carry the same problems, that because one is a property, it is void of such warnings?
"Not sure why you bring up this 'shorthand' issue"
Because what I said above.
"There are no getters/setters (which means no abstraction) and they are still available for everyone."
The getter/setter tells the coder that it is meant to have processing within that code as opposed to just 'return varX' or 'varX = value' - because at that point you might as well just have a public variable.
"Not sure why you bring up this 'shorthand' issue"
Because what I said above.
"There are no getters/setters (which means no abstraction) and they are still available for everyone."
The getter/setter tells the coder that it is meant to have processing within that code as opposed to just 'return varX' or 'varX = value' - because at that point you might as well just have a public variable.
A public field (variable as you say) is not a property, only a property is a property. A property is a precisely defined programming element. The short declaration style property is nothing short of a regular declaration style property.
Similar threads
- Question
