设计模式开篇-不要滥用设计模式

作者：阿修罗一平

链接:http://www.cnblogs.com/yiping06993010/archive/2006/10/18/532838.html

设计模式总结－不要滥用模式

从前年开始接触设计模式，一直都想深入设计模式的精髓，却都因为懒惰，再加上潜质不够（因为每次读完一个模式，都会有新的收获，而不能象金庸小说中的少侠，天资聪慧，绝世武功一遍搞定），还在继续努力着。 最开始读的是GOF的《设计模式：可复用面向对象软件的基础》，读到了一半，因为项目时间越来越紧张，每天晚上加班回去后就想睡觉。于是，书的下一半到现在几乎都是新的，一直都放在我的床头。后来，开始拜读阎宏老师的《java与模式》，新的项目也开始了，又因为惰性，看一会停一会，最终导致一个结果是：创建模式读了3遍，结构模式读了2遍，而行为模式只读了1遍。最近，改变了读书方式，感觉下来还不错。这次借blog开通之际，记录一下大师们的观点，让没有接触过的朋友了解一下，也许会有收获。不知道过几年后，看到这些，我会是什么心情呢？呵呵，也许还在努力着。

        我设想分几步走：第一步，因为《java与模式》我完整的看过，所以总结先以《java与模式》开始。第二步，读完《设计模式：可复用面向对象软件的基础》，然后进行总结；第三步，总结它们之间的区别。

     现在就从阎宏老师的《不要滥用模式》开始我的记录。

       从理论上将，面向对象的编程鼓励代码的复用，而设计模式本身是经过时间检验的设计方案，因此，应当说设计模式便是对成功的设计方案的复用。通过设计方案的复用，可以带动代码的复用，达到提高代码复用率的作用。但是所有的理论在应用到实践中的时候，都必须对具体问题做具体分析。

       随着设计模式越来越普及，又一种倾向也变得越来越明显，这就是没有经验的设计师对设计模式的盲目崇拜和过分的追求。这些设计师不是全力以赴地为它们所面临的问题找出最好的设计，而是将力气放在如何尽可能多和频繁地使用著名的模式。它们错误地认为，只要使用了这些设计模式，就可以保证一个设计方案是好的设计方案。因此，使用模式越多，设计就越好，这就导致了很多根本没有意义的设计。在这些设计里充斥着著名的设计模式，但是设计却和系统的需要严重脱节。

    要想恰到好处地在一个系统里面使用设计模式，必须做到一下几点：

   1、完全了解面临的问题，这就是说要完全了解具体情况。如果不完全了解所面临的问题，怎么能谈得上解决问题呢？

   2、完全了解模式，这就是说要十分懂得理论。如果不完全懂得所使用得理论，怎么能够正确地应用这一理论呢？

   3、非常了解怎样使用设计模式解决实际的问题，这就是说要将模式理论与具体系统需求情况相结合。如果设计师不知道一个设计模式怎样对系统设计有帮助的话，最好不要使用这个模式。不要只是因为想在简历上写设计模式方面的经验就盲目地使用模式。

    很多时候，也许大概知道模式的所解决的问题，知道模式模式的类图，我们都是为了用模式而使用模式，对于模式的不了解，不了解模式所要解决的问题，不了解模式的特点，不了解它们的适用范围，不了解它们之间的区别，造成了设计方案的失误。模式是用了一大堆，却没有得到应有的效果，代码的维护还是牵一发而动全身（夸张了啊）。这样使用模式，也许还不如不使用模式的效果，也许是对的。    

    好了，下班回去做饭了。

链接:http://www.cnblogs.com/yiping06993010/archive/2006/10/19/533970.html

设计模式总结－设计原则

 注：文章只是作为设计模式的总结，记录自己认为正确的观点。  如有不同观点，请指教。

      文章不是想说设计模式的重要性，更不是介绍设计原则，相关的文章太多了，在这里只是想给学习设计模式时没有在意设计原则的朋友提醒一下：在看模式的过程中，考虑一下设计原则在模式中的体现。因为，我有过这种失误。

      曾经在一次面试中，有一位负责人问我：你都了解哪些设计模式？呵呵，我不禁要笑了。

      也许有些人更多的关注的是如何正确地运用这23种设计模式做出优秀的系统设计。面对上面的问题，不同的人有不同的理解，有的人会认为，你连23种设计模式都不清楚，谈什么系统设计。也有人会认为，设计模式包含的不仅包含这23种，还包括了更深层次的设计思想。

      在这里，我们想知道的是是否了解的模式数量越多，就越能体现设计能力？如果在这23种设计模式中，没有哪一个模式适合用于解决所遇到的问题，那我们该怎么办，是否就是随意设计呢？我就只会用这23种设计模式，而且用的很活，是不是就达到了设计师的水平？说到这里，一堆砖头扔过来，别急，我和大家的答案是一致的。随着不断的接触，有一天一不小心，被23种设计模式扔出来，我突然发现，设计模式最根本的是设计原则，每一个设计模式，都是这些设计原则在解决某一具体问题的表现和应用；不仅要掌握23种设计模式及其应用，更要理解设计原则以及这些设计原则在23种设计模式中的应用。所以，不论是在使用已有的设计模式的时候，还是在面对设计模式都无法解决问题的时候，是否都应该想想设计原则呢。
    
      以下列出一些设计原则，也许与其他参考书有出处，不过理解就好。

      “开－闭”原则
        一个软件实体应当对扩展开放，对修改关闭。当需求改变时我们可以对模块进行扩展，使其具有新的功能对更改是封闭的，对模块扩展时，不需要改动原来的代码面对抽象而不是面对细节，抽象比细节活的更长僵化的设计——如果程序中一处改动产生连锁反应。

      
       里氏代换原则
       任何积累可以出现的地方，子类一定可以出现。里氏代换原则是对“开－闭”原则的补充。实现“开－闭”原则的关键步骤是抽象化，而积累与子类的继承关系就是抽象化的具体体现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

        依赖倒转原则
        要依赖于抽象，不要依赖于实现。看上去依赖倒转原则与“开－闭”原则有很大的相似指出，实际上，它们之间的关系是目标和手段之间的关系。“开－闭”原则是目标，而达到这一目标的手段是依赖倒转原则。

        合成/聚合复用原则
        要尽量使用合成/聚合，而不是集成关系达到复用的目的。显然，合成/聚合复用原则使与里氏代换原则相辅相成的，两者又都是对实现“开－闭”原则具体步骤的规范。前者要求设计师首先考虑合成/聚合关系，后者要求在使用集成关系时，必须确定这个关系是符合一定条件的。
      
         迪米特法则
         一个软件实体应当与尽可能少的其他实体发生相互作用。当一个系统面临功能扩展的时候，其中会有一些模块，它们需要修改的压力比其他一些模块要大。最后的结果可能是这些模块需要修改或者不需要修改。但是不论是哪种情况，如果这些模块是相对孤立的，那么它们就不会将修改的压力传递给其他的模块。

        接口隔离原则
        应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。显然，接口隔离原则与广义的迪米特法则都是对一个软件实体与其他的软件实体的通信限制。广义的迪米特法则要求尽可能的限制通信的宽度和深度。接口隔离原则所限制的是通信的宽度，也就是说，通信应当尽可能地窄。显然，遵守接口隔离原则与迪米特法则，会使一个软件系统在功能扩展地过程种，不会将修改地压力传递到其他的对象。