5 ms·

>OO has many drawbacks What are some, according to you? I mean, I have read a bit about why immutability and functional programming is becoming popular, e.g.

by vram22 8y ago

>OO has many drawbacks What are some, according to you? I mean, I have read a bit about why immutability and functional programming is becoming popular, e.g. it makes concurrent programming and use of multiple cores easier (only a general idea, may be wrong). But what are your specific reasons for saying OO has many drawbacks?

jwr 8y ago
My reasons are very pragmatic: I found that OO doesn't bring me any benefits, while imposing a significant cost. This realization came as I switched to Clojure: it found that I'd rather use the generic data structures with the excellent functions that come with the standard library. This gave me much better reusability than inheritance. Enforcing contracts can be done in a multitude of ways, and I no longer liked the idea that the only way to enforce data integrity is by keeping the data private and accessible only using "accessors". Debugging OO code can be a major nightmare. Reading and understanding it is also difficult. How do you know which method implementation will get called at a certain point in your program? You really have no idea until you run it and dynamic dispatch happens. This is also a problem with Clojure multimethods, although it is somewhat mitigated by Clojure's explicit dispatch fn. As for data modeling, I found that inheritance isn't such a useful tool in practice. It looks great in theoretical problems, but in practice the perfect "is a kind-of" relationship is rare. The final nail in the coffin was Clojure's STM. Immutable data structures bring so many benefits that after using them for a while it is unthinkable to me right now to go back to mutating data in-place.
- vram22 8y ago
  Thanks for the info. >As for data modeling, I found that inheritance isn't such a useful tool in practice. True. It can lock you into a particular style and hierarchy. Plus, inheritance just to inherit the methods of the superclass seems like overkill or sometimes might be a wrong approach. Personally I think composition can often be more flexible than inheritance.

by vram22 8y ago

jwr 8y ago

My reasons are very pragmatic: I found that OO doesn't bring me any benefits, while imposing a significant cost. This realization came as I switched to Clojure: it found that I'd rather use the generic data structures with the excellent functions that come with the standard library. This gave me much better reusability than inheritance. Enforcing contracts can be done in a multitude of ways, and I no longer liked the idea that the only way to enforce data integrity is by keeping the data private and accessible only using "accessors". Debugging OO code can be a major nightmare. Reading and understanding it is also difficult. How do you know which method implementation will get called at a certain point in your program? You really have no idea until you run it and dynamic dispatch happens. This is also a problem with Clojure multimethods, although it is somewhat mitigated by Clojure's explicit dispatch fn. As for data modeling, I found that inheritance isn't such a useful tool in practice. It looks great in theoretical problems, but in practice the perfect "is a kind-of" relationship is rare. The final nail in the coffin was Clojure's STM. Immutable data structures bring so many benefits that after using them for a while it is unthinkable to me right now to go back to mutating data in-place.

vram22 8y ago
Thanks for the info. >As for data modeling, I found that inheritance isn't such a useful tool in practice. True. It can lock you into a particular style and hierarchy. Plus, inheritance just to inherit the methods of the superclass seems like overkill or sometimes might be a wrong approach. Personally I think composition can often be more flexible than inheritance.