5 ms·
Getter and setters are unnecessary. The thing that most people are trying to avoid by using these is mutating state. However a getter or setter does nothing to
by _gabe_ 4y ago
Getter and setters are unnecessary. The thing that most people are trying to avoid by using these is mutating state. However a getter or setter does nothing to prevent this. A simple `const` keyword goes so much farther than adding useless indirection everywhere.
Edit: I suppose it may be argued that you need to set some other state when you set a member variable. If that's the case, then it's no longer a getter or a setter and the function should be treated differently.
- MichaelBurge 4y agoI think the concern is: It's currently a getter/setter but might change later. Maybe for debugging you want to log a callstack every time the field gets accessed, for example. Or when you set the field, you should invalidate some cached value that uses it.
- karpierz 4y agoGetters and setters are much more useful when accessing or setting the element should require some other function calls. Caching, memoization, and event-logging are examples where you might want this to happen. You can say that's not a getter/setter, but then your definition is just different than the people you're responding to.
- ratww 4y agoHowever Getters/Setters are often the worst place to implement cross-cutting concerns, like caching, memoization and logging. Of course, in more limited languages/environments they're probably the only tool you have, so there's that.
- Xeoncross 4y agoCaching, memoization, and event-logging can be handled by wrapper objects that implement the interface so the base object doesn't need to contain all these layers of outside concerns. Let each class focus on it's single area of use. interface Store { Query() } // these all have the Query() method type/class MySQL implements Store type/class Cache implements Store type/class Logger implements Store var db Store db = new Logger(new Cache(new MySQL()))
- soganess 4y agoGetter and setter are not just for keeping state immutable. They allow an api to control _how_ state changes. The most obvious example is maintaining thread-safety in multi-threaded environments. I get they can be cumbersome, but using them really matters especially as a project grows... an API that has a simple single client today may have many different (and concurrent!) ones tomorrow. The pain of using S&Gs now saves refactoring later.
- kadoban 4y agoThe number of getters and setters I've written that never got changed into anything more than read/change variable has to be _hundreds_ of times more than the ones that ever did anything else. At what point is it cheaper to just refactor into getters/setters later when needed? That point _has_ to be miles behind me.
- ratww 4y agoTrue. Another problem (from a class/library-consumer point of view) is having getters/setters suddenly becoming more expensive to call, blocking, or even having side effects after an update. It often only affect the runtime behavior of the code. Changing the interface, however, will give me a hit that something else has changed.
- rileyphone 4y agoOOP languages shouldn't need getters and setters because there shouldn't be even a concept of variable access and mutation, just all method calls - that's what OOP is all about, after all, not just putting variables into bags and staying in a procedural mindset.
- msla 4y agoSmalltalk-style OO anyway: All You Can Do Is Send A Message. That isn't the only type of OO. Look at CLOS in Common Lisp for a counterexample: https://wiki.c2.com/?HowObjectOrientedIsClos https://wiki.c2.com/?HowObjectOrientedIsClos
- imtringued 4y agoThat will just make everything more convoluted and less flexible. When you send a message over websockets you want a Datatype for each message type. It's not going to have any complicated method calls. You just insert the data or retrieve it on the other side. Since the framework expects you to define setters and getters you do it reluctantly.