OOP Impact - How Do OOP Programmers Have to Think?
Object-oriented programming is not just a new programming paradigm; it represents a new way of thinking about programming. Programmers writing in OOP languages do not just change their modes of expression. Rather, as noted by the linguist Edward Sapir, a radical change of language forces a complete shift in the approach to programming and in the way that programmers have to think.
An often cited (although factually incorrect) example has to do with Eskimos and snow (Pullum, The Great Eskimo Vocabulary Hoax). Eskimo languages have a large variety of words to describe snow: different sorts of wet, fluffy, crusted, icy, etc. The Eskimos’ eyes are not really that much better, and it is only because of the importance of snow to their culture and daily life that so many terms for snow exist. Although it is possible to describe the various types of snow in English as well, English does not force the speaker to be very precise about the conditions of the snow. While the Eskimo language itself does not require one to look at snow completely differently, it leads the speaker to do so, and its vocabulary is best adapted for this approach.
Similarly, changing to an object-language, such as Smalltalk, does not immediately constitute object-oriented programming. While object-oriented programming is facilitated by the existence of OOP languages, it is possible to write OOP programs in regular C and non-OOP programs in Smalltalk. It is precisely the principles of OOP programming that transcend particular languages that we want to examine here.
The term paradigm, often associated with the strategically different programming approaches (such as the imperative-programming paradigm for Pascal and C, and the logical programming paradigm for ProLog) is highly appropriate to describe the new way of thought required for OOP. A paradigm is, formally, an example or a model, and this is precisely what OOP is - a model of the world, which enables us to view it as a set of objects with methods defined on them. [SEE THE OOP TECHNICAL SECTION]
A programmer in the imperative-programming languages has to consider all possible exigencies that may occur in a program. Because the instructions in a regular program are executed in order, a variety of cases must be considered even for a moderately sophisticated program, and writing code for complicated programs that may function in a non-linear manner is almost impossible. A program that proceeds from start to finish according to a precise set of instructions can not react adequately to a changing environment. That means that a programmer can have only a very limited control over the computer. This control is sufficient as long as everything proceeds in a set, sequential manner; however, since the program can not cope with certain out-of-sequence stimuli, the human-computer chain of command can easily break down. (Budd, pp. 120-122).
As noted earlier, OOP languages successfully solved this control dilemma by delegating the responsibility to individual objects. An OOP programmer views the world as a set of objects, each of which belongs to a particular class. All of these objects/ classes respond to messages which call on their methods. The decision-making is transferred from the programmer to the objects. There is no need to plan for every exigency, because each object will, presumably, know how to respond to any message sent to it.
The object-oriented programming paradigm is, consequently, more closely related to the real world than its imperative cousin. The closer relationship between the OOP paradigm and the real world is the reason why Smalltalk pioneer Alan Kay found it easier to teach Smalltalk to children than to experienced programmers (Kay, Early History of Smalltalk). OOP works similarly to the way people think, and it is only after getting used to other programming paradigms that mastering the OOP mode of thought requires a special effort.
More than just a couple of extra features added to existing languages, and probably less than a complete revolution in programming, the object-oriented paradigm does represent, in the words of Timothy Budd, a new way for programmers to "decompose problems and develop programming solutions".
References:
Timothy Budd, An Introduction to Object-Oriented Programming
(2nd ed.), Addison-Wesley, 1997
Geoffrey Pullum, The Great Eskimo Vocabulary Hoax, The University of Chicago Press, Chicago, 1991
Alan Kay, The Early History of Smalltalk, The Second ACM SIGPLAN History of Programming Languages Conference, March 1993