If I make a class member private, and then I want to acess that member, we have to define a public property for that member. But then I wonder: If we can use the class member publicly by declaring a public property for it, then why don’t we just define the class member itself as public?
This is not really an argument because if you later find the need to do this, you can *still* introduce the property then.
Timwi
2010-08-27 05:16:18
@Timwi, I think changing a member to a property will force code which uses the type within a .dll to recompile. While this isn't a problem for most people, if you are distributing .dlls for 3rd party consumption, this should be avoided.
tster
2010-08-27 05:19:01
Yes, but as you yourself pointed out, it only applies to libraries. Your answer doesn’t state that.
Timwi
2010-08-27 05:20:59
A:
Property accessors (get, set methods) allow you to change your implementation is future. For example, you may start with a backing field (private class member) but later the property may become a result of some calculation. Further, property syntax allows you to have read-only members - so you can change the value only inside your class, outside world can only read it.
VinayC
2010-08-27 05:14:09
This argument makes the case for read-only properties — but not read/write ones. If you later find the need for a property because it turns into a calculated value, you can still introduce the property then.
Timwi
2010-08-27 05:17:37
+12
A:
Microsoft recommends the use of public properties in place of public fields for reasons of binary compatibility. This is only an issue if you are writing a library (which other programs will access).
Basically, imagine this scenario:
- You create a library with a public field
- Someone else writes a program that uses your library and accesses that public field
- Now you want to change your field to a public property because you need to validate the input value, or the property has become the result of a calculation, or you want it to throw exceptions because it’s obsolete, or whatever.
- The user tries to upgrade your library, but not the program that uses the library.
This will completely break the program — it will stop working and only crash. However, if instead of the field you had a public property right from the start, then you could swap the library.
This is, of course, only relevant for libraries. In all other cases, the advice is not really relevant and you can use fields if you like. If you later find that you needed a property, you can still change it to a property then and your program will still compile fine.
Timwi
2010-08-27 05:20:33
A:
Here are some reasons of why we use public properties instead of public fields.
- You can write more complex codes in get/set methods, while there is only a single value in fields.
- Properties makes your code more "OO". Say a class called Person, we can easily guess that there is a property called "Name" in it. But a public field named "Name" is really weird.
- Some attributes work for properties only(AttributeTargets.Property).
Danny Chen
2010-08-27 05:32:05
A:
The reason for using properties is very simple. You can always change the code handling getting/setting it's value without breaking any external program depending on your work - this is not possible with fields. Furthermore, properties can be marked as virtual, and thus, can be redefined by child classes - again without breaking any compatibility.