Thank you for raising this. All too often debates about OOP get hung up on the overuse of inheritance. That’s a fair point, to be sure, but IMHO there are two much more fundamental limitations that are inherent in the OOP way of doing things.
1. In OOP, one object is special.
Whether it’s the object that is receiving a message or the object that gets a special designation like `this` or `self`, something is always given a special emphasis in a purely OOP design.
However, many useful algorithms take multiple inputs where none needs to be singled out in that way. Where do such algorithms live?
Trivial example: A symmetric binary operator like +.
Grown-up example: You don’t really model funds transfers by sending a `debit` message to one instance of a `BankAccount` class and a `credit` message to another instance.
2. In OOP, one object is special.
This is a generalisation of the point that zmb_ made. Usually in programming we don’t work only with single, self-contained data points. Most interesting things happen when we manipulate structured data and consider relationships between data points.
In purely OOP designs, we often see classes representing single data points, and then further classes to represent containers of that type. However, if the implementation of each data point is locked up behind the interface to a particular class, and then we have to access the points in each container through the container’s own generic interface, we are constrained in the access patterns we can use. Emphasizing individual, self-contained data points is often the wrong level of granularity for promoting either code reuse or efficient designs.
Example 1: What if we want to implement a more efficient representation of a data set that supports a different access pattern, such as the kind of continuous memory case zmb_ mentioned?
Example 2: What if we want to enforce constraints on a whole set of data, or model relationships between structured data of different types?
In each case, it may be very difficult to reuse existing algorithms that are locked up in methods on existing single-data-point classes. We might want to store the underlying data in a different format, and converting between formats just to access functionality artificially tied to a specific variation is likely to be awkward and inefficient.
If we instead build our modules as a set of fundamental data types and a set of accompanying algorithms — which could be as simple as a library of C structs/enums and functions using them — then the artificial barrier doesn’t arise. We can still present a clean interface/implementation for each module as a whole, but we aren’t forcing the implementation details to be separated just because Everything Must Be A Class.
In #1, your "trivial" example is actually more of a real issue with OOP than your "grown up" one, since the the latter just illustrates poorly chosen objects and messages, not an issue with OOP as such.
In #2, you again just illustrate a potential poor choice of objects. In both examples for this point, the answer to the "What if" is "you create an object that modes the data set, rather than the individual data points". This is not only consistent with OOP, its fairly routine.
In both examples for this point, the answer to the "What if" is "you create an object that modes the data set, rather than the individual data points". This is not only consistent with OOP, its fairly routine.
And how are you going to implement those “data set” objects, if the only tool you have in your armoury is more objects? Where are you going to put code that works with the underlying data and is useful regardless of the specific structure that data happens to be kept in at the time?
You can model functions as objects and run all sorts of function.call(args) methods, but if it is done out of necessity, it doesn't matter if it is done regularly or consistently with OOP -- OOP is just not the best way to go with this sort of thing.
Comments
Thank you for raising this. All too often debates about OOP get hung up on the overuse of inheritance. That’s a fair point, to be sure, but IMHO there are two much more fundamental limitations that are inherent in the OOP way of doing things.
1. In OOP, one object is special.
Whether it’s the object that is receiving a message or the object that gets a special designation like `this` or `self`, something is always given a special emphasis in a purely OOP design.
However, many useful algorithms take multiple inputs where none needs to be singled out in that way. Where do such algorithms live?
Trivial example: A symmetric binary operator like +.
Grown-up example: You don’t really model funds transfers by sending a `debit` message to one instance of a `BankAccount` class and a `credit` message to another instance.
2. In OOP, one object is special.
This is a generalisation of the point that zmb_ made. Usually in programming we don’t work only with single, self-contained data points. Most interesting things happen when we manipulate structured data and consider relationships between data points.
In purely OOP designs, we often see classes representing single data points, and then further classes to represent containers of that type. However, if the implementation of each data point is locked up behind the interface to a particular class, and then we have to access the points in each container through the container’s own generic interface, we are constrained in the access patterns we can use. Emphasizing individual, self-contained data points is often the wrong level of granularity for promoting either code reuse or efficient designs.
Example 1: What if we want to implement a more efficient representation of a data set that supports a different access pattern, such as the kind of continuous memory case zmb_ mentioned?
Example 2: What if we want to enforce constraints on a whole set of data, or model relationships between structured data of different types?
In each case, it may be very difficult to reuse existing algorithms that are locked up in methods on existing single-data-point classes. We might want to store the underlying data in a different format, and converting between formats just to access functionality artificially tied to a specific variation is likely to be awkward and inefficient.
If we instead build our modules as a set of fundamental data types and a set of accompanying algorithms — which could be as simple as a library of C structs/enums and functions using them — then the artificial barrier doesn’t arise. We can still present a clean interface/implementation for each module as a whole, but we aren’t forcing the implementation details to be separated just because Everything Must Be A Class.
In #1, your "trivial" example is actually more of a real issue with OOP than your "grown up" one, since the the latter just illustrates poorly chosen objects and messages, not an issue with OOP as such.
In #2, you again just illustrate a potential poor choice of objects. In both examples for this point, the answer to the "What if" is "you create an object that modes the data set, rather than the individual data points". This is not only consistent with OOP, its fairly routine.
In both examples for this point, the answer to the "What if" is "you create an object that modes the data set, rather than the individual data points". This is not only consistent with OOP, its fairly routine.
And how are you going to implement those “data set” objects, if the only tool you have in your armoury is more objects? Where are you going to put code that works with the underlying data and is useful regardless of the specific structure that data happens to be kept in at the time?
You can model functions as objects and run all sorts of function.call(args) methods, but if it is done out of necessity, it doesn't matter if it is done regularly or consistently with OOP -- OOP is just not the best way to go with this sort of thing.