亚马逊上有一个关于<设计模式>这本书的评论,讲得很有道理,於我心有戚戚焉
... well, it's over. "Patterns" have not revolutionized the world. Nor does this book need to be "studied" for deep insights.
What it seems patterns are actually good for is giving common names to popular solutions to problems, to make them easier to call to mind, and easier to discuss with others. Even this much is overrated. Before the advent of patterns, you could have said "callbacks" and people would have understood. Now you say "the Observer pattern".
_Design Patterns_ is none the less valuable, because it is one of those few books that EVERYONE is expected to have read. This is helpful in practice, as you can expect everyone to be familiar with its vocabulary. Few books truly fall into this "required reading" category. The only other that comes to mind is the MIT algorithms text. Many tech pundits claim that every next book is "required reading", and the claim becomes tiring after a while, but this is one of the few that really is.
I would not necessarily purchase it, though. The "pattern" schematic is verbose, and requires pages upon pages to describe something that, once you have seen it in practice once or twice, you will recognize immediately. Omitting the appendixes, the book is barely 350 pages, and presents only 23 patterns. Only a handful of the patterns are truly famous: Singleton, Observer, Template Method ... perhaps a few more. A number of them are poorly presented. Chain of Responsibility, for instance, is just one of many ways to define an event framework and does not belong in a book that doesn't present the alternatives. Mediator is another; there must be dozens of ways to create a Mediator, which most people would call an "event registry" or something else, rather than a Mediator. "Mediator" itself is little more than a name, and won't help you in design.
Some patterns are boring, since modern languages tend to provide them, and we've heard about them many times already: Iterator, Proxy, Memento (serialization). Others, like Command, are geared towards GUIs, and provide little value to other types of applications. Then there are the State and Strategy patterns, which are two sides of the same coin, and needn't be given two different names.
And so on. Definitely do not "study" this book if it seems you "just don't get it". Chances are the book is wrong. It is worth a read through, and a second read through if the terminology doesn't stick the first time, but stop at that. My gut feeling is that this book is most appropriate for someone working on his or her first large project. After that, once the terminology sinks in, the book has little else to offer. And if taken dogmatically, or considered "inspired" or infallible, the book is a hindrance. Finally, overuse of patterns can result in a "kitchen sink" design, instead of a simple one that takes a few patterns, that may or may not be ones from this book, and implements them cleanly. Take the book for what it's worth, but remain skeptical.
设计模式更多地是一种交流方法(在这一点上做的也并不好),它并不能带来好的设计
设计模式鼓励复杂的设计,往往导致过多的类,过多的封装,深层次的调用
我认为合适地进行面向对象设计最重要的就是对对象职责的划分,而要能正确划分对象职责必须对问题本身有良好的理解,但是设计模式会促使人把问题复杂化,臆想需求,为了设计而设计
在平常的编程中,我更倾向于遵从KISS原则,把问题简单化,然后用一些简单易懂的方法进行封装,保持接口的简单和一致性
个人浅见,欢迎指正