4 ms·
Except that his talk is not anti-OOP. It's anti-a-specific-way of using OOP. Namely representing the Domain Model as the compile time hierarchy. He goes to grea
by zaphar 1y ago
Except that his talk is not anti-OOP. It's anti-a-specific-way of using OOP. Namely representing the Domain Model as the compile time hierarchy. He goes to great lengths that he himself uses OOP concepts in his code. OOP wasn't a mistake per-se. The mainstream way of using as promulgated by a number of experts was the mistake.
- mrkeen 1y agoThe problem is when you take out mistakes, there's not much left of OOP. We take out 'dog-is-an-animal' inheritance. We take out object-based delegation of responsibility (an object shall know how to draw itself). A Painter will instead draw many fat structs. Code reuse? Per the talk, the guy who stumbled onto this was really looking for a List<> use-case, (not a special kind of Bus/LinkedList hybrid. He was after parametric polymorphism, not inheritance.
- vkazanov 1y agoThe problem is that once you exclude domain-specific hierarchy from the discussion, there's not much left of OOP. It's just data + relevant functions. Which is ok. That's all there is, really.
- mrkeen 1y agoAnd Rich Hickey calls out even that last feature as a mistake, and I tend to agree. https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#should-i-use-a-namespace-to-bundle-functions-to-model-a-domain-object-like-a-customer-or-product https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd6...
- MantisShrimp90 1y agoYou get it
- igouy 1y ago> "OO is not bad when there is an actual entity - i.e. a stream, a socket, a window, etc to which an object corresponds, or in a simulation of actual entities. That's where it was born and where it shines. … For instance, don't customers buy products? Which should own the functions that involve both?" What is the purpose of the customers / products app?