Classics of Software Engineering: “Design Patterns”

Classics of Software Engineering: “Design Patterns”

(One of a series of short reviews on books which have profoundly affected my own programming style, and which have made me a better Software Engineer)

Design Patterns
Gamma, Helm, Johnson, and Vlissides (The Gang of Four)
Addison-Wesley, 1995

This book was the one which finally unseated “Software Tools” as my own personal “Most Important Software Book I Ever Read.” It is THE modern classic of Object-Oriented Design.

It is really so famous at this point, so very well known, that any praise is likely to be met with the response, “Well, Duh.”

But the flip side of that is that if you haven’t yet read this book (perhaps because you’ve been on the Moon for the last few years and have never heard of it), you are at serious risk of being left behind. As early as 1996, I was already being asked in job interviews, “So, which Design Patterns do you prefer?” You’d better have an answer for that question.

So what’s all the fuss about? Design Patterns are simply time-tested organizations of objects which solve certain problems in certain ways. Just as you would pick a well-known sorting algorithm rather than trying to derive your own, you need to be familiar with ways of organizing objects which others have already found to be useful, and what their pluses and minuses are. Instead of code reuse, or algorithm reuse, we’re talking Design Reuse.

One of the most well-known examples of a Design Pattern is Model/View/Controller from Smalltalk-80, which is actually a higher-level Design Pattern built on several smaller ones. Consider the problem of a word processor which would like to support, as Microsoft Word does, being able to split a window into multiple panes so that the user can have several different views of the same word processing file. If the user types in one view, the changes must simultaneously affect the other views of that same document. Another example of the use of alternative views would be Microsoft Excel, which can represent the same data as a set of numbers or as one of a variety of graphs. How can we achieve this?

The Model/View/Controller pattern does this by separating these three aspects of the problem into separate objects. A Model object holds information about the document’s contents. It knows all about the contents of the document, what words and pictures are where, but doesn’t have any information about a specific view of the data. Instead, for each pane which corresponds to a view of the document, a View object is created, each of which has a reference to the same instance of the model object.

Views have all of the information that is specific to a given view: the zoom level of the view, its scroll position, etc. The Views are also registered as Observers of the document Model, which means that whenever a change is made to the document Model (for instance, when a character is inserted), this change is announced to all interested Observers (in this case, each of the Views). So, whenever the Model is changed, all of the Views get notified, and can update their displays.

Finally, a Controller object encapsulates the way that a View responds to user input. A view can change the way it responds to the user by swapping out the Controller object for a different one.

Design Patterns examines a relatively small number (20 or so) of fundamental patterns of objects IN DEPTH. For each pattern, the book looks at the overall key features, the implementation details (presented in both language-neutral UML and as actual sample code), the pros and cons of the pattern, a few examples of where it has already been used in the past, and how it is related to other similar patterns.

And don’t overlook the first section of the book. Many people do, simply because the larger second half, the catalog of patterns, is so outstanding, but the first section is filled with valuable information in its own right.

Classics of Software Engineering: “Software Tools”

(One of a series of short reviews on books which have profoundly affected my own programming style, and which have made me a better Software Engineer)

Software Tools
Brian W. Kernighan and P. J. Plaugher
Addison-Wesley Professional, 1976

When I was getting my B.S. in Computer Science the first time, 26 years ago, I was one of an exceedingly small number students at Georgia Tech who were using this brand-new tiny little operating system called UNIX, out of Bell Labs, which ran on DEC PDP-11 minicomputers (about as powerful as a 25 MHz 80386). Within this group, and all across the country, this book set off detonations like little neutron bombs. My old friend Michael “Bobby” Tague still calls it “The Most Important Software Book I Ever Read” — for my own part, it held that title until being unseated by “Design Patterns” in the mid-1990’s.

Continuously in print for 26 years, Software Tools teaches Structured Programming, example by glorious example. To quote the front cover:

“Good Programming is not learned from generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient, and reliable, by the application of common sense and good programming practices. Careful study and imitation of good programs leads to better writing.”

[That’s outstanding prose right there.]

The authors, who had already written an exceptional book, The Elements of Programming Style, reached in Software Tools a level of greatness which we students had not even previously conceived, much less experienced. They started out the book mired in the hell of FORTRAN, an environment which many programmers of that day, including even the bulk of the Computer Science Majors at Georgia Tech, were stuck in. They then said [paraphrasing now], “but why would we limit ourselves to that horrible programming environment as the primary tool we use in our everyday work, when we can easily improve it?” They described a new language, Ratfor (for Rational Fortran), which was little more than FORTRAN with C flow-of-control structures, improved comment support and C-like libraries of functions, and wrote a simple little preprocessor which converted Ratfor to FORTRAN. They then rewrote the Ratfor preprocessor in Ratfor, and ran it through the original FORTRAN version, and had bootstrapped themselves a programming environment that, while not UNIX, was (literally) an order of magnitude better than the one they had been stuck with previously.

And they shared their work with the world, by making all of the programs in the book available by nine-track tape, letting computer centers the world over bootstrap themselves into a dramatically better environment in a matter of hours.

In this slim volume, they consider the design of at least a dozen significant programs, designing and writing each while you watch. Topics such as top-down design, structured programming, egoless programming, pseudo-code, testing stubs, etc., were all taught by example. Most amazing was the collection of complete, significant, highly-readable programs that had been written by the end of the book, including a text editor, a word processor, and the Ratfor preprocessor itself. Topics such as sorting and parsing were covered as by-products along the way.

If you like to read books about programming, or want to be a better programmer, pick up this little book. Even if you don’t know FORTRAN, you’ll find the programs a breeze to read, as long as you know C, C++, or Java.