第3/4/5章 - 设计模式四原则

原则

一、单一职责原则（Single-Response-Principle）SRP

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

如果任何类型的需求来了，都需要改类，则维护麻烦，复用不可能，缺乏灵活性
  如果一个类承担的职责过多，就等于把这些职责耦合到一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责互相分离。
如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责

二、开放 — 封闭 原则（The Open-Closed-Principle）OPC

不能修改，但是可以拓展的的设计原则
对于拓展是开放的（open for extension）
对于修改是封闭的（close for modification）

eg：香港澳门回归，一国两制

软件实体（类、模块、函数等）应该可以拓展，但是不能修改

思考：
怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新版本呢？
eg：弹性工作制
上班总共时间是封闭的，不能变；但是几点来几点走是开放的。

无论模块多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对他设计的模块应该对哪种变化封闭做出选择。他必须先猜测初最有肯能发生的变化种类，然后构造抽象来隔离那些变化。

等到变化时立即采取行动：
在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。
面对需求，对程序的改动是通过增加新代码进行，而不是更改现有的代码。

三、依赖倒转原则

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

即：针对接口编程，不要对实现编程

eg：CPU、内存、硬盘、显卡 都是针对 主板上的统一接口设计的可插拔式。

不同手机厂商生产的智能机的充电接口现在都是type-C
苹果的是自成一家，数据线得单独设计实现

依赖倒转原则

A. 高层模块不应该依赖底层模块。2个都应该依赖抽象。
B. 抽象不应该依赖细节。细节应该依赖抽象。

为什么叫倒转？

例子1：
1. 高层模块 ——> 依赖底层模块
项目依赖某类型mySQL ,将Mysql访问代码写成函数，项目调用。

2. 底层模块换了
客户要求使用Oracle。此时高层项目模块与底层MySQL数据库访问模块绑定耦合在一起，没办法复用项目了。

例子2：
CPU、内存、硬盘 都 依赖 主板，若硬盘坏了，则它们统统不能使用。
反之若内存坏了也不应该造成其他部件不能用。

如果不管高层模块还是底层模块，都依赖于抽象，具体一点就是接口或抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他收到影响，这就使得无论高层模块还是底层模块都容易被复用，这才是最好的办法。

为什么依赖抽象的接口或抽象类就不怕更改？

四、里氏替换原则（LSP）

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

• 白话翻译：
  一个软件实体如果使用的是一个父类的话，那么一定适用于它的子类，而且它察觉不出父类对象和子类对象的区别。也就是说在软件里面，把父类都替换成它的子类，程序行为没有变化。

eg:
鸟类 能飞； 企鹅、鸵鸟不能飞，那么企鹅、鸵鸟不能继承鸟类并以鸟类的身份出现。

需求的变化，使得需要将猫更换成狗、牛、羊等别的动物，而程序其它地方不需要修改
Animal animal = new Cat(); 
animal.叫（）；
animal.跑（）；
animal.吃（）；
animal.喝（）；

只有子类可以替换掉父类且软件单位的功能不受到影响时，父类才能真正被复用，而子类也能在父类的基础上增加新行为。正是由于类型的可替换性，才使得父类型的模块在无需修改的情况下就可以得到拓展。

高层模块不依赖底层模块，两者都依赖抽象

依赖倒转其实可以说是面向对象设计的标志，用那种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计了。