I've seen it time and again. A computer programmer proudly proclaims, “Yeah, my code is object-oriented. See? My data members are all private, and they can only be reached through public member functions. That's what being object-oriented is all about.” I've even heard this kind of drivel come from the mouths of Computer Science graduates—people who have presumably studied object-orientation in the classroom, or who would have had ample opportunity to educate themselves.



Scholars may quibble about the fine points of object orientation; however, one thing is for certain: merely having private data and public functions does not constitute a proper object-oriented design. Rather, proper object orientation entails much more.

One of the most basic elements is information hiding. This means that objects should only present the information that needs to be seen; that is, it should present a coherent and well-selected interface of functions—one that does not betray the data contents and internal workings of the class. In other words, the manner in which the functions are implemented remains hidden from the user, allowing the developer to alter the implementation as needed. (Some also refer to this as “encapsulation,” whereas others state that encapsulation is merely a means for hiding information. I lean toward the latter view; however, for the purposes of this article, this distinction is unimportant. Suffice to say that information hiding is a key element of object-oriented design.)

When a programmer declares that his code is object-oriented by virtue of having private data and public functions, he is placing the cart before the proverbial horse. Using private data and public functions is merely a means of achieving information hiding; it is not a goal in itself. For example, consider a design in which every single data member has corresponding “get” and “set” accessors (e.g. a data member “x” would have matching “getx()” and “setx()” functions). In this example, information is poorly hidden, since the choice of functions (indeed, their very names!) betrays the manner in which the data has been implemented.

Inheritance is another key element; that is, specific classes are to be derived from more general ones. Inheritance is a means of implementing abstraction; that is, it allows the user to identify objects with common characteristics, and which should therefore use common code (or at the very least, common interfaces). This is part and parcel of thinking in terms of objects, as opposed to thinking primarily in terms of functions and procedures.

Yet another key characteristic is polymorphism, which allows a descendant object to override its parent's member functions. With polymorphism, a descendent object does not have to respond to a message exactly as its ancestor does; rather, it can have its own implementation. Note that the descendant objects do not have to override these functions; rather, they should simply be allowed to do so, as needed.

Much more could be said about the nature of object orientation; indeed, scholars often contend over its precise definition and its principal ideas. Whatever the case though, the point remains: merely keeping private data and a set of public functions does not constitute an object-oriented design—not in any meaningful sense of the term.