Hacker News Reader

Comment by _gabe_ | Hacker News Reader

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.

View on HN

Getters 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.

However 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.

Caching, 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()))

Getter 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.

The 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.

True.

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.

OOP 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.

Smalltalk-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

That 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.

I 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.

Reply on news.ycombinator.com