Where I work, using Properties are discouraged. We have code generation tools to “speed things up”. All object data ends up being Public fields. If you request properties anyway, you get something like this:
Public sFoo as String
Public Property Foo as String
Get
Return sFoo
End Get
Set(ByVal value as String)
sFoo = value
End Set
End Property
I can’t think of a reasonable argument to do this. Are there any good reasons to use both a Public Property with a Public Field?
4
No.
There’s no good reason for this. It:
- Confuses other programmers by doing something that makes no sense,
- Exposes the innards of your class unnecessarily,
- Provides two entry points for the same thing,
- ??
Use Auto-Implemented Properties instead.
3
One of the fundemental object oriented principles is called Encapsulation. It says that each object should protect it’s data from outside modification.
This is done by making all fields private and if possible also make all property setters private. Instead you have to introduce behaviour by adding methods which is used to modify state.
What you are doing is very wrong. In essence it’s just functional programming where all classes are only data containers or a way of grouping methods togehter. The former is an anti pattern called Anemic Domain Model.
The problem with that is that the business logic for every domain model is spread out over several places in your application (i.e. every place where the object is modified). Hence it’s hard to find bugs related to your business rules as you have to analyze every place where the object is used, instead of just analyzing the object iself.
I’ve blogged about this here: http://blog.gauffin.org/2012/06/protect-your-data/
Are there any good reasons to use both a Public Property with a Public Field?
In short: No, there are no justification for that. The public properties have more business uses than public fields.
Some of the many uses of properties are:
- Properties can validate data before allowing a change
- It can transparently expose data on a class where that data is actually retrieved from some other source, such as a database
- It can take an action when data is changed, such as raising an event, or changing the value of other fields
As already suggested, using auto-properties is another smart way to go with.
More details in MSDN – VB.NET properties