And furthermore, it is not self-evident that OOP is inherently more efficient than procedural programming.
Your decomposition implies that even the earliest OO concepts existed only as transitional elements in large complex procedural workspace.
At a machine-language level OO creates massive stack manipulations for even the most trivial programs.
And even syntactically, the constant need to add references to accomplish something trivial is somehow annoying.
Procedural: fart()
OO: Body.Intestine.Anus.Fart()
And at the end, is the quality of the code any better? Fundamentally, after all the religion, that should be the only measure that matters.
And in case there is a question, "quality" means "reliable and able to accomplish the intended task without error", not "more readable" as is the standard classroom definition.
To continue the discussion about development languages, I want to ask a potentially embarrassing question: has the whole object orientation business been both a functional and a conceptual failure?
One of the odd things about the OO movement is that no two proponents understand it to mean the same things; but, in the abstract, the generic sales pitch comes in two parts. First is the conceptual part: if you build sufficiently general, sufficiently self-contained, and sufficiently flexible widgets that individually do something predictable to externally supplied data, then you can construct entire applications by using messaging to link these widgets into sequences without having to care about anything that’s internal to any of them. The second part consists of a list of desirable consequences including better overall application design control, the ability to assign multiple parallel work teams, easier debugging, and the benefits of widget re-use.
Imagine, however, what would happen to the claims of modernity and the one right way associated with the OO movement if it could be shown that something as archaic as the original 1957 COBOL MOVE statement and syntax meets the definition? If one could lay a reasonable foundation, in other words, for the proposition that OO has been all been about using new words to label old ideas? - and has, therefore, fundamentally amounted to little more than a chimeric branch to nowhere.
The argument for seeing MOVE as OO compliant is simple: MOVE completely abstracts a complex set of procedures; nicely encapsulates a series of data transforms; has an obvious class/object framework; clearly supports both inheritance and polymorphism (buy a new machine, apply an existing procedure); returns a result based entirely on external operands; is fully reusable; and, is completely non procedural in use.
Notice that the questionable part is messaging: object widgets are characterized by the ability to send, receive, and act on messages. MOVE receives messages as operands and acts on them without affecting external data, but arguably doesn’t send any because there’s no explicit returned value. Internally, however, it does: completion (with or without notification) is itself a message - explicit where a check register is set and implicit where it isn’t.
It sounds absurd, but it’s actually true. MOVE is a label for a set of working procedures developed during the early 1920s for transferring and verifying count totals from one tabulating machine or batch to another. In those days an application consisted of running multiple card batches on multiple machines in just the right sequence and some steps required the operator to copy the end of batch register readings on one machine to one or more start of batch registers on the same or another machine. Since people make mistakes, the procedures for this usually included error checks and since the process inherently required many steps it became known on process flow charts simply as MOVE (values from one or more registers, on one or more machines, to one or more registers, on one or more machine).
In those days, therefore, the MOVE procedure fit today’s class/object hierarchy because different machines had different attributes and thus required different methods to do the same things - and polymorphism because new machines usually combined new functionality with backwards compatibility - meaning that existing procedures worked but could often be usefully extended.
In those days managers wrote procedure sheets including MOVE instructions for clerks to act on - and today’s programmer does exactly the same thing: writing “MOVE XXX to YYY” in lieu of a long series of machine specific steps he doesn’t really care about.
Bottom line? Logically, MOVE is a classic OO widget - and if that sounds absurd, it’s only because this is 2007 and we see MOVE as a very low level operation - something that was not true for a 1925 IBM data processing manager dealing directly with clerks, cards, and tabulators to whom it appeared to be a high level instruction abstracting significant work procedures.
Personally, of course, I agree that this is absurd, but unfortunately it’s also right -meaning that the fundamental underpinnings for the OO movement simply don’t hold up - and consequentially that once you remove the hand waving, the mumbo jumbo, and the modeling religions invoked in any OO application what you have left is 1960s programming by functional decomposition.
And if you don’t know how that turned out, just look at any large scale OO project today.
