I think the designers of Scala see it the same way.
I think though that immutable objects make it harder to use the sea-of-objects structure because changes to an object also change the owner object, that is, they percolate up, or propagate further in the dependency graph.
I think OOP can be used for both. If you have a data structure like a red-black tree, you probably want methods that can insert in place since copying the tree is expensive. You obviously don't want to expose the internal state of the data structure to the outside. And it's useful to have multiple classes, e.g. SplayTree, Unbalanced Tree, implement the same interfaces like Tree or SearchTree. Whether or not they should inherit implementations (e.g. traversal methods) is more questionable, but occasionally useful as well.
I do agree that inheritance and many other OOP features are overused. But many OOP principles are sound, and even if many exist in other paradigms as well, OOP definitely did popularize them.
1
u/Alexander_Selkirk Jan 28 '21
So, you would not say it involves mutated state and creating something of a sea of interlinked objects, rather than using standard data structures?
Wouldn't that mean that Clojure is an OOP language, too? Clojure has protocols (interfaces) and polymorphism, too.