简谈设计模式的几个原则

    最近设计模式进行到一半，停了两天没有敲代码，但是把整本书的内容看了又看，整理下思路。。。

    刚学了一周多，但是对大话设计模式这本书我有一种一见如故的感觉。它里面的很多话我都觉得很经典。

    比如，在序的前面，有一张非常空白的纸上，写了3段话，其中有一段是这样说的：了解优秀软件设计的演变过程比学习优秀设计本身更有价值，因为设计的演变过程中蕴藏着大智慧。  这本书的作者在每一章节，都用了大量的篇幅来写如何演变成一个模式的，在代码的变化中，我们可以看出很多东西和自己的影子。

  。。。。。（N多，留白。。。）

   总之，想说，这是一本“非常非常非常。。。”好看的书，无论是学习还是为了生活，都应该多读几遍。

   书中讲了23中设计模式，万变不离其宗——设计模式的原则。

   任何变化虽然是动态的，但是，我们从变化中可以窥见一些未来的趋势。正如书中作者所说：研究历史是为了更好的迎接未来。

    下面，我们来看一下设计模式中的一些原则：

      单一职责：

             就一个类而言，应该仅有一个引起它变化的原因。

        看到这个原则，我想起了以前看到的这样一句话：如果想同时坐在两把椅子上，那么，你的结果很可能是掉在两把椅子中间的。也就是说，我们为自己预定的位置越多，我们同样要承担的责任也就越多，那么，自己最可能的结果就是什么都做不好。在设计类的时候也一样，如果类要承担的职责越多，那么它就越可能什么都承担不好。

   

      开放封闭原则：

       是说软件实体(类,模块,函数等)应该可以扩展,但是不可修改.

    这个原则的两个特征:

     1,对于扩展是开放的

      2,对于更改是封闭的.

过去的错误，如果现在想去修改，这在软件设计里面可以实现，但是在人生里面却是被禁止的。因为时光是不能倒流的。我们能做的，就是把今天做到最好，去扩宽生命的长度，而不是一味的沉溺于自己的错误。

      依赖倒转原则：

 1，高层模块不应该依赖低层模块。两个都应该依赖抽象。

2，抽象不应该依赖细节，细节应该依赖抽象。

上学这么多年，一直发现，物理学的课本里面的概念最抽象，最不容易理解，一直在想，那些写书的人，你们把课本写的通俗易懂一点会死啊。。。但是学过抽象这个词才发现，这样写有这样写的好处：概念越抽象，就越能概括大多数情况。物理学研究的非常宏观，所以它的概念理应是非常抽象的。在类的设计中，也要尽可能的抽象，以方便以后的扩展。

里氏转换原则

          

             子类型必须能够替换掉它们的父类型。

          

              在生物学上，有个概念叫做遗传。遗传就类似继承，这保证了后代完全拥有父辈的保留下来的非常有利生存的优势。即使它们的父辈死去，它们也能完全承担自己在生物链中的职责。同时，后代还有一个独有的东西：变异。通过变异，实现优胜劣汰，让自身发展的更好。

      迪米特法则

    如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

    在明代朱元璋当上皇帝后，为了防止将领拥兵自重（他还是比较做贼心虚的，明明自己就是“黄袍加身”当上皇帝的那种模式。。。），实行了一条政策，就是将领不掌管军队，而是由皇帝亲自对军队实施调度，这样，大大削弱了将领和士兵之间的联系，即使有些将领想要造反，也没有士兵拥护。朱元璋这种方法，就如同在软件设计中，减少两个类的联系一样。如果将领要调兵，要向皇帝请圣旨，然后皇帝发兵。通过减少联系来弱化关系。

  合成聚合复用

        尽量使用合成/聚合，尽量不要使用类继承。

        我非常信奉老舍《茶馆》里的一句话：“莫谈国事”。但是国事又是非常有意思的，让人总是会忍不住想要想一想。在官场上，有这样一种现象，比如，去年关注度很高的一位高官，一家全完。又比如，一起跟某某总统很熟，是校友什么的，然后总统一上任，就把它提拔为高官。。。。。有很多事情是变换莫测的。但是，这里有一个原则：尽量减少密切的连续，但是可以加强合作。也就是说，不要加入他们，以免将来被当成同党一网打尽，但是可以成为盟友。

   以上就是关于设计模式原则的一些联想，感觉很有意思。