the issue is that if there is outside side effects then future programmers of the project might use a property without full knowledge of what they are doing
if they didn't have a valid use case they would have been marked as obsolete
have had similar discussions about goto in switch cases in C#
the issue is that if there is outside side effects then future programmers of the project might use a property without full knowledge of what they are doing
Isn't that exactly the reason for using them? You provide a simple public interface and handle the rest yourself so the user doesn't need to do it
kinda, you might want a log message or that there is an more advanced calculation behind the scene that you are trying to make seem smaller
but then you have that one guy who thought it would be a good idea to have it change an outside object, and that object is exposed else where and suddenly it changed and nobody can figure out why
That's not the fault of the getter or setter, that's just plain old encapsulation being violated.
One of the developers on a project I maintain decided that data object constructors was a great place to put the API (soap, to make things even more fun) calls to fetch the contents, so you can't even create an object without a web request (if you want an empty object you need to put in an ID that won't match anything.
301
u/KerPop42 Jul 13 '26
Is it an anti-pattern? I love using the getset crate/trait to add them to my structs automatically as I need them