Distrust of clients by class designers is destructive and unnecessary . . .

Are application programmers cheaters?

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.

Adversary-Oriented Design

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 private 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.

Programmers have been known to cheat

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.

Enforcing the rules

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.


1 -- See the sidebar near the bottom of A Mild Dissent from a Growing Practice in C++.
2 -- Character data was unsupported in early Fortran.
3 --
private, protected, public, package etc.

Return to Management articles
IDI Home Page

Last updated 10 September 2004