The Wiley Technology Publishing group typically has books that cover the more specialized parts of the programming puzzle. Visual Basic Design Patterns is no exception.
In fact, unless you're an experienced programmer, you might not have a complete idea about what a design pattern is. Here's the book definition: "Software patterns are reusable solutions to recurring problems you encounter during software development." They're like design objects, then. You can take advantage of the work of previous designers in figuring out how to do things right.
Possibly the main thing that some readers might not like about this book is that it's really meant for "experienced programmers". In the introduction, the authors state the case for the book quite plainly, "The value of this book is that it gives experienced programmers a common vocabulary to discuss patterns." It seemed to me that the authors actually are writing mainly for people who already know quite a lot about it, but just need that "common vocabulary" to help them communicate.
There's actually some history to back up my opinion here.
Back in the 1990's, respected and intelligent scholars were almost at each other's throats over - if you can believe it - questions like whether to draw a "cloud" or a "rectangle" to indicate a class in object modeling diagrams. The academic warfare and bickering went on for years and it only settled down because three of the most respected scholars decided to hammer out a version they could all support in private meetings away from the battleground. Then they made their decision the standard by sheer force of their combined influence. These were the "Three Amigos" who invented UML, the Unified Modeling Language, and later made a bit of money founding and then selling Rational Software.
This might be why the book starts out with a fast, but intense and detailed chapter about UML and why UML is the foundation technology for the rest of the book. The authors are clearly waaaay into this subject. It just stands to reason that the almost mythic story of how the Three Amigos brought peace to a troubled land (and just a little gold to their own pockets) might be a guiding light for them.
"Visual Basic" in the title suggests that this is a book about Visual Basic. It's not. It's a book about software design. Visual Basic is used whenever code examples are needed but the goal of this book is not to teach VB. The authors (correctly, in my opinion) simply decided that VB is the best way to illustrate their design patterns with code.
The main focus of the book is a series of descriptions of the accepted ways that common software problems should be solved. Problems like ...
- How to create software objects in code. How to code an "object factory" or and "object pool" for example.
- How to structure code for particular goals such as adding new classes at runtime.
- How to code software that must execute concurrently.
It's not like these patterns were previously unknown. In fact, the authors cite a previous source for most of the patterns in the book. But, as promised in the introduction, they have a well structured and detailed explanation - you could call it a "writing design pattern" - for every design pattern in the book. This "common vocabulary" consists of these sections:
- Code Examples
- Related Patterns
All in all, this is an excellent book ... for the right reader. Fellow "design pattern" fans of the world will absolutely love it.
Also, if you have ever wanted to have a more practical and grounded introduction to UML, then this could be exactly what you're looking for. The authors recommend the technique of reading about a pattern and skipping back to the first chapter to figure out what all the UML diagrams mean. I tried it. It works.
And, of course, the design patterns themselves make the book an absolute encyclopedia of software architecture. Let's put this one in perspective. Consultants will tell you that there is very good evidence that more than half of all software projects are failures. The losses run into the billions every year. A lot of these failures happen simply because designers and programmers keep trying to reinvent the same wheel over and over and over. And sometimes, they don't happen to invent the best design. (Duh!!)