Hacker News Reader

Comment by ThrustVectoring | Hacker News Reader

Java in particular is missing certain language features necessary for easily changing code functionality. This leads to abstractions getting written in to the code so that they can be added if needed later.

A specific example is getters and setters for class variables. If another class directly accesses a variable, you have to change both classes to replace direct access with methods that do additional work. In other languages (Python specifically), you can change the callee so that direct access gets delegated to specific functions, and the caller doesn't have to care about that refactor.

View on HN

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.

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.

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.

That's a design choice though -- if you're structuring your code to avoid mutable state, you're not going to have setters. And if you're structuring your code such that you're telling objects what to do, rather than pulling data out of them and acting on them remotely, then you're not necessarily going to have getters either.

To be fair, the the Open-Closed principle is basically an article of faith in Java (along with the rest of SOLID).

The getter setter nonsense is 99% compliance for specific frameworks like Hibernate or shudder, JSF but it caught on and now nobody wants to be seen without using ugly getters and setters which would be perfectly fine if the language natively supported them.

Reply on news.ycombinator.com