You'll get you run out of town with that level of heresy in most java/c# shops. Getters and Setters are great when you want finer control over what can access certain fields, in a List class for instance, I wouldn't want the length to be externally writable. But somewhere along the way it went from a useful feature in some circumstances to a mandatory feature in all circumstances.
In the c# world "public int Id;" will fail code review but "public int Id { get; set; }" will be just fine. I've never seen a justification for it though, if we make a change in future it's going to take just as much work and 99.99% of the time will never be required.
"public int Id" should fail the code review, but "public readonly int Id" should not...
public readonly int Id is perfectly fine until the property would actually be needed. The nice thing about properties is that when changing a public field "public readonly int Id" to a property "public int Id { ... }" you don't require any change of calling code. This is really the main benefit of properties over get/set methods.
Now: getters and setters are very useful once you need them. And you don't need them until you do. But there are many good reasons for them: invariants/validation and interfaces are probably the most common.
> if we make a change in future it's going to take just as much work
In Java, changing from a field to using accessor methods requires source changes on the consumer side as well as the class itself. With C# properties this is transparent in source, but I think it still requires recompilation on both sides. Not using fields, therefore, means changes have less impact on other compilation units that might consume the class.
I don't understand your complaint. The problem with getters and setters was the substantial tedious boilerplate required. C# completely does away with that to where there is no meaningful difference between the two in terms of typing required, while at the same time providing the benefit of encapsulation. So what's the problem? Do you really object to 14 more chars to type? That's absurd.
> The problem with getters and setters was the substantial tedious boilerplate required
The problem isn't the tedious boilerplate, it's that it isn't necessary most of the time, 99%+ of getters and setters could be replaced with public fields. c# solved a problem that only existed in the first place because of cargo cult practices.
> while at the same time providing the benefit of encapsulation
It potentially provides encapsulation and I don't really object to them there, but if we just used them where they were really needed then we having a setter/getter function is would have been just fine as well and the language would be simpler.
> Do you really object to 14 more chars to type? That's absurd.
I see you didn't use c# before version 3. Originally they required almost as much boiler plate as java, I've still got a mountain of code around here from that time and all they add to the codebase is noise.
> 99%+ of getters and setters could be replaced with public fields.
Actually it makes more sense the other way around. Fields are just an optimization; the different between fields and properties is one has direct memory access and the other is a method. Properties/methods are far more powerful: their implementation can change, they can be virtual and overridden, etc.
Maybe we could have had just properties and the JIT could have optimized them into direct memory access if they were backed by a simple field.
>The problem isn't the tedious boilerplate, it's that it isn't necessary most of the time
I just don't understand this POV. The cost is essentially zero so I don't see what there is to object to. That it isn't "necessary" is just a strange thing to optimize for. Unnecessary code that adds to the cognitive burden should be eliminated. But this isn't an example of that.
In the c# world "public int Id;" will fail code review but "public int Id { get; set; }" will be just fine. I've never seen a justification for it though, if we make a change in future it's going to take just as much work and 99.99% of the time will never be required.
But we have to appease the encapsulation gods.