6 ms·

Agreed. I remember thinking "what don't I get? Why do we need getters and setters?". After some years (and discovering Python), I realized there's nothing to ge

Agreed. I remember thinking "what don't I get? Why do we need getters and setters?". After some years (and discovering Python), I realized there's nothing to get, it's just ridiculous overengineering 95% of the time. Same goes for a lot of stuff in OO. I attribute it to the corporate mindset it seems to thrive in, but I could be wrong.

wnevets 7y ago
I feel like what happened to agile development happened to OOP, people morphed it into something that it was never meant to be.
- TheCondor 7y ago
  Yeah, somewhere it stopped being about modeling your problem and it became a code organization technique. There was an incredible effort to formalize different modeling techniques/languages but it’s dried up. It seems to be what we do, I’d say fp is in the same place. My CS program was heavily built around the ML family of languages, specifically Standard ML, with the algebraic types, functions, pattern matching (on your types,) etc. it seems like that “functional programming” is a radically different thing than what people do in js or erlang and call it that. It all comes around, I guess, static types were pretty gauche 10-15 years back and now how many folks are using typescript to make their js better?
- Nasrudith 7y ago
  Evolutionary design is that way in general really. Your intentions never matter - just what it can be used for.
Consultant32452 7y ago
In my opinion OO design is valuable in extremely large code bases and/or code bases that will likely exist for decades and go through multiple generations of significant refactoring. With respect to your setters and getters question, particularly in regards to Python... The @Property feature in Python is just a specific implementation of the setters/getters OO design principle. I can easily be convinced typing foo.x is better than foo.getX(), but I have a hard time having a strong emotional reaction to one vs the other if the language allows them to have the same benefits.
kbp 7y ago
The important thing is restricting your public interface, hiding implementation details, and thinking about how easy your code (and code that uses it) will be to change later. It's not an OO vs anything thing. When you want a value from a module/object/function/whatever, whether or not it's fetched from a location in memory is an implementation detail. Java and co provide a short syntax for exposing that implementation detail. Python doesn't: o.x does not necessarily mean accessing an x slot, and you aren't locking yourself into any implementation by exposing that interface as the way to get that value. It's more complicated than Java or whatever, here, but it hides that complexity behind a nice syntax that encourages you to do the right thing. Some languages provide short syntax for something you shouldn't do and make you write things by hand that could be easily generated in the common case. Reducing coupling is still a good idea.
- weberc2 7y ago
  I don’t think I’ve ever seen a useful “Getter” abstraction...
  - kbp 7y ago
    You're always using a getter. It's just a question of what syntax your language provides for different ways of getting values, and how much they say about your implementation. Most people don't have a problem with getters and setters, they have a problem with writing pure boilerplate by hand. Languages like Python and Lisp save you from the boilerplate and don't provide a nicer syntax for the implementation-exposing way, so people don't generally complain about getters and setters in those languages, only in Java and C++ and things.
    - weberc2 7y ago
      You misunderstood my post. I said I haven’t seen a useful getter abstraction. Not all data access is via a method nor is it always abstract. I specifically object to the useless abstraction, not the boilerplate (boilerplate is cheap).
      - 7y ago
AlexCoventry 7y ago
Getters and setters make more sense in languages where you can't override attribute lookup.
wtracy 7y ago
In the original JavaBeans spec, getters and setters served two purposes: 1. By declaring a getter without a setter, you could make a field read-only. 2. A setter could trigger other side effects. Specifically, the JavaBeans spec allowed for an arbitrary number of listeners to register callbacks that trigger whenever a value gets changed. Of course, nobody actually understood or correctly implemented all this, and it all got cargo culted to hell.
- gmueckl 7y ago
  Finally someone mentions using getters to create read only fields. Objects are the owners and guardians of their own state. I don't see how this is possible without having (some) state-related fields that only can be read from the outside.
  - pjmlp 7y ago
    Pretty obvious to readers of "Object-Oriented Software Construction" from Meyer. A big problem is cargo culting without reading the CS references.
hota_mazi 7y ago
Either you tell your objects what to do, which means they have mutable state, which means you are programming in an imperative way. Or you get values from your objects. You need getters for this, but you can guarantee immutability and apply functional programming principles to your code. You can't have your cake and eat it too. At the end of the day, you need values.
BigJono 7y ago
I get that "what don't I get?" feeling all the time. Overengineering is basically an epidemic at this point, at least in the JS/front-end industry. My guess is there's a correlation between overengineering and career success, which drives it. Simple, 'KISS' style code is the easiest to work with, but usually involves ditching less essential libraries and sticking more to standards, which looks crap on your resume. Most interviewers are more interested in whether you can piece together whatever stack they're using rather than whether you can implement a tough bit of logic and leave great documentation for it; so from a career perspective there's zero reason for me to go for a (relatively) simple 100 line solution to a tough problem when I can instead go for a library that solves 100 different use cases and has 10k lines of documentation that future devs have to wade through. The former might be the 'best' solution for maintainability but the latter will make me appear to be a better engineer, especially to non-technical people, of which there are far too many of on the average team.
- revvx 7y ago
  Thanks for that. That resonates a lot with me. It makes me feel better realizing that I'm not alone in thinking that. Recent writings by Joe Armstrong are also resonate with me the same way.
- gmueckl 7y ago
  Well, it depends on what you are doing. I designed some systems that were too complex and some that were too simple and couldn't grow as a result. So, with experience, one will hopefully see that supposed overengineering is sometimes only overengineering until you actually need that specific flexibility in a growing system. And there is little substitute for experience to know which is which.
revvx 7y ago
IME the thing with getters and setters is that everyone is doing it (inertia) and that other options either suck (syntactically) or break the "everything is a class" constraint. Ruby is far from being my favorite language, but I like how Structs "solve" the getter/setter problem in it: my_struct = Struct.new(:field_one, :field_two) It doesn't clutter your code with multiple lines of boilerplate, and it returns a regular class for you to use, not breaking the "everything is a class" constraint.
vnorilo 7y ago
It's harder to write simple code because that requires a crystallized understanding of the problem. You can start banging out FactoryManagerFactories without having the faintest idea of the core problem at hand. Maybe some of the silliest OO patterns are like finger warmup for coders? Unfortunately that stuff still ends up sticking to the codebase.

wnevets 7y ago

I feel like what happened to agile development happened to OOP, people morphed it into something that it was never meant to be.

TheCondor 7y ago
Yeah, somewhere it stopped being about modeling your problem and it became a code organization technique. There was an incredible effort to formalize different modeling techniques/languages but it’s dried up. It seems to be what we do, I’d say fp is in the same place. My CS program was heavily built around the ML family of languages, specifically Standard ML, with the algebraic types, functions, pattern matching (on your types,) etc. it seems like that “functional programming” is a radically different thing than what people do in js or erlang and call it that. It all comes around, I guess, static types were pretty gauche 10-15 years back and now how many folks are using typescript to make their js better?
Nasrudith 7y ago
Evolutionary design is that way in general really. Your intentions never matter - just what it can be used for.

Consultant32452 7y ago

In my opinion OO design is valuable in extremely large code bases and/or code bases that will likely exist for decades and go through multiple generations of significant refactoring. With respect to your setters and getters question, particularly in regards to Python... The @Property feature in Python is just a specific implementation of the setters/getters OO design principle. I can easily be convinced typing foo.x is better than foo.getX(), but I have a hard time having a strong emotional reaction to one vs the other if the language allows them to have the same benefits.

kbp 7y ago

The important thing is restricting your public interface, hiding implementation details, and thinking about how easy your code (and code that uses it) will be to change later. It's not an OO vs anything thing. When you want a value from a module/object/function/whatever, whether or not it's fetched from a location in memory is an implementation detail. Java and co provide a short syntax for exposing that implementation detail. Python doesn't: o.x does not necessarily mean accessing an x slot, and you aren't locking yourself into any implementation by exposing that interface as the way to get that value. It's more complicated than Java or whatever, here, but it hides that complexity behind a nice syntax that encourages you to do the right thing. Some languages provide short syntax for something you shouldn't do and make you write things by hand that could be easily generated in the common case. Reducing coupling is still a good idea.

weberc2 7y ago
I don’t think I’ve ever seen a useful “Getter” abstraction...
- kbp 7y ago
  You're always using a getter. It's just a question of what syntax your language provides for different ways of getting values, and how much they say about your implementation. Most people don't have a problem with getters and setters, they have a problem with writing pure boilerplate by hand. Languages like Python and Lisp save you from the boilerplate and don't provide a nicer syntax for the implementation-exposing way, so people don't generally complain about getters and setters in those languages, only in Java and C++ and things.
  - weberc2 7y ago
    You misunderstood my post. I said I haven’t seen a useful getter abstraction. Not all data access is via a method nor is it always abstract. I specifically object to the useless abstraction, not the boilerplate (boilerplate is cheap).
    - 7y ago

AlexCoventry 7y ago

Getters and setters make more sense in languages where you can't override attribute lookup.

wtracy 7y ago

In the original JavaBeans spec, getters and setters served two purposes: 1. By declaring a getter without a setter, you could make a field read-only. 2. A setter could trigger other side effects. Specifically, the JavaBeans spec allowed for an arbitrary number of listeners to register callbacks that trigger whenever a value gets changed. Of course, nobody actually understood or correctly implemented all this, and it all got cargo culted to hell.

gmueckl 7y ago
Finally someone mentions using getters to create read only fields. Objects are the owners and guardians of their own state. I don't see how this is possible without having (some) state-related fields that only can be read from the outside.
- pjmlp 7y ago
  Pretty obvious to readers of "Object-Oriented Software Construction" from Meyer. A big problem is cargo culting without reading the CS references.

hota_mazi 7y ago

Either you tell your objects what to do, which means they have mutable state, which means you are programming in an imperative way. Or you get values from your objects. You need getters for this, but you can guarantee immutability and apply functional programming principles to your code. You can't have your cake and eat it too. At the end of the day, you need values.

BigJono 7y ago

I get that "what don't I get?" feeling all the time. Overengineering is basically an epidemic at this point, at least in the JS/front-end industry. My guess is there's a correlation between overengineering and career success, which drives it. Simple, 'KISS' style code is the easiest to work with, but usually involves ditching less essential libraries and sticking more to standards, which looks crap on your resume. Most interviewers are more interested in whether you can piece together whatever stack they're using rather than whether you can implement a tough bit of logic and leave great documentation for it; so from a career perspective there's zero reason for me to go for a (relatively) simple 100 line solution to a tough problem when I can instead go for a library that solves 100 different use cases and has 10k lines of documentation that future devs have to wade through. The former might be the 'best' solution for maintainability but the latter will make me appear to be a better engineer, especially to non-technical people, of which there are far too many of on the average team.

revvx 7y ago
Thanks for that. That resonates a lot with me. It makes me feel better realizing that I'm not alone in thinking that. Recent writings by Joe Armstrong are also resonate with me the same way.
gmueckl 7y ago
Well, it depends on what you are doing. I designed some systems that were too complex and some that were too simple and couldn't grow as a result. So, with experience, one will hopefully see that supposed overengineering is sometimes only overengineering until you actually need that specific flexibility in a growing system. And there is little substitute for experience to know which is which.

revvx 7y ago

IME the thing with getters and setters is that everyone is doing it (inertia) and that other options either suck (syntactically) or break the "everything is a class" constraint. Ruby is far from being my favorite language, but I like how Structs "solve" the getter/setter problem in it: my_struct = Struct.new(:field_one, :field_two) It doesn't clutter your code with multiple lines of boilerplate, and it returns a regular class for you to use, not breaking the "everything is a class" constraint.

vnorilo 7y ago

It's harder to write simple code because that requires a crystallized understanding of the problem. You can start banging out FactoryManagerFactories without having the faintest idea of the core problem at hand. Maybe some of the silliest OO patterns are like finger warmup for coders? Unfortunately that stuff still ends up sticking to the codebase.