Design patterns - my friend and enemy!
I learned about design patterns in the formative phase of my life as a programmer. (Yes, that was long ago. I don't even remember, how long ago.) Since then, I've always been a great admirer of the concept. I like structured programming and I like algorithms and methodological approaches to coding, so this design patterns idea has always looked like a potentially very interesting topic to me.
Potentially; that's the word. Almost all of the books explaining design patterns were written with C++ (and later Java) programmers in mind. Well, I could swallow that. I know how to program in C, and I can read C++ and Java, so that was an obstacle that I could surmount with some work. A bigger problem were the UML diagrams explaining the patterns and code examples that had no connection to reality.
Problem one – UML diagrams. I don't do UML. I tried to learn it few times, but it doesn't speak to me, and for the sake of my sanity, I'm unable to remember what all those empty circles, full circles, and other line endings are supposed to mean. Each time I saw a UML diagram in a design patterns book, I lost my patience and walked away.
Finally, the time has come for some payback! This book contains no UML diagrams at all. What's more, this book contains only one diagram describing a state machine, but even this diagram uses no formal notation - it is just my ad hoc sketch. Take that, UML design pattern-lovers! (Not really. I have deep respect for people who fluently use UML.)
Rather than drawing all kinds of diagrams, here, I've tried to explain how each pattern works in simple words. I've also tried to find more-or-less appropriate and analogous examples from the real world. I can only hope you'll like my approach. If not, you can still read this book and use any website describing design patterns to look at pretty diagrams at the same time.
My second problem was with code examples. With some rare exceptions, design pattern books and websites all repeat examples that were cited in the original Gang of Four publication (more on that in Chapter 1, Introduction to patterns). Those examples are all terribly outdated and irrelevant to a Delphi programmer. Which one of you needs to know how to use the Decorator pattern to apply scroll bars to a text view? There are many other uses for this pattern in the modern world – see the Chapter 5, Adapter, Proxy, Decorator, and Facade and consider the Adapter, Proxy, Decorator, and Facade patterns as examples.
Because of my deeply rooted dislike of such examples, I tried to stay away from them as much as possible. There are still examples that draw shapes onscreen in this book – simply because some patterns were designed specifically with such problems in mind – but the big majority of examples try to be closer to the experience of an average Delphi programmer. I also added few standalone sections on Delphi-specific language enhancements that may not be known to a fresh Delphi programmer, or to a Pascal programmer that doesn't speak Delphi. Look for them in headings starting with Delphi idioms.
Did I succeed in writing a easier to understand and more practical design pattern book? Only you can tell. (And please, do tell! I'll be glad to receive any feedback – positive or negative.) I can only say that this book has helped me – now I finally understand what this "design pattern" stuff is all about.
