设计模式总结－设计原则

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

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

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

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

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

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

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

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

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

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