As a life-long developer in OOP languages (C++, Java, C#, among others) I still think OOP is quite good when used with discipline. And it pains me that there is so much misunderstood hate towards it nowdays.
Most often novice programmers try to abuse the inheritence for inpropper avoiding of duplicate code, and write themself into a horrible sphagetti of dependencies. So having a good base or design beforehand helps a lot. But building the code out of logical units with fenced responisbilities is in my opinion a good way to structure code.
Currently I’m doing a (hobby) project in Rust to get some feeling for it. And I have a hard time to wrap my mind around some design choices in the language that would have been very easily solved with a more OOP like structure. Without sacrificing the safety guarantees. But I think they’ve deliberatly avoided going in that direction. Ofcourse, my understanding of Rust is far from complete so it is probably that I missed some nuance… But still I wonder. It is a good learning experience though, a new way to look at things.
The article was not very readable on mobile for me but the examples seemed a bit contrived…
I do not agree. Very often, when using libraries for example, you need some extra custom handling on types and data. So the easy way is to inherit and extend to a custom type while keeping the original functionality intact. The alternative is to place the new functionality in some unrelated place or create non-obvious related methods somewhere else. Which makes everything unnecessary complex.
And I think the trait system (in Rust for example) creates so much duplicate or boilerplate code. And in Rust this is then solved by an even more complex macro system. But my Rust knowledge might just nog be mature enough, feel free to correct me if I’m wrong…