| |
A Common Misconception about Object-Oriented Programming
By V. Berba Velasco Jr., Ph.D.
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.
About the Author
V. Berba Velasco Jr., Ph.D. is a senior electrical and software engineer at Cellular Technology Ltd (http://www.immunospot.com, http://www.elispot-analyzers.de, http://www.elispot.cn, http://www.elispot.co.jp), a biotech company that provides ELISPOT expertise and cryopreserved peripheral blood mononuclear cells (PBMCs).
Article Source: http://www.simplysearch4it.com/article/32460.html
| If you wish to add the above article to your website or newsletters then please include the "Article Source: http://www.simplysearch4it.com/article/32460.html" as shown above and make it hyperlinked. |
| Some other articles by V. Berba Velasco Jr., Ph.D. | Using 'Get' and 'Set' Might Be Something You'll Regret
It's an all-too-common pitfall. Programmers who attempt to write object-oriented code decide to make all of their data variables private, while creating ...
People Who Think They're Right
A few months ago, I had a conversation with a churchgoer who complained about religious intolerance. He said (and I paraphrase), "When it comes to religious beliefs, I really don't like people who think ...
Listening Techniques For More Effective Meetings, Part II
In Part I of this article, we discussed the importance of active listening, and how it is important for smooth ...
Listening Techniques For More Effective Meetings, Part I
We all know what it’s like when a meeting doesn’t go smoothly. Discussions get derailed, tempers start to fray, and things are seldom resolved to everyone’s satisfaction. In such ...
Don't Forget the Internal Software Documentation
Internal documentation. It's one of the most frequent casualties in software development.
It's not hard to see why. For most companies, time is money, and they frequently find themselves ...
A Time-Saving Programming Tactic That Doesn't Work
Let's say that you have a software project that's under severe time pressure. Let's say that this deadline is so tight that you already know it will involve many late nights of ...
|
|
| |
|
