Agreed. Objects are nice and a great way to program. Composition is great. Traits/interfaces are great. Namespaces are great. Objects are a really nice way to reap the benefits of principles like these.
But then there are aspects of OOP that absolutely suck, like inheritance. I hate inheritance. The rules get very confusing very quickly. For example, try understanding overriding of methods. Do I need to call the superclass method or not? If not, does it get called automatically? If so, in what order? How do these rules change for the constructor? Now repeat this exercise for every OOP language you use and try not to mix them up… Java, C++, Python, etc.
Fortunately, it feels like we rely on inheritance less and less these days. As an example, I really like how Java allows you to implement Runnable these days. Before, if you wanted to run a thread, you needed a separate object that inherited Thread. And what if that object needs to inherit from another one too? Things would get out of hand quickly. (This is a very old example, but with lambdas and other new features, things are getting even better now.)
Anyway, long story short, I think OOP is a complicated way to achieve good principles, and there are simpler ways to achieve those principles than a full OOP implementation.
I’ve seen this thing where people dislike inheritance a lot, and I have to admit that I kind of struggle with seeing the issue when it’s used appropriately. I write a bunch of models that all share a large amount of core functionality, so of course I write an abstract base class in which a couple methods are overridden by derived models. I think it’s beautiful in the way that I can say “This model will do X, Y, Z, as long as there exists an implementation of methods A, B, C, which have these signatures”, then I can inherit that base class and implement A, B, and C for a bunch of different cases. In short, I think it’s a very useful way to express the purpose of the code, without focusing on the implementation of specific details, and a very natural way of expressing that two classes are closely related models, with the same functionality, as expressed by the base class.
I honestly have a hard time seeing how not using inheritance would make such a code base cleaner, but please tell me, I would love to learn.
Agreed. Objects are nice and a great way to program. Composition is great. Traits/interfaces are great. Namespaces are great. Objects are a really nice way to reap the benefits of principles like these.
But then there are aspects of OOP that absolutely suck, like inheritance. I hate inheritance. The rules get very confusing very quickly. For example, try understanding overriding of methods. Do I need to call the superclass method or not? If not, does it get called automatically? If so, in what order? How do these rules change for the constructor? Now repeat this exercise for every OOP language you use and try not to mix them up… Java, C++, Python, etc.
Fortunately, it feels like we rely on inheritance less and less these days. As an example, I really like how Java allows you to implement
Runnablethese days. Before, if you wanted to run a thread, you needed a separate object that inheritedThread. And what if that object needs to inherit from another one too? Things would get out of hand quickly. (This is a very old example, but with lambdas and other new features, things are getting even better now.)Anyway, long story short, I think OOP is a complicated way to achieve good principles, and there are simpler ways to achieve those principles than a full OOP implementation.
I’ve seen this thing where people dislike inheritance a lot, and I have to admit that I kind of struggle with seeing the issue when it’s used appropriately. I write a bunch of models that all share a large amount of core functionality, so of course I write an abstract base class in which a couple methods are overridden by derived models. I think it’s beautiful in the way that I can say “This model will do X, Y, Z, as long as there exists an implementation of methods A, B, C, which have these signatures”, then I can inherit that base class and implement A, B, and C for a bunch of different cases. In short, I think it’s a very useful way to express the purpose of the code, without focusing on the implementation of specific details, and a very natural way of expressing that two classes are closely related models, with the same functionality, as expressed by the base class.
I honestly have a hard time seeing how not using inheritance would make such a code base cleaner, but please tell me, I would love to learn.