"General purpose" design patterns include the Null Object, the Manager, and the Product Trader patterns, and another section improves on the Visitor pattern. These patterns allow classes to borrow the methods of other classes without using inheritance. Some of the most challenging patterns in this book are good for distributed processing, including Acceptor and Connector and Object Recovery. Basic research in object-oriented design (OOD) is apparent in the Serializer pattern, which implements persistence for objects, another unusually difficult aspect of object design to get right. Another useful section introduces "domain specific" patterns--or patterns that solve particular real-world problems--with several patterns for transportation systems and fire alarms.
The book closes with more esoteric explorations of patterns for developers, including patterns for effectively designing in teams and using software testing patterns. Judging from the rich selection of the ordinary and the bizarre, there seems to be no end in sight for the business of discovering patterns. For those interested in expanding their collection of patterns, this volume offers a fascinating array of new specimens.
A software design pattern is a solution to a particular computing problem. Each pattern has, in general, four parts: the pattern name, the problem to be solved, the solution provided by the pattern, and the trade-offs. Familiarity with patterns makes software design "easier," because large concepts can be dealt with using the patterns, rather than reinventing the wheel in each program.
A recent presentation on patterns comes via Addison-Wesley's Corporate & Professional imprint. The production quality of Pattern Languages Of Program Design 3, edited by Robert Martin, Dirk Riehle, and Frank Buschmann, is excellent, and the binding easily endured the two months I spent reviewing the text. Most importantly, because you'll find yourself reading the text with pen in hand, the pages are of sufficient thickness to take marginalia and highlighting without bleed-through. This is a nice book...
PLoPD3 is no novel. It is a difficult book to read, for you are reading the documentation and code of other programs. It is not a book to skim once and shelve. Rather, I suggest you read a paper, try to imagine how you would use the pattern, and try some of the sample code. Try to imagine some of the problems that will occur if you use the pattern. With this admittedly conservative approach, the book will take a few months to read. --Peter N. Roth, Dr. Dobb's Journal -- Dr. Dobb's Journal