Design Patterns in C#
This is the last weblog entry that concerns my research for Charlie. Next up, I will talk about Charlie’s final architecture and its first classes.
In the previous weblog entry I described just how great is the book, Head First Design Patterns. After reading it I was so inspired that I promptly purchased Design Patterns in C#, hoping to round out my knowledge of patterns. If the Head First Design Patterns book is one of the best programming books ever written, Design Patterns in C# is one of the worst. It is truly, truly awful.
The first line of the book reads, “This book is for developers who know C# and want to improve their skills as designers.” Then, after having established that the book is for developers who already know C#, the first chapter says, “it’s worthwhile ensuring that you are comfortable with how C# features work,” and launches into a needless review of C#. That would be excusable if it were not the worst review imaginable. It is so poorly written that I wondered whether the author actually understands C# himself. In introducing interfaces, the first line reads, “C# interfaces can specify that implementers must provide indexers or properties.” If that is a good way of introducing interfaces to someone who may be fuzzy on the concept, I will sell my soul on eBay. The author also tries to explain the concept of delegates. While I have never seen a good explanation of delegates, this must be close to the worst attempted explanation.
The first line introducing design patterns reads, “A design pattern is a pattern—a way of pursuing an intent—that uses classes and their methods in an object-oriented language.” If you think the author then expands on that nebulous description, you’d be wrong. That description is provided in the introduction, before the first chapter provides the needless review of C#. The second chapter then delves right into the Adapter pattern. No more explanation of design patterns is provided. And, unless I mistaken, that description is rather inaccurate.
Can I pick on the analogies too? Please let me.
To explain the Decorator pattern, the wonderful Head First Design Patterns book chooses the analogy of ordering coffee. A customer might order a coffee. Or the customer might order a coffee with cream. Or the customer might order a coffee with cream and sugar. Or the customer might order a coffee with cream and sugar and a cinnamon stick. Now, even if you don’t know what the Decorator pattern is, the progressively “added to” nature of this short description would give you a clue to what the Decorator pattern does.
To explain the Decorator pattern, the horrible Design Patterns in C# book chooses the example of streamwriters. Never mind that a developer who is learning design patterns is surely unfamiliar with the concept of streamwriters, even those who do know what a streamwriter is may have a hard time visualising how one stream can wrap another. I know it’s a common analogy, but it’s a dumb one.
The ongoing analogy in Head First Design Patterns is that of a diner. So we have coffee to illustrate the Decorator pattern, pizza to illustrate the Factory pattern, and a menu to illustrate the Iterator pattern. Every developer in the world, no matter how inexperienced, knows about coffee, pizza, and menus. A good choice for analogies then, wouldn’t you say?
The ongoing analogy in Design Patterns in C# is that of a company that produces rockets. For some reason, the company is named Oozinoz. I have flipped open to a random diagram using this analogy. It shows a Firework inheriting from a Rocket, and then asks, “What’s wrong with this picture?” Well, given that I’ve never gotten too close to a rocket or a firework, I can’t exactly say. (In Australia, we don’t mess around with fireworks. The only person I knew who did, put the thing in his pants pocket, and now he is called “char bar.” True story.) On another page, we see a diagram with a ShowBallistics class (no idea what that is), a PlotPanel class (nope, no idea), and a TrackBar (dunno that one, either). I think someone needs to tell the author that an analogy needs to be both simpler and more familiar than the concept it is trying to represent.
Figuring that the design patterns themselves might be the saving grace of the book, I attempted to look up how to apply the Model-View-Controller pattern to a .NET application. Nope, Design Patterns in C# made only passing mention to this oh-so-common pattern. So I went back to the Head First Design Patterns book. Sure enough, it provided good coverage of the MVC pattern using the analogy of an MP3 player. Even more impressive, the book discusses how this pattern is altered to work in the context of a web-based application, where it is known simply as Model 2 in the Java world.
Okay, I have provided a harsh review of this book. This is partly because I feel cheated out of $60. It is also partly to ensure that any C# developer who wants to learn design patterns (and who somehow stumbles upon this weblog entry) will give this book a miss, even if it is the only book with both Design Patterns and C# in its title. If you’re a C# developer and you want to learn about design patterns, then Head First Design Patterns is the book to buy.
by Alister Jones | Next up: The Architecture - Part 2 →
----
Post a Comment