Infected With Patternitis
Here is part one of a three-part article explaining why and when to use patterns in your software development project.
To summarize part one:
– The scope of your project may be bigger than you think.
– Patterns are a useful “universal” language when you are part of a programming team, no matter what the size.
In part two:
– Users and project managers always find a way to sneak features into the project during the development cycle.
– An “impossible change” to the project spec is always imminent during the development cycle and managers will want those changes incorporated into the project right away.
– A quickly coddled, poorly designed system results from all this constant changing of the specs during development. This results in unmaintainable code.
– When the time comes to “clean up” the code base for your project, it will be near impossible to do so without breaking anything.
In part 3, the article is concludes with some points regarding pro and anti pattern groups and finally lays out why patterns are useful no matter how small you think your project is. Before I read this article, I was already sold on using patterns in my projects. I even realized that I had been using some of the patterns described in [the GoF book in my projects][gof] without realizing it. I have experienced much of what the author of the article describes when it comes to working with small to medium sized projects. Needless to say, patterns really help. Even if you are a one man programming team.
[gof]: http://hillside.net/patterns/DPBook/GOF.html “Design Patterns”