As I tried to make clear in this post, I’m not happy relying on a rule or principle as a reason for preferring one coding practice over another; I want to understand why this principle is useful, and in particular what actual, concrete problems are avoided by following the principle. (To me, just to cite one example, “increased coupling” is not a concrete problem; “greater likelihood that a future change will cause a feature to stop working” is.) Even the best design principles should not be treated as dogma. If we adhere to them without understanding why, we risk going astray.
Recently, I read a number of blog posts arguing against “utility classes”, classes that consist of nothing but static methods that aren’t meant to be instantiated. Some of these posts did mention concrete problems that could be caused by utility classes, in some cases. Two, however, argued only that they were bad because they weren’t object-oriented enough. For example, one criticized a code snippet that looked clean because it was “procedural, not object-oriented”, without giving any other reasons to avoid it, as if simply calling it “procedural” should have convinced everybody that this should be avoided like the plague. Both of these posts used the most innocuous examples of utility classes—examples that would not cause any maintenance problems that I can see—and one of them proposed some “solutions” to make things more “object-oriented” that I believe could have made programs worse, forcing code to be more complicated with no benefit. But I’m sure the authors of both these posts thought they were helping programmers improve their programs.
I can understand this because I’ve been there. In the mid-1970s, I was working as a part-time COBOL programmer for the school district while I was in high school. This was before anybody had heard of object-oriented programming. However, I was greatly influenced by reading Dijkstra’s “Go To Statement Considered Harmful” letter. Prior to that, my code looked like everybody else’s around me—GOTOs occurring wherever we felt like it, and branching to any old place. Reading this letter was an eye-opener for me; it made a lot of sense, that code with a better structure was going to be easier to work with.
Unfortunately, I made the mistake of thinking it was all about purging GOTOs, rather than the structure. This isn’t a problem in a language that has the control structures needed to avoid GOTOs effectively. I cannot remember the last time I used a goto in production code. COBOL, however, did not have those control structures at that time. It did not have loop statements; you could say something like PERFORM SomeParagraph UNTIL Index >= 10, but the looped paragraph had to be out of line from the rest of the code, and while it’s a good idea to extract smaller subroutines out of larger subroutines, it’s not so good when the subroutine and its caller work with the same variables (COBOL did not have procedure parameters or local variables), which means you have to jump back and forth to figure out what’s going on. COBOL also didn’t have any kind of IF..ENDIF or BEGIN..END or {..} scoping structure, so that a code sequence like
IF HOURS > 0 THEN
COMPUTE PAY = HOURS * HOURLY-PAY
IF HOURS > 40 THEN
COMPUTE OVERTIME = (HOURS - 40) * HOURLY-PAY / 2
ADD OVERTIME TO PAY
[END-IF]
ADD PAY TO TOTAL-OUTLAYS
[END-IF]
could not be written, because there was no way to put a nested IF in the middle of the THEN or ELSE sequence; the ADD PAY TO TOTAL-OUTLAYS would only have been executed if HOURS > 40. (Better control structures were added to COBOL in 1985, including the END-IF keyword; the END-IFs in the above example are just there to show what I would have liked to write.)
Since I was determined to purge the harmful GOTOs from my code, though, I did what was necessary to work around COBOL’s deficiencies, mostly by adding lots of PERFORMs. I even got a little depressed one day when I found that I could not excise the last GOTO, in a case involving one statement (I think it was SORT, but I don’t remember) where the rules of the language required the code to be written in a way that there had to be a GOTO to an exit paragraph. I thought it was a “blow to structured programming” that the GOTO couldn’t be eliminated in that one case.
After doing this for about a year, it dawned on me that the code I was writing was almost as convoluted and hard to follow as the spaghetti-code style I had left behind. OK, that may be an exaggeration. But it certainly proved to be more convoluted than necessary. Somehow, I figured out that it was better, in this language, to go ahead and use GOTOs but in a disciplined, structured fashion, and I became willing to write code like
MOVE 1 to I.
BEGIN-EMPLOYEE-LOOP.
IF I > TOTAL-EMPLOYEES GOTO END-EMPLOYEE-LOOP.
IF EMPLOYEE-SALARY(I) > 200000 THEN
ADD 1 TO OP-INDEX
MOVE EMPLOYEE-ID(I) TO OVERPAID-EMPLOYEES(OP-INDEX).
ADD 1 TO I.
GOTO BEGIN-EMPLOYEE-LOOP.
END-EMPLOYEE-LOOP.
I don’t remember if I indented things exactly this way, but the point is that by picking appropriate names, using GOTOs only in certain patterns like this loop pattern, and indenting, the structure would be clear and the code would be readable, and the GOTOs would be used in a way that was not harmful.
This lesson—the importance of remembering the real goal that I’m trying to accomplish rather than simply following a dogma—is an important lesson that has stayed with me through my career, and I feel very fortunate to have learned it so early. Developing a thorough understanding of the benefits of following good design principles, the cases where the benefits don’t accrue, and the tradeoffs involved in following them, leads to much better-designed software than imitating George Orwell’s sheep and chanting “Object-oriented good, procedural bad” over and over.
