All of the mappings we have so far from real-world problems to software realizations are either bad (in the sense of imprecise and convoluted) mappings or map to pretty bad models (in the sense that the models are either devoid of semantics or have semantics too complex for the working programmer to really understand). OO "works" because it is the least-bad and least-incomprehensible mapping that has been identified to date.The thread is also notable for David Barbour's treatise Being poor at modeling is essential to OOP:
The poor modeling facilities of OOP are caused by essential properties of OOP. These essential properties include encapsulation and message-passing polymorphism. These are the same properties that make OOP powerful for configurable modularity, scalability, and object capability security. ...I do not believe that modeling 'tax reports' in OOP is something that we would 'want' to do. Ever. We might need a tax-report value object as an artifact of the dataflow system (e.g. if tax-reports are dumped into the system as complex form objects), but that's just plain-old-data and could be done just as easily in functional or procedural, and is really not 'OOP'. ...
Your comments (modeling the situation, wanting to model the 'tax reports' explicitly even when it is unnecessary, etc.) and those like them (being extremely prevalent in OO books and the education), are what lead people to start each program by writing a business simulator when what they want are business data processors.
3 comments:
I remember the time my community college C++ teacher got mad when I pointed out that 1) no programmer, not even an OOP-tunnel vision programmer would make a vending machine that did THAT, and 2) building a testing function like THAT into such a device would result in the device needing rebooting.
Finally, she gave up on being rational, and told me that it was just a stupid programming exercise, it didn't HAVE to make sense in the real world. Besides, she backtracked, sometimes when you're programming a function for a dev team, sometimes the function specs are idiotic and you just have to do it because the boss says so.
Oh. Okay. (type type) Done. (I got 100/100 on that assignment once she explained her parameters.)
This calls for some quasi-Wittgensteinian thinking.
Why don't OOP objects match human conceptions of real-world objects? Because there isn't really any human conception of objects. 'Human', or 'mental', objects have no definition, no boundaries. They are one big soup of overlapping concepts. For humans, there is *always* a new, different way to see, describe, or relate to something. No fixed abstraction can ever 'converge' on that.
But software is not *supposed* to match the real world anyway. It is a set of building blocks. It is defined by, it takes its form and structure from, how and what it is *used* for: purposive building of useful artifacts. This is *doing* something quite different to human descriptions, etc., of objects.
Imagining that software should match a mental/real-world object is like saying you want to solve a problem, but without ever finally saying what the problem is. It is impossible, because it doesn't really make sense. The activity of solving presupposes a *definite* problem.
Good observation, Mr. Wittgenstein!
Post a Comment