Using Patterns for Enterprise Development: Initial Thoughts
Background
I started programming at the age of twelve thanks to a close friend of the family who gave me a certificate for a Radio Shack computer course. I was lucky that the local store liked the idea of having a twelve-year-old programming their computers because it showed how truly easy computers were to use. Since that time, I have spent every day (except for a handful of vacation days when I was forbidden to bring a computer with me) programming or otherwise developing software at some level. I think this explains the warped view of the world I am so often credited with.
Now, more than twenty years and many hundreds of thousands of lines of code later, I get a chance to share a piece of what I find important. I have been amazingly lucky to learn from plenty of smart people, both colleagues on projects and students in various training courses I have taught. During this process I have learned lots of techniques and approaches—some of them helpful; some I had to unlearn. Certain key techniques, once internalized, changed my view on software development as a whole.
In 1994, I was working on an embedded pen-based system that was intended as a specialized notebook-size form entry device (much like a larger-size Palm Pilot). This was one of those many technical projects that met its objectives but never really achieved the market space it needed for commercial success. At that time I started to notice several idioms or common techniques that I had used and that had been used in other systems, both at my current company and at other companies I had worked for. We spent a while trying to come up with ways to document and refine the techniques.
It was at this point that a friend directed me to the patterns work being compiled, and I delved into this area, exploring the work done by Christopher Alexander and others. I discovered that not only did these patterns address the same type of things we were doing, but they opened my eyes to a whole new way of looking at problems and understanding system architecture as a whole. I also discovered many things I had done wrong in the past and finally understood why some of our previous efforts had failed. I resolved not to repeat those errors and to come up with ways to share this knowledge with others.
Let's jump right in. Let me show you one of the first patterns I wrote and one that forms one of the key tenets I try to use when designing any software system. I'll present it here quickly. Later, I'll explain the key sections of the pattern and show its application throughout the book. However, I think it is important to understand that whether you agree with it, a pattern forms a picture in your mind, conveying the key concepts and application in a readily accessible manner.