3 ms·
The argument for getters and setters is much stronger when you're writing libraries that are dependencies for projects you don't control. If you own all consum
by barrkel 9y ago
The argument for getters and setters is much stronger when you're writing libraries that are dependencies for projects you don't control.
If you own all consumers of your code, and it's all part of the same project, then you can safely refactor from field access to getters and setters if and when you need to add extra semantics. If you own the consumers but they're not all part of the same project, you can refactor but it will take longer and be a multi-step exercise.
If you don't own the consumers, then you need to break compatibility, which means major version bumps, which will leave some downstream consumers on older versions, and will probably increase version divergence in your userbase, fragmenting the ecosystem and increasing your support load.
- striking 9y agoFrom TFA: > * I would consider creating both a getter and a setter for the data use case in a public API, like let's say I am writing a library meant to be used as a dependency in a lot of other applications. But I would only consider it after exhausting all of these list items.
- benmmurphy 9y agoI think it is kind of insane not to recompile when your downstream dependencies change and the recompilation fixes this problem. Like presumably it makes sense to run your tests again when you change downstream dependencies and it is extra work to run tests independently of recompilation so I think most people's process would be update dependency -> recompile -> run tests. I just remember Java having lots of gotchas with binary compatibility and I assume C# has similar issues. It's just easier to not depend on binary compatibility and always recompile. I'm guessing this is a result of 'insane' processes where you have people upgrading dependencies in deployed applications without properly going through a test process. (EDIT: oops i thought this was a c# post. but this change in java breaks source compatibility as well as binary compatibility)
- jacques_chester 9y agoMy understanding is that C#'s properties were designed pretty much exactly for this situation.
- cup-of-tea 9y agoPython's properties are great for this. You can start off with public attributes and later switch to properties without changing the API.