面向对象设计模式总结

       从去年7月份开始学习设计模式一直到今年3月底，4月初，共8个多月，想把自己明白的总结下来，也希望给初学的朋友们一点点东西。

        记得去年9月份时一位IT大佬问我设计模式你用过哪些，我说好像都很少用（其实是自己不懂），如果我现在再回答问题就会是基本都在用，其实在一些前辈的程序里，即使他们没有学习设计模式，也会看到很多设计模式的影子，下面我就来简单介绍一下

       23种设计模式首先其实是围绕5个设计原则来的，这5个设计原则充分体现了面向对象的精髓

       一：单一职责原则，故名思意就是只一个原则，定义：就一个类而言，应该仅有一个引起它变化的原因。其实就好比我们现在用的手机和数码相机，手机是一个类（可以拍照哦），数码相机是一个类，不管现在手机拍照有多好都不可能赶上数码相机，而且修一个照相功能就得拆开整个手机，数码相机的好就是因为它只有这一个“职责”。

               面向对象编程里面就是：如果一个类承担的职责过多，就等于把这些职责耦合在一起，那么如果我要修改这个类里面的一个方法，却可能要影响类其它的地方，一个职责的变化可能会削弱或者抑制这个类其它职责的能力，这种设计不是显得很脆弱很苍白吗，所有一个类应当仅仅包含一方面的职责，同理，一个函数也应当仅仅只有一个功能。如果你有了多于一方面的理由去修改类，那么它就有了多于的职责，你就应该考虑重新分割了，

       二：开放--封闭原则，这个原则相信大家一定不会陌生，像微软，360，腾讯等等无一不体现这一设计原则，他们开发的软件都是越来越大是吧，就是他们不修改以前写好的代码，只是将它们扩展（比如继承）来达到增加功能，优化界面，增强稳定性的目的。定义：软件实体（类，模块，函数等等），我们应该可以扩展它，而不应该修改它。 我们的程序升级不是每个地方都要变，所以对于扩展是开放的（Open for extension）,但对于更改是封闭的（Close for modification）

        这就要考验我们的“预知”能力了，我们要提前预测哪些模块可能是易变的（比如：界面），哪些应该是不变的，然后把这些不变的地方构造抽象隔离出来，让那些易变的来继承它，这样我们升级是只需要增加一个继承自抽象类的子类就可以了，这样一来我们既不会害怕与之前的兼容性，又实现了拓展

        三：里氏代换原则，看起来很英伦范儿啊，呵呵，里氏代换原则是Barbara Liskov这个女人在1988年发表的，它在数学上也有用处，简单意思就是继承自父类的子类在使用中应当可以完全代替父类的功能，定义：子类型必须能够替换掉他们的父类型。也就是说，只有当子类可以替换父类，且软件功能不收影响时才是对的，因为只有这样继承的复用父类效果才体现出来，否则就得看看是不是继承错了，或者继承不合理。

       四：依赖倒转原则，意思就是我们应该针对类对外的函数接口去实现，而不是一味得去实现这个类要表达的功能，比如电脑，如果我们直接就是想造一个可以联网，计算，显示的一个整体的电脑也是可以的，不过如果显示屏幕坏了，那就相当于这个电脑都坏了，对吧。可以如果我们现在只是把他们一个个分离出来，每个部件（类）都有对外的接口（类成员函数），那么我们就只需要管理这些接口之间的处理就可以了，也就是说，屏幕类坏了或者是要升级更好的我们只需要找他们的继承类来替换就好了，因为他们接口一样，所以就可以很好的“组合”上去，定义：高层模块不应该依赖底层模块，两个都应该依赖抽象，抽象不应该依赖细节，细节应该依赖抽象。

        五：迪米特法则：定义：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中一个类需要调用一个不应当直接发生关系类的方法的话，可以通过第三者来转发这个调用。比如：我们（第一个类）要用电脑主机（第二个类）的联网功能，那么我们就可以通过屏幕（第三者）来调用即可。

        类之间的耦合越松，越有利于复用和维护，一个处于弱耦合的类被修改，就不会波及到其它类了