Most of the computer-related books on my shelves fall into one of three categories: those that describe how to do particular things, those that discuss why things ought to be done a particular way, and those that can be summed up as saying, "Gosh, computers are really cool!"
Tom Armstrong's The Active Template Library: A Developer's Guide is a perfect example of the first type. The Active Template Library (ATL) is Microsoft's most recent attempt to make its COM object model more accessible. The library consists of a set of C++ macros and classes that encapsulate and partially automate basic COM operations. Both in spirit and in implementation, the ATL is similar to the Microsoft Foundation Classes (MFC), which serve the same purpose for Windows GUI programming. Instead of buttons, sliders, and message boxes, however, the ATL encapsulates reference counting, dispatch interfaces, and threading.
Armstrong's book starts with a short description of C++ templates, and then devotes a little over 60 pages to a discussion of what COM does and how it works. These two chapters are succinct, informative, and easy to follow. The third chapter, which introduces the ATL, is harder going, primarily because the ATL is a complex library. Armstrong does his best, and provides some helpful diagrams showing the derivations and relationships between various ATL classes. However, I think that the chapter would benefit from more discussion of the problems that various features are trying to solve, and from a slower pace in general.
Each of the remaining eight chapters dissects one of the ATL's key features -- the use of IDL, containment and aggregation, automation, and so on. Each chapter begins by explaining why the particular feature exists, then walks the reader through an example. (The source for these examples is available at the author's web site.) The two appendices discuss native support for COM in Microsoft's Visual C++, and the features that COM+ (COM's successor) is supposed to have.
Overall, I found The Active Template Library very useful: I'm trying to get up to speed with COM for a new project, and have been disappointed by how difficult most older books make it. However, the book was weakened by a lot of irritating typographical errors, both in the text ("pawwing" instead of "passing," for example, and some bad line splices), and, more importantly, in the code listings. While I hope that a second edition appears soon to fix these, the book is still the most readable technical introduction to the ATL I've come across.
James Coplien's Multi-Paradigm DESIGN for C++ (yes, that's really how the title is capitalized) lives on the other tail of the bell curve for serious computing books. Coplien is best known for his Advanced C++, a widely read book on how to do complex things in a language which is fairly complex in its own right. In this new book, Coplien moves beyond smart pointers, the letter/envelope-design pattern, and the pitfalls of operator overloading to look at when and why you should use inheritance, templatization, function overloading, and the various other abstraction mechanisms that C++ now provides.
Or at least I think that's what he's doing, but to be honest, I'm not really sure. Multi-Paradigm DESIGN for C++ is written at such a high level of abstraction that I often couldn't tell exactly what point the author was trying to make. Occasionally, I would be able to seize on something concrete, such as the parallels between templatization, which give compile-time polymorphism, and the inheritance of virtual methods, which give run-time polymorphism. Most of the time, though, I felt like I was in the presence of someone who'd had a glimpse of something fundamental, but whose every attempt to put it into words ended up sounding banal. As depressing as it may be, I think I'm simply not smart enough, or experienced enough, to understand what Coplien is trying to say.
On the bright side, I'm pretty sure I understood Carlton Egremont III's Mr. Bunny's Guide to ActiveX. This book belongs in the "computers are cool" category -- or more exactly, in the "really geeky humor" category. For example:
The familiar dot "." symbol from Internet addresses is used in this book to terminate sentences.
Well, okay, it's funnier in the book. So is the side view of a dialog, and (my favorite) the Visual Basic 5.0 splash screen on page 40, which looks suspiciously like a memory-access violation message box. Yes, the book runs out of steam about half-way through, but it's still very funny, and let's face it, where else are you going to read something like:
...you form windows using forms. A form is a window that you form. At first forms are unformed. You must form your forms using the former designer (formerly the former). In the form former, an unformed form forms a uniform formation of dots....
-- G.V.W.
There is a quiet revolution under way in how we design object-oriented software. Reusable object patterns, first popularized in the book Design Patterns, by Erich Gamma et al. (Addison-Wesley, 1995) are changing the way we think about, talk about, and design object-oriented systems. Design patterns describe recurring problems and their core solutions in such a way that the solutions are reusable in different problem contexts. Design Patterns (also called the Gang-of-Four book, or just GoF) has become required reading for object-oriented designers, and has spawned its own virtual community, complete with an annual conference called PLoP attended by OO heavyweights, including the likes of Grady Booch, Frank Buschmann, and the GoF authors themselves.
All this attention has made GoF the benchmark against which other pattern-oriented publications are judged. GoF, itself, has been criticized for being difficult to understand. Since design patterns incorporate both the problem and the solution, you really need an understanding of their problem context for them to make much sense. Good examples would really be helpful here, but GoF is a bit thin on examples. The examples it does provide are snippets of either C++ or Smalltalk, and neither of these is of much help to Java programmers.
This is where Patterns in Java, by Mark Grand, really fills a void. Grand adopts the format of GoF and restates its patterns using Java. PiJ organizes 41 design patterns into six categories. (In contrast, GoF contains 23 patterns grouped into three categories.) The extra patterns described by Grand are representative of the many advances that have occurred in the three years since GoF was first published. Grand also presents a group of five "fundamental" design patterns. These are object-oriented techniques described in the subtext of GoF, but not explicitly presented as patterns. Grand also seizes an opportunity to describe seven concurrency patterns that are conspicuously missing in GoF and acknowledged as such by its authors.
As you begin reading PiJ, you get the sense that one of Grand's goals is to make patterns more accessible to the everyday OO programmer. In Chapter 1, he presents a simple introduction to patterns, where he describes the nine topics that form the body of each pattern. This is a welcome simplification of the 12-topic structure used in GoF. In Chapter 2, Grand presents an overview of the Unified Modelling Language (UML) that is used for diagramming in PiJ. While UML is richer and more expressive than the notation used in GoF, I must confess that I prefer the simplicity of the GoF notation (for the description of patterns, at least). The cardinality, type specification, and scoping expressed in PiJ's UML diagrams sometimes convey more detail than is necessary and obscure the simplicity of the patterns.
In Chapter 3, Grand makes a concession to methodology, by presenting an overview of the software development process. This is essentially a 10-page introduction to UML "use cases" and the requirements for specification, analysis, and design, which form the framework of every software development project. You've probably read this kind of thing before, but the review still gets you in the mood for what follows.
Each of the remaining six chapters in PiJ describes a collection of related patterns. Chapter 4, "Fundamental Design Patterns," describes five basic patterns that form the building blocks for other patterns. Chapter 5, "Creational Patterns," describes six patterns for implementing dynamic, decision-driven object creation mechanisms. Chapter 6, "Partitioning Patterns," describes three patterns that provide guidance in how to partition complex functionality into multiple, loosely coupled objects. Chapter 7, "Structural Patterns," presents nine patterns for managing complex arrangements of objects at run time. Chapter 8, "Behavioral Patterns," describes 11 patterns that organize and combine the behavior of objects to promote reuse. Chapter 9, "Concurrency Patterns," presents seven patterns for coordinating concurrent operations, like controlling access to shared resources, and ordering the sequence of execution.
There is considerable debate within the pattern community as to what constitutes a proper definition of "design pattern." GoF's stature within the pattern community clearly makes it the reference definition for design pattern. But with each new pattern publication, the definition of design pattern seems to broaden. For example, some will argue that Grand's interface pattern is not a pattern at all, but is instead simply a feature of the Java language. In my opinion, this is a red herring issue. The real benefits that PiJ, GoF, and other pattern catalogs offer is that they convey knowledge about object-oriented problems and solutions. By defining a standard format, these publications make this knowledge widely accessible and reusable, which has long been the Holy Grail of object-oriented architecture. So, whether PiJ's patterns conform to GoF's definition of design pattern, by applying PiJ's techniques, your Java projects will benefit from improvements in scalability, reusability, and maintainability. PiJ is well written and reasonably easy to understand. It's also one of the few pattern publications that is truly Java centric. If for no other reason than this, Patterns in Java deserves two thumbs up.
-- S.C.
DDJ