As an abstraction, design patters can prove both beneficial and detrimental depending upon the situation. By attempting to generalize the way in which problems are solved in software development, design patters create a certain unofficial standard in which certain problems are approached and managed. Design patterns are not usually created overnight, but are often the result of various different people and groups. Thus design patters are often “tried and true” methodologies that people unfamiliar with certain problems can utilize to improve certain aspects of their software. All software developers whether they realize it or not, follow their own sort of design patterns. These patterns can range from using the same methods to solve similar problems, to certain ways of modularizing and structuring programs and how specific features are implemented, etc.
The thing about design patterns is, while many effective design patterns exist, there are also numerous ineffective design patterns as well. As technology and philosophy about software development advances old design patterns become obsolete, yet because not everyone is up to date with them, they still get implemented despite their drawbacks or existence of better solutions. Even worse are design patterns that persist not through ignorance, through fear and lack of knowledge in them. In these cases, not only do old design patterns persist, but even if they are effective, because so few people have knowledge on how to maintain them if something was ever to happen to the actual code itself, many things would need to build from the ground up.
In a way, design patterns are not just limited to actual abstractions for problem solving, but are also ways in which developers approach all of programming in general. Design patterns can become a way of thinking as a whole, not just about solving specific problems. This can thus both restrain and free the minds of developers.