Earlier quoted context omitted.
It's "pure fashion" until you try to massage your new subclass into behaving slightly differently when you're living with class hierarchies that are N levels deep. Clean compositions, ala Scala traits, can be done with OO. It's just not something I've seen in the wild, or something actively encouraged by any OO teachings I've witnessed. At the same time, composition is pretty much the only way FP is taught (at least…
Exactly this. I think this is the issue with OO that developers have come to realise, and which more functional languages get around. It's the "banana, gorilla, forest" problem that Joe Armstrong of Erlang once mentioned in a book I think, and it boils down to the lack of care when considering separation of concerns. Of course you can separate concerns properly in an OO context, but most developers don't. It's much e…
Back when Gmail just started, one of the things that it made different from other web-mail services (including hotmail) was letting you "label" emails instead of "moving them" to folders.
The problem with Directories was that, at some point, content might have two different classifications, so the question of putting it in two directories arises (if using that abstraction).
Same thing happens with Object hierarchies, even if you start meticulously defining the hierarchy of your objects given the current domain you are mapping, chances are in 2 years you will get a trait/data that does not really fall in one of your defined objects, and you will struggle to put it in one or the other, and your encapsulation will start breaking.
That happens "in practice" in real life, and is something that tons of books about OOD, OOA, and OOP define as incorrect architecture in theory, but there was always a disconnect.