C#设计模式迷你手册

一、 设计模式的隐喻

      武功套路是习武的门径。新手要一招一式地练习套路，烂熟于心之后，熟能生巧，在实战之中即可见招拆招、运用自如——此时习武之人已从“新手”成长为“好手”。“高手”则没有套路，实战之中只有自然反应，然而一招一式浑然天成、恰到好处，似有似无、无中生有。“高手”之上还有“高高手”，他们达到的境界非我等凭借金氏武侠小说可以揣测。

      设计模式之于设计，好比套路之于武术。“新手”要一个接一个地学习模式，“好手”能够活用模式，“高手”则没有模式。

      设计模式的“内功”是面向对象的基本原则。这些原则是“神”，模式是“形”。高手拼的是“内功”，对面向对象基本原则有了深刻的领悟，才能用好设计模式，避免“走火入魔”。

      一般在设计模式著作的前几章都会介绍面向对象的基本原则，这几章非常重要。学通了这几章，后面的模式就不过如此了。学完了设计模式，也最好翻过头来重新看看这几章，保证会有新的领悟。

二、 为什么使用设计模式

      对任何设计都可以凭主观（对设计很难做出客观评价）判断得出它是一个好的设计，还是一个坏的设计。使用设计模式是为了避免坏的设计。Martin叔叔在他的著作《敏捷软件开发 原则、模式与实践》中描述了拙劣设计的症状：

• 僵化性（Rigidity）：设计难以改变。
• 脆弱性（Fragility）：设计易于遭到破坏。
• 牢固性（Immobility）：设计难以重用。
• 粘滞性（Viscosity）：难以做正确的事情。
• 不必要的复杂性（Needless Complexity）：过分设计。
• 不必要的重复（Needless Repetition）：过多的重复。
• 晦涩性（Opacity）：混乱的表达。

 

三、 什么时候使用设计模式

      Martin叔叔的书中有段话：
      在学习它们（设计原则和模式）的时候，请记住，敏捷开发人员不会对一个庞大的预先设计应用那些原则和模式。相反，这些原则和模式被应用在一次次的迭代中，力图使代码以及代码所表达的设计保持干净。

• 在这段容易被读者忽略的文字中，我体会到这样几层含义：
• 代码是设计（这是Martin叔叔强调的一个观点，这个观点可以参考《敏捷软件开发 原则、模式与实践》一书的附录D）；
• 设计模式是为了使设计适应变化；
• 设计模式是重构的工具；
• 设计一开始就要保持干净、简单，以后仍然要保持干净、简单；
• 不能过度使用设计模式。

      使用设计模式的目的是为了适应未来的变化，变化之所以存在是因为它的不可预知性——如果可以预知，则不能称其为变化。如何判断哪些需求可能变化，哪些需求可能不变，并且在最大程度上保持设计的干净、简单，这是些工艺问题，而不是工程问题。既然是工艺问题，那么就只能给出原则，不能给出标准。使用设计模式的大体原则可能是：对未来极有可能发生变化的问题给出最简单、修改成本最低的解。　　

 

四、 避免过度使用设计模式

      易维护的程序首先要易理解，这一点远甚于其他。在易理解的代码上才好维护。过分地使用设计模式会增加程序的复杂性和晦涩性，让程序不易理解，从而降低了程序的易维护性。 Switch语句曾经遭致诟病，许多重构的例子就是拿Switch开刀。我认为Switch语句是高效的语句，可以写出极优雅、简单的代码。在很多情况下，直接使用Switch语句比把它拆成若干个Class更“干净”。 再比如，有一段四百多行的代码负责整个系统的调度，如果未来的变化仅仅是修改这四百行代码而不会大量添加代码，那么把这四百多行代码集中在一个函数里面，比将它拆分成十来个Class更加容易维护。

正式内容

	创建型	结构型	行为型
类	Factory Method	Adapter_Class	Interpreter Template Method
对象	Abstract Factory Builder Prototype Singleton	Adapter_Object Bridge Composite Decorator Facade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor
概览

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1724380