全部博文（230）
分类： 项目管理
2008-08-31 00:25:26
Peter Sommerlad, Insitute for Software, HSR Rapperswil
I feel guilty as an author of many patterns and supporter of the pattern community because I've come to the conclusion that -in general- Design Patterns (DP) are bad for software design.
You might ask why the splendidly successful Design Patterns book [ GoF ] is bad for software design? Here are my answers:
The gang-of-four's (GoF) cultural revolution in making object-oriented (OO) design and programming mainstream has succeeded. But, in the early days of OO programming, only guru level people were actually designing working OO systems and the average programmer was stuck with BASIC, Pascal or C. Those were the people that invented the architectures that later became popular Design Patterns. The gurus were able to conciously think about their design decisions or already had the experience to decide between good or worse designs by a gut feeling. In addition they came from a time when Dijkstra, Hoare and Parnas etc's principles of simplicity, abstraction, structure, encapsulation, coherence and decoupling were well known, trained and followed. At least by the people considered capable of good software design.
Today, Design Patterns allows average developers to design OO systems and get them working that would have been beyond their design capabilities before. This sounds like a great thing, but the relative lack of expertise or brilliance can easily result in bigger software design desasters with DP applied than without.
Most of the Design Patterns in the GoF book are about introducing flexibility by indirection and inheritance. This is great when you use it to reduce code size and simplify logic by applying polymorphism, but in the hand of the uninitiated Design Patterns are a tool for overengineering and introducing unnecessary complexity. A feeble designer that cannot decide on a system property will use Design Patterns to postpone too many decisions, will speculate about features never needed and will lay a heavy burden on implementers and maintainers of the system.
Not only the GoF book is a reason for this situation, but also its use in training and education by teachers inexperienced in OO programming. Often the drawbacks of a Design Pattern are not explained well enough by the GoF or are omitted by readers or teachers, since DP are perceived as the OO design panacea. One reason for the obscurity of some of the issues with DPs lie in the aged form of the GoF style. Most modern pattern books provide a style that more clearly shows the problem and forces resolved and the downsides of the solution. Another issue is the often exclusive focus on the original 23 Design Patterns without showing students the breadth of pattern literature where better solutions for their design problems might be presented.
The GoF book if its your only source of patterns and OO design know how is outdated, not only because of its aged pattern format, but also because we know better patterns today. The paramount example of an obsolete DP that provides more problems than part of solution is the classic Singleton. I could argue longer than this point against singleton, but like to cite Kent Beck instead: "How do you provide global variables in languages without global variables? Don't. Your programs will thank you for taking the time to think about design instead." [ TDDbE ]
The key word in this citation is the word "think". Patterns should make you think and DP failed in many respects to actually make designers think about design, because it is so easy to implement them (especially Singleton). And they are so hard to get rid of. This asymmetry leads to accumulation of DP in systems, even when they are not needed and get in the way of improvement or simplicity. For example, I have seen people refactoring a simple if-statement into State without any need for it. Whenever you feel the itch to apply a DP think first, if you really need its flexibility and adding the patterns complexity will make the overall system simpler.
Nevertheless, I should be happy, since DP lead to many OO legacy systems that are in a big need for refactoring or reengineering. I get called to help start with that task, e.g., get rid of hundreds of Singleton classes and introduce unit tests for the code enabling refactoring.
In addition, developers need to unlearn some of the Design Patterns, such as Singleton, and relearn, understand and apply the basic principles of good design like Simplicity, low coupling, and high cohesion.
