C# properties are made of methods. Thus, by using methods instead of properties, you do not get any runtime advantages.
Instead it will be all about developer productivity and readability of your code.
Readability is for yourself too. In a few months when you forgot the details of your code and you need to modify it to fix a bug or add a new feature. Even if you do not care about that, you probably care about doing more with the same amount of code.
On the productivity side, we have that properties have the advantage of requiring to write less code. Much more if we are talking about auto-properties. About readability, they result in less verbose code (less
Set and less
Properties may also affect discoverability. As having getter and setters will result in the methods associated with the same field being separated in intellisense.
However, there are some arguments for methods. For instance, if setting a value can fail, you might want to use a method and return
bool so you can communicate to the caller if the set failed. You could, in theory, get away with using a property... after all, the caller can read the property after setting it to check if the value was set. However, returning
bool is a thread-safe ready API.
Another case is when the property has to do a long computation to return a value. Using a method conveys that it is doing something behind the scenes. Similarly, using a method instead of a property can convey that reading the value could have side effects (it is not pure). Addendum: This is not a hard rule. Yet, in general a method does something, it is an action. On the other hand, we expect to be able to read properties at any time without major consequences.
Finally, if you have a property that returns an array, it could be missed for an indexer. It is preferred to provide an actual indexer or use a method to avoid confusion.
By the way, Alan Kay, who coined the term object-oriented, does not like setters. Instead, state should be encapsulated. He said:
Lots of so called object oriented languages have setters and when you have a setter on an object you turned it back into a data structure.
For Alan Kay, letting third parties change the state of the object unexpectedly is a bad idea.
With that in mind, let met tell you about a couple cases where properties are a bad design:
Avoid providing properties as a mean to decide what to do. The caller code should not have to read properties of your object to decide what method to call. Instead encapsulate that logic in the methods of your class. That is, with object-oriented design, prefer Tell, Don't Ask.
Avoid properties that change the behavior of methods. If you have them, you will end up with code that backups the value of a property, change the value, calls the method, then restores the value. Instead add that value as a parameter to the method (even if you need to add it to virtually every method in the class). That makes for a much easier to use API, follows the principle of least astonishment, and it is better for thread-safe code.
Properties, in particular readonly properties, remain very useful for logging and debugging. Also there are things that depend on properties to work, such as some forms of serialization and data binding.