by Conrad Weisert
© 2004 Information Disciplines, Inc., Chicago
IDI's Issue of the Month, September, 2004
NOTE: This document may be circulated or quoted from freely, as long as the copyright notice is included.
The literature of object-oriented programming (OOP) is full of advice to the class designer on how to thwart cheating by class users (most application programmers). I recently updated1 an old article in order to respond to a trade-journal article about such cheating.
I later heard from a reader who pointed out a way a malicious client
programmer could still defeat the remedy I had suggested. He pointed out
that a C++ programmer could still gain access to a class's
members by coding:
#define class struct #define private public #define protected public #include <classdefn.h>That's diabolical. The paranoid class designer can thwart that mischievous user-programmer with equally diabolical defenses but why bother? Class designers and client programmers are not natural adversaries trying to outsmart each other.
We have to concede that application programmers haven't always been cooperative in respecting conventions of good practice. For example:
The result, more often than not, inhibited future change. Updating the operating system version or switching to a new compiler could render a critical application inoperable. In extreme cases, an organization might be forced to run a critical mainframe application for years in stand-alone mode under an obsolete O.S., interfering with the workflow of all other users.
But that was then and this is now. Those practices have been so thoroughly discredited that few modern programmers, if any, would boast of such misguided cleverness today.
The access specifiers3 in object-oriented languages serve to clarify the class designer's intent about how the class is to be used. Automated enforcement by the compiler is an advance over PL/I and Pascal, but in a sane environment it's more likely to catch accidental or thoughtless misuse than deliberate cheating.
The most effective defense against misuse, however, isn't automated at all. If a programmer is deliberately violating standards, he or she needs to be coached to understand the purpose of the standards and the benefits of complying. Abandoning that programmer to trial-and-error hacking only invites more costly violations.
The most effective defense against misguided or malicious violations is code inspection, a key element of an enlightened Quality Assurance function. A program that attempts blatant subversion of private member accessibility should be promptly caught can corrected by peer review.
Quality Assurance or earlier "walkthrough" review will also catch all sorts of equally harmful shortcomings that elude attempts at automated enforcement. See, for example, Atrocious Programming Thrives.
In most organizations, the whole professional staff is on the same side. In-house training materials and methodology documentation should convey the purpose and benefits of good practice to new staff members. Anyone who deliberately violates standards and who resists coaching and correction, may be asked to seek employment elsewhere. This is a management issue, not a programming-language issue.
private, protected, public, package etc.
Return to Management articles
IDI Home Page
Last updated 10 September 2004