Pattern Code Bloat
-
Around 1982 we obtained a very early C++ compiler (not yet released) that compiled to plain C, which could be used as input to any K&R C compiler to generate binary code. As senior students, we eagerly read this intermediate C code to see how subclasses and inheritance and abstract classes and initializers and whaterver other OO concept was implemented. At summer time, I was an intern with a company making both computers and software for it, and I got insight in a fullscale, commercial OS, written in a low level language (more or less a set of macros on top of the assembly language) in the early 1970s. To my surprise I found lots of source code in the OS that very much resembled the C code created by the C++ compiler. Lots of OO concepts had been realized by hand coding in a near-assembly language. When I pointed this out to the OS developers, they gave me a blank stare: OO was a completely unknown concept to them. They had all the good reasons for coding it the way they did, using the same arguments as the OO guys, in a somewhat different vocabulary. So I learned that OO concepts came neither with C++, Simula or Smalltalk - they just formalized a language syntax for concepts that had been in use for years. Patters are similar. I met them after a number of years as a software developer, and my reaction was "Yes? Sure that is good way of structuring the code; we have always done it that way..." Of course there were rule thumpers who where nitpicking some details that diverged from some academic description of a given pattern. In a couple of cases, the details could easily be adjusted to make those guys happy; it never changed the real pattern. Just like the OS guys did OO programming without knowing it, lots of developers use code patterns "by instinct", without ever looking up its index in some academic dissertation. They use it without being tied on hands and feet to a set of academic absolutes, but adapt the basic principles to a real world production environment. Which is how it ought to be, in my opinion.
My experience with both object oriented programming and design patterns mirrors yours, and probably nearly every one of our colleagues who started in the 1970's. Along those same lines, I was once asked to fix a program that had been written by a brand new graduate, so new that the ink wasn't dry on his Computer Science diploma. It was modularized, as was the fashion of the day, in the extreme. If even a single statement appeared in two or more places in the program, it was implemented as a function. After studying it for a few hours, I scrapped the entire program, and rewrote it from scratch. With a total expenditure of about two days, I had a completely rewritten, tested replacement for the program. While it was modular, it wasn't slavishly so; there were places here and there where the same statement appeared in two or more places. So what? In the grand scheme of things, that might have made toe object code a hundred bytes bigger, which didn't matter, even then, when we measured programs' memory consumption in kilobytes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting