That only matters for interfaces which you expose to clients. The real problem with getters & setters & such is when they gum up the internal workings of a codebase, abstracting over nothing and complicating things unnecessarily.
I agree with that. If you create accessors as a matter of course, then you are mostly adding dead weight. But accessors can add a useful layer of abstraction at the interface layer, as you say.
not quite! a property is a pair of methods. if you replace a member with a property, it does remain code compatible as you describe, but breaks the ABI. so if you do this in a published library, clients require a recompile. for this reason, they recommend:
1) different naming convention between members and props
2) dont expose members; use properties from the start for anything public
to assist with two, they introduce the default get/set implementation, like so:
public object Derp { get; set; }
for when you want to expose an interface with the assignment idiom but dont actually have any interesting implementation
bccdee|5 years ago
millstone|5 years ago
Gibbon1|5 years ago
thatjoeoverthr|5 years ago
1) different naming convention between members and props
2) dont expose members; use properties from the start for anything public
to assist with two, they introduce the default get/set implementation, like so:
public object Derp { get; set; }
for when you want to expose an interface with the assignment idiom but dont actually have any interesting implementation