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
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.