3 ms·

IME, most programmers just write procedural/imperative code using OO semantics rather than trying to write actual OOP code. If you're auto-generating your data

IME, most programmers just write procedural/imperative code using OO semantics rather than trying to write actual OOP code. If you're auto-generating your data classes and then writing static utility functions to operate on them, you're about as non-object oriented as you can get in an object oriented language.

Retric 3y ago
In some ways I agree, but OO is best in moderation. The goal is to be a more useful programming technique and large class hierarchies filled with self contained objects end up being ridged when you want to change fundamental aspects of the project. The objects in OO really don’t need to have anything to do with the outside world. Projects where the majority of the code sits in a handful of giant bloated objects passing messages to each other tends to be quite flexible in practice. This works because rather than treating objects as consistent bundles of data and code throughout the program it’s often useful to think in terms of different contexts and then pass messages between those contexts. The advantage being you have fewer side effects to worry about when editing code, which is really the entire point of OO.
- commandlinefan 3y ago
  > don’t need to have anything to do with the outside world I'd take that a step farther - if they do, that's probably a sign that you're taking things too literally. They probably _shouldn't_ have anything to do with the outside world. I die a little inside every time somebody introduces inheritance with that stupid Dog extends Animal example.
whstl 3y ago
Yes. It pisses me off to no end that in most modern OOP schools there is a noticeable lack of "objects knowing about themselves", since a lot of focus is put on on reducing file LOC and splitting things mindlessly. I've seen developers claiming that "encapsulation" is just about "having getters/setters and private fields". But those getter/setters never get any custom implementation, they're just accessors for other classes. It's not really OOP anymore at this point. Classes are just records, or depositories of procedural subroutines. In the name of Single Responsibility Principle, there's a lot of breaking up classes in a way that forces encapsulation to be broken. A class doesn't always have to expose all its data!

Retric 3y ago

In some ways I agree, but OO is best in moderation. The goal is to be a more useful programming technique and large class hierarchies filled with self contained objects end up being ridged when you want to change fundamental aspects of the project. The objects in OO really don’t need to have anything to do with the outside world. Projects where the majority of the code sits in a handful of giant bloated objects passing messages to each other tends to be quite flexible in practice. This works because rather than treating objects as consistent bundles of data and code throughout the program it’s often useful to think in terms of different contexts and then pass messages between those contexts. The advantage being you have fewer side effects to worry about when editing code, which is really the entire point of OO.

commandlinefan 3y ago
> don’t need to have anything to do with the outside world I'd take that a step farther - if they do, that's probably a sign that you're taking things too literally. They probably _shouldn't_ have anything to do with the outside world. I die a little inside every time somebody introduces inheritance with that stupid Dog extends Animal example.

whstl 3y ago

Yes. It pisses me off to no end that in most modern OOP schools there is a noticeable lack of "objects knowing about themselves", since a lot of focus is put on on reducing file LOC and splitting things mindlessly. I've seen developers claiming that "encapsulation" is just about "having getters/setters and private fields". But those getter/setters never get any custom implementation, they're just accessors for other classes. It's not really OOP anymore at this point. Classes are just records, or depositories of procedural subroutines. In the name of Single Responsibility Principle, there's a lot of breaking up classes in a way that forces encapsulation to be broken. A class doesn't always have to expose all its data!