（3）&（4）&（5） 设计模式原则

这几章内容都是说的设计模式的原则，其实也就是面向对象的一些基本使用原则，一般任何一本书上都会写，只是归纳总结的没有这么好而已，可是这些原则用起来，可真不容易，这些原则都用会了，那么设计模式也就学通了（目标啊 ），理解和解释都不难，就是用起来不简单啊！！！ ### 单一职责原则 就一个类而言，应该仅有一个引起它变化的原因。（摘抄） 这个通俗的解释应该把各个类都划分清楚，功能都尽量的分开，不要界面和逻辑处理写到一个类里面。 ### 开放——封闭原则 是说软件实体（类，模块，函数等等）应该可以扩展，但是不可以修改。（摘抄） 也就是说尽量的去写接口，抽象类，如果需要增加功能，那么实现接口，继承父类就好，而不需要去修改已经写好的代码，前面提到的两种模式感觉就是单一原则和开放封闭原则的结合。 感觉书上的有一段话写得很好，简单来说就是应该对那些需要频繁变化的部分进行抽象，而不是对每一个部分都去可以的抽象，这样才能做到理解了面向对象。 拒绝不成熟的抽象和抽象本身一样重要。（摘抄） 这时就要学会去判断，那些部分是需要拓展的，而哪些部分是不需要拓展的，这就需要根据自己的实际情况来判断，过于多的不成熟抽象，会造成代码量的增加和结构的复杂，会让别人感觉绕来绕去的。 ### 依赖倒转原则 1.高层模块不应该依赖低层模块。两个都应该依赖抽象。 2.抽象不应该依赖细节。细节应该依赖抽象。（摘抄） ### 里氏代换原则 子类型必须能够替换掉它们的父类型。（摘抄） 后面两种原则放在一起说吧，书上也是把这两种放在一个章节的。这个我用一个简单的例子说一下我的理解 例如你的程序，需要做两种数据访问操作，一种是从网络获取数据，一种是从本地获取数据，那么这两种方法的实现肯定是不同的，假如你这时候把写成函数，那么就非常不好操作和修改，如果要加一个操作的话那么就是灭顶之灾而且别的类无法调用这两个操作，如果你把这两种操作分别写成两个类那么比写成两个函数会好一点，但是这样，要是类一多，那么就不方便了，所以这时就可以抽象一层，把获取数据作为一层，然后使用者依赖于这个抽象类，实现者也依赖于这个抽象类，那么增加类，修改类，对使用者就没有影响了，只要抽象类保持不变即可。 ### 总结 就用前面提到过的计算器的例子来解释这四种原则把，把加减乘除分开，体现了单一原则，四个实现类继承于抽象出来的父类，体现了依赖倒转和开放——封闭原则，使用时，把子类向上转型成父类对象，这时就用到了里氏代换原则。