About Design Patterns
Christopher posted about "Design Patterns Explained". Having been down that road myself (and so has any developer that learned this stuff at one time or another) I can only congratulate you on a good decision. Some developers just don't have the will power (not that it's so hard, they are just lazy) or the motivation to open their mind to broader subjects, and would rather stay in their little cube, programming their little tasks. Taking design patterns as something to learn is one of the steps I will never regret learning. It just stays with you.
To me, learning design patterns was like discovering a parallel dimension of the world we live in. gradually, I started seeing almost everything from this point of view. The view from there was that everything, somehow, was part of a grand design pattern. The way you would read you mail was a pattern, the way you build a house is a pattern (There's a great book about it, It slips my mind though), and of course, the way you build software is a pattern. Its pattern madness really…
One of the things the book I read said was that once you read it, you’ll discover that you’ve been using quite a lot of patterns for a long time, without even knowing it. The book was right on the money – I found exactly that. What has changed from that moment on, was that I tried to stay true to the design, meaning any coding changes to interfaces and such were thought of twice before being done. I loved every minute of it and I can safely say that I also used it too much. Waaay too much. That’s a common problem - many people, once they learn about design patterns, feel the urge to use them all the time, even when it is too cumbersome and just complicates things. If you’re going to build a single-Form application to manipulate application settings in the registry - don’t start planning for a Model-View-Controller pattern – that is plain overkill. If you’re going to display a simple data grid and you need to develop this for the next day – patterns don’t fit here. Go for the brute force approach on this one.
Patterns need to be used, although not sparingly, with thought. Like any good thing – too much will hurt you (and your boss). On the other hand, I’ll tell you that while reading the GOF design patterns book, I discovered many wonderful things. That book also comes with examples of known commercial products that use the design patterns mentioned in it – which makes the light bulbs go off in your head – “Oh! So that’s how they did it!”. Really cool stuff.
It also helps you a lot when you start planning and building some serious medium-large scale applications. These are not simple things. Building them like you built the smaller applications you’ve made so far will get you stuck pretty quickly – either because of performance issues, or you just wouldn’t know how to get a specific feature done (AKA “How the hell do they expect me to accomplish that??”) – that’s the beauty of patterns – it is very probable , very, that someone has done the thinking for you and solved a similar problem way before you stumbled on to the one you’re facing. The design pattern is actually a record of what design guidelines that person took in order to solve this problem. Use this. Don’t re-invent the wheel every time. That’s the philosophy behind design patterns. That’s the philosophy of the “lazy programmer” too..
I’ve read another book titled “Anti Patterns”. It depicts several so-called problematic patterns that you might be doing. These can range from “stale code” to “company politics”. I don’t know just how useful this book is, as it does not really define patterns to be used, but rather – patterns to be avoided of. Of that – it does a fair job, but I wouldn’t recommend it unless you have some spare cash lying around. It seems to actually borrow the “pattern” term just to sell a few extra copies. It could have easily be named “Common problems with software engineering” or something of the sort.
To sum all this up, here are some links to design pattern resources: