  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. And you can get it here: urlLink http://www.amazon.com/exec/obidos/ASIN/0201633612/ 
