6 ms·

Java in particular is missing certain language features necessary for easily changing code functionality. This leads to abstractions getting written in to the c

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.

marginalia_nu 4y ago
To be fair, the the Open-Closed principle is basically an article of faith in Java (along with the rest of SOLID).
_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 ago
  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.
- karpierz 4y ago
  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.
  - ratww 4y ago
    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.
  - Xeoncross 4y ago
    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()))
- soganess 4y ago
  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.
  - kadoban 4y ago
    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.
    - ratww 4y ago
      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.
- rileyphone 4y ago
  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.
  - msla 4y ago
    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 https://wiki.c2.com/?HowObjectOrientedIsClos
  - imtringued 4y ago
    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.
andrewaylett 4y ago
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.
imtringued 4y ago
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.

marginalia_nu 4y ago

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

_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 ago
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.
karpierz 4y ago
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.
- ratww 4y ago
  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.
- Xeoncross 4y ago
  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()))
soganess 4y ago
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.
- kadoban 4y ago
  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.
  - ratww 4y ago
    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.
rileyphone 4y ago
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.
- msla 4y ago
  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 https://wiki.c2.com/?HowObjectOrientedIsClos
- imtringued 4y ago
  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.

andrewaylett 4y ago

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.

imtringued 4y ago

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.