Chapter 1: Why OO Programming--Some Parallels with Things at Large

What is object-oriented programming?

Although the answer to this question will reveal itself as you work your way through this book, at this juncture it might be useful to draw parallels between object-oriented programming (OO) and the world around us. You are unlikely to dispute the assertion that during the last half century the following facts about societies have become amply clear: Societies function best when centralized control is kept to a minimum; when the intelligence needed for the smooth functioning of a society is as distributed as possible; when each person is sufficiently smart to know for himself or herself how to make sense of the various norms and mores of the society for the common good; and when the higher-level organizational structures, often organized in the form of hierarchies, facilitate the propagation of society-nurturing messages up and down the hierarchies.

Large object-oriented programs are no different. The idea is to think of large software (sometimes consisting of millions of lines of code) as consisting of a society of objects: objects that possess sufficient intelligence to interpret messages received from other objects and to then respond with appropriate behavior; objects that inherit properties and behaviors from higher-level objects and permit lower-level objects to inherit properties and behaviors from them; and so on. Just as decentralization of human organizations makes it easier to extend and maintain the various societal structures (because the intelligence needed for such maintenance and extension resides locally in the structures), a decentralized organization of software allows it to be extended and maintained more easily. If as a programmer you are not happy with the objects supplied to you by a software vendor, in most cases you'd be able to extend those objects with relative ease and customize them to your particular needs. And if any problems developed in one of the components of a large decentralized organization of objects, your troubleshooting would be easier because of its localized nature—this would apply as much to a society of people as it would to a society of software objects.

A discourse concerning societies is made more efficient if we group together all those objects that share common characteristics. We could then refer to such groups as classes. For example, all people engaged in the delivery of healthcare have to have certain common professional attributes. We could say that these common attributes define the class health-care professional. All medical doctors—the class medical doctor being a subclass of the class health-care professional—must possess the attributes of all health-care professionals; they must also possess additional attributes by way of specialized education and training.

This analogy carries over directly to software design based on objects. All objects that possess the same attributes and exhibit the same behaviors are grouped into a single class. In fact, we first define a class and then create individual objects by a process known as instantiating a class. All objects that possess the attributes and behaviors of a previously defined class, possessing at the same time additional more-specialized attributes and behaviors, are represented as a subclass of the previously defined class.