1.1 单一职责原则
单一职责原则：Singel Responsibility Principle，SRP
单一职责原则的定义：应该有且仅有一个原因引起类的变更。
书中提到一个例子：对电话的抽象。
继续细化，向下拆分，向上抽象
电话通话时可以抽象出4个过程：拨号、通话、回应、挂机。
在举着个例子的时候，作者提到大部分人可能都会说这个没什么问题，动作定义比较清晰。其实如果更深层的了解电话的结构，应该可以对电话类进行一个更完整的抽象。
比如：电话的通话过程，是否是自始至终都是这四个阶段，在发展过程中会不会增加或者减少。如果以阶段为维度来进行抽象，是否会出现经常变更的情况。如果换一个维度，如：从更底层职责的角度来进行抽象，会抽象出“协议管理”和“数据传输” 两个角度，无论中间阶段发生什么变化，这两个职责，是一个电话必须拥有的。
所以我们在对业务模型进行抽象定义时，也需要尽量的事无巨细的了解业务的模型，然后再做分析。
回归原则定义
原则定义：应该有且仅有一个原因引起类的变更。
上面的接口并不是“只有一个原因引起变化”的。IPhone 不只是只有一个职责，它包含两个职责：
- 协议管理：dial() 和hangup() 方法负责拨号接通和挂机
- 数据传送：chat() 实现数据传送，把话转换成信号在双方之间传递
这两个职责都会引起这个接口或者实现类的变化：
日常习惯
比如一个用户信息接口：
这个接口有一个“修改用户信息”的方法。这个方法太过于笼统，一个方法承担了多个职责，这样的接口虽然对上层来说只提供了一个接口，但是它的职责并不是单一的。这样做需要在接口文档上做额外的注释，说明这个修改接口都可以修改哪些信息，操作参数什么情况需要传什么样的值。在《代码整洁之道》中建议过：提供好的注释，不如将代码写的别人一看就明白，无需注释。这里也一样，一个好的接口的定义，不需要文档中做长篇大论的调用说明。与其做一堆说明，不如在定义接口的时候，定义的清晰易懂。
这样定义会对上层更友好一点，将修改用户信息拆解为多个方法，每个方法只负责一件事，别人一看就知道，那个方法改的是什么，这个接口每个方法都能修改什么，清晰完整。
实际开发
虽然一直说要按照SRP的原则去进行设计，但毕竟理论是理论，实践是实践。在实际开发过程中，有很多因素导致最终无法达到按照SRP原则的最终效果，比如开会讨论业务模型中职责的划分；又比如deadline比较紧急，没有足够的时间进行讨论和设计。一个行业的驱动最终还是业务，代码只是实现业务的工具，是轮子。一个功能，最低要求就是先能跑起来，完成功能。只是在一开始实现的时候，尽可能的去往 SRP 上靠，读者的建议是：
对于单一职责原则， 我的建议是接口一定要做到单一职责， 类的设计尽量做到只有一个原因引起变化。
1.2 里氏替换原则
里氏替换原则原则是在继承方面上的一个要求。它是针对继承的弊端而出现的一个原则。
继承的优点：
- 共享代码，提供代码的重用性
- 提高代码的扩展性
- 提高产品或者项目的开放性
继承的缺点：
- 继承是侵入性的，只要继承，就必须拥有父类的所有属性和方法
- 增强了耦合性。当父类的内容修改时，需要考虑子类的修改，可能会造成大段代码需要重构
定义
Liskov Substitution Principle， LSP
所有引用父类的地方必须能透明的使用其子类的对象。
通俗的讲，只要父类出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或者异常，使用者可能根本不需要知道是父类还是子类。但是反过来就不行，有子类的地方，无法用父类进行替换。
LSP 对良好的继承定义了一个规范，这个规范包含四层含义：
1. 子类必须完全实现父类的方法
书中的例子是“士兵和枪”的例子。当定义“ToyGun”时，由于 ToyGun 无法杀人，程序无法正常运行。原因是 ToyGun 无法完整的实现 shoot 功能。
在具体应用场景中就要考虑下面这个问题了： 子类是否能够完整地实现父类的业务， 否则就会出现像上面的拿枪杀敌人时却发现是把玩具枪的笑话
如果子类不能完整地实现父类的方法， 或者父类的某些方法在子类中已经发
生“畸变”， 则建议断开父子继承关系， 采用依赖、 聚集、 组合等关系代替承。
注意：在类中调用其他类时务必要使用父类或接口， 如果不能使用父类或接口， 则说明类的设计已经违背了LSP原则。
2. 子类可以有自己的个性
书中给出的例子是“狙击手使用狙击枪杀人”，表达的意思是：如果实例类型为子类，则子类无法强转成父类类型进行调用。
3. 覆盖或实现父类的方法是输入参数可以被放大
书中举出了一个例子，这个例子会导致“子类在没有覆写父类的方法的前提下，子类方法被执行了”。
这个例子中子类对于方法的定义就有问题：
public class Father {
public Collection doSomething(Map map) {
System.out.println("父类被执行...");
return map.values();
}
}
public class Son extends Father {
//缩小输入参数范围
public Collection doSomething(HashMap map) {
System.out.println("子类被执行...");
return map.values();
}
}
public class Client {
public static void invoker() {
//有父类的地方就有子类
Father f = new Father();
HashMap map = new HashMap();
f.doSomething(map);
}
public static void main(String[] args) {
invoker();
}
}
子类的doSomething方法，并不是覆盖，而是对从父类继承过来的doSomething方法的重载。在 Client 执行时，如果使用子类去替换，实际执行的将会是子类的 doSomething 方法。从而导致了“子类在没有覆写父类的方法的前提下，子类方法被执行了”。
注意，这里是有一个前提：“子类在没有覆写父类的方法的前提下”
如果是子类在复写了父类的方法下，使用子类去替换父类，调用的实际是子类的方法，这样是ok的。但是上面却是没有复写到父类的方法。没有复写，而且输入参数的范围比父类的方法大，就会出现问题。
正确的例子是：
public class Father {
public Collection doSomething(HashMap map) {
System.out.println("父类被执行...");
return map.values();
}
}
public class Son extends Father {
//缩小输入参数范围
public Collection doSomething(Map map) {
System.out.println("子类被执行...");
return map.values();
}
}
public class Client {
public static void invoker() {
//有父类的地方就有子类
Father f = new Father();
HashMap map = new HashMap();
f.doSomething(map);
}
public static void main(String[] args) {
invoker();
}
}
这样执行，子类也没有复写到父类的方法，但是在Client中用子类去替换父类，实际执行的还是父类方法。
最根本的原因，就是 子类在定义同名方法时，输入参数的范围比父类更大。
4. 覆盖或实现父类的方法是输出结果可以被缩小
书中分了两种情况：
- 子类覆盖：返回值范围要小于等于父类的方法
- 方法重载：这个无所谓，因为不会调用到该方法
这个也比较好理解，目的是：
让上层在调用目标方法后，在使用方法的返回值时不会出现不存在方法的现象。如果返回值是父类，而实际返回值类型是子类，这样没什么问题；如果反过来，就可能会出现问题，上层在调用返回值中的方法，有可能是子类独有的方法，而返回值类型是父类，会出现调用失败的现象。
总结：
遵守了这四个规范，也就相当于遵守了 LSP 原则
1.3 依赖倒置原则
依赖倒置原则的表现：
- 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
- 接口或抽象类不依赖于实现类；
- 实现类依赖接口或抽象类。
书中用“司机开车”的例子来说明。
public class Benz {
//汽车肯定会跑
public void run() {
System.out.println("奔驰汽车开始运行...");
}
}
public class Client {
public static void main (String[] args) {
Driver zhangSan = new Driver();
Benz benz = new Benz();
//张三开奔驰车
zhangSan.drive(benz);
}
}
Driver 和 Benz 类都是实现类，Driver 强依赖 Benz 类。
如果将来需要司机去开 BMW，程序将无法完成。此处进行结构优化，对实现类进行抽象，解除强依赖关系。
public interface IDriver {
//是司机就应该会驾驶汽车
public void drive(ICar car);
}
public class Driver implements IDriver{
//司机的主要职责就是驾驶汽车
public void drive(ICar car){
car.run();
}
}
public interface ICar {
//是汽车就应该能跑
public void run();
}
public class Benz implements ICar{
//汽车肯定会跑
public void run(){
System.out.println("奔驰汽车开始运行...");
}
}
public class BMW implements ICar{
//宝马车当然也可以开动了
public void run(){
System.out.println("宝马汽车开始运行...");
}
}
public class Client {
public static void main (String[] args) {
IDriver zhangSan = new Driver();
ICar benz = new Benz();
//张三开奔驰车
zhangSan.drive(benz);
//IDriver zhangSan = new Driver();
//ICar bmw = new BMW();
//张三开奔驰车
//zhangSan.drive(bmw);
}
}
总结一下依赖倒置的好处：
- 在新增加低层模块时， 只修改了业务场景类， 也就是高层模块， 对其他低层模块如Driver类不需要做任何修改， 业务就可以运行， 把“变更”引起的风险扩散降到最低
- 两个类之间有依赖关系， 只要制定出两者之间的接口（ 或抽象类） 就可以独立开发了， 而且项目之间的单元测试也可以独立地运行
最佳实践
我们怎么在项目中使用这个规则呢：
- 每个类尽量都有接口或抽象类， 或者抽象类和接口两者都具备
- 变量的表面类型尽量是接口或者是抽象类
- 任何类都不应该从具体类派生
- 尽量不要覆写基类的方法
- 结合里氏替换原则使用
1.4 接口隔离原则
定义
接口：
- 类接口
- 实例接口
隔离：
- 客户端不应该依赖它不需要的接口
- 类之间的依赖关系应该建立在最小的接口之上
接口隔离原则概括为一句话：
建立单一接口，接口尽量细化，同时接口中方法尽量少。
例子
书中给出的例子是“美女类”的例子
接口定义了一个美女：
public interface IPettyGirl {
//要有姣好的面孔
public void goodLooking();
//要有好身材
public void niceFigure();
//要有气质
public void greatTemperament();
}
接口存在的问题是：审美会随着时间的改变而改变。
接口IPettyGirl的设计是有缺陷的， 过于庞大了， 容纳了一些可变的因素。而我们却把这些特质都封装了起来， 放到了一个接口中， 封装过度了。
把原IPettyGirl接口拆分为两个接口， 一种是外形美的美女IGoodBodyGirl， 这类美女的特点就是脸蛋和身材极棒， 超一流， 但是没有审美素质， 比如随地吐痰， 文化程度比较低； 另外一种是气质美的美女IGreatTemperamentGirl， 谈吐和修养都非常高。把一个比较臃肿的接口拆分成了两个专门的接口， 灵活性提高了， 可维护性也增加了， 不管以后是要外形美的美女还是气质美的美女都可以轻松地通过PettyGirl定义。
/** 外表型美女 **/
public interface IGoodBodyGirl {
//要有姣好的面孔
public void goodLooking();
//要有好身材
public void niceFigure();
}
/** 气质型美女 **/
public interface IGreatTemperamentGirl {
//要有气质
public void greatTemperament();
}
/** 最标准的美女，拥有所有优点 **/
public class PettyGirl implements IGoodBodyGirl,IGreatTemperamentGirl {
private String name;
//美女都有名字
public PettyGirl(String _name){
this.name=_name;
}
//脸蛋漂亮
public void goodLooking() {
System.out.println(this.name + "---脸蛋很漂亮!");
}
//气质要好
public void greatTemperament () {
System.out.println(this.name + "---气质非常好!");
}
//身材要好
public void niceFigure () {
System.out.println(this.name + "---身材非常棒!");
}
}
让客户端去依赖两个专用的接口，比去依赖一个综合的接口要更加灵活。
接口隔离原则的目的
接口隔离原则是对接口进行规范的约束
接口要尽量的小
这一点上面的例子已经体现了，如果一个接口已经存在了臃肿现象，它会影响一个正常的代码结构，一些不需要实现的方法强制去实现。要对接口进行细化。
接口要高内聚
高内聚 就是提高接口、 类、 模块的处理能力， 减少对外的交互。
具体到接口隔离原则就是， 要求在接口中尽量少公布public方法， 接口是对外的承诺， 承诺越少对系统的开发越有利， 变更的风险也就越少， 同时也有利于降低成本
定制服务
只提供访问者需要的方法
接口设计是有限度的：
- 对接口的拆分也需要有度，根据接口隔离原则拆分接口时，首先必须满足单一职责原则
- 接口的设计粒度越小， 系统越灵活， 这是不争的事实。 但是， 灵活的同时也带来了结构的复杂化， 开发难度增加， 可维护性降低。
如何衡量原子接口或原子类的划分：
- 一个接口只服务于一个子模块或业务逻辑
- 通过业务逻辑压缩接口中的public方法， 接口时常去回顾， 尽量让接口达到“满身筋骨肉”， 而不是“肥嘟嘟”的一大堆方法
- 已经被污染了的接口， 尽量去修改， 若变更的风险较大， 则采用适配器模式进行转化处理
- 了解环境， 拒绝盲从。 每个项目或产品都有特定的环境因素，深入了解业务逻辑
与单一职责原则的区别
接口隔离原则与单一职责的审视角度是不相同的， 单一职责要求的是类和接口职责单一， 注重的是职责， 这是业务逻辑上的划分， 而接口隔离原则要求接口的方法尽量少。
1.5 迪米特法则
定义
原则
对外公开的范围
一个类公开的public属性或方法越多， 修改时涉及的面也就越大， 变更引起的风险扩散也就越大，因此， 在设计时需要反复衡量：
- 是否还可以再减少 public方法和属性
- 是否可以修改为private、 package-private（包类型， 在类、 方法、 变量前不加访问权限， 则默认为包类型） 、 protected等访问权限
- 是否可以加上final关键字等
成员的归属
如果一个方法或者属性放在本类中， 既不增加类间关系， 也对本类不产生负面影响， 那就放置在本类中
最佳实践
迪米特法则的核心观念就是类间解耦， 弱耦合，既做到让结构清晰， 又做到高内聚低耦合。
1.6 开闭原则
定义
对扩展开放， 对修改关闭， 其含义是说一个软件实体应该通过扩展来实现变化， 而不是通过修改已有的代码来实现变化
例子
书中用 “书店买书” 的例子来进行说明
/* 书籍接口 */
public interface IBook {
//书籍有名称
public String getName();
//书籍有售价
public int getPrice();
//书籍有作者
public String getAuthor();
}
/* 小说类 */
public class NovelBook implements IBook {
//书籍名称
private String name;
//书籍的价格
private int price;
//书籍的作者
private String author;
//通过构造函数传递书籍数据
public NovelBook(String _name,int _price,String _author){
this.name = _name;
this.price = _price;
this.author = _author;
}
//作者是谁
public String getAuthor() {
return this.author;
}
//书籍叫什么名字
public String getName() {
return this.name;
}
//获得书籍的价格
public int getPrice() {
return this.price;
}
}
/* 模拟业务流程类 */
public class BookStore {
private final static ArrayList bookList = new ArrayList();
//static静态模块初始化数据， 实际项目中一般是由持久层完成
static{
bookList.add(new NovelBook("天龙八部",3200,"金庸"));
bookList.add(new NovelBook("巴黎圣母院",5600,"雨果"));
bookList.add(new NovelBook("悲惨世界",3500,"雨果"));
bookList.add(new NovelBook("金瓶梅",4300,"兰陵笑笑生"));
}
//模拟书店买书
public static void main(String[] args) {
NumberFormat formatter = NumberFormat.getCurrencyInstance();
formatter.setMaximumFractionDigits(2);
System.out.println("-----------书店卖出去的书籍记录如下： -----------");
for(IBook book:bookList){
System.out.println("书籍名称： " + book.getName()+"\t书籍作者： "
book.getAuthor()+"\t书籍价格： "+ formatter.format (book.getPrice()/100.0)+"元");
}
}
}
此时需求增加，需要对打折的书籍的价格进行特殊调整。
- 打折行为只会出现在打折书籍中，并不存在于所有书籍。所以不能改动 IBook 接口；
- 例如采购书籍人员也是要看价格的， 由于该方法已经实现了打折处理价格， 因此采购人员看到的也是打折后的价格， 会因信息不对称而出现决策失误的情况。 因此， 该方案也不是一个最优的方案。（说来惭愧，书上的这一段我没咋明白作者想表达的意思...）
此时需要构造一个新的类作为 NovelBook 的子类
public class OffNovelBook extends NovelBook {
public OffNovelBook(String _name,int _price,String _author){
super(_name,_price,_author);
}
//覆写销售价格
@Override
public int getPrice () {
//原价
int selfPrice = super.getPrice();
int offPrice = 0;
if (selfPrice > 4000) { //原价大于40元， 则打9折
offPrice = selfPrice * 90 /100;
} else {
offPrice = selfPrice * 80 /100;
}
return offPrice;
}
}
/* 业务流程类 */
public class BookStore {
private final static ArrayList bookList = new ArrayList();
//static静态模块初始化数据， 实际项目中一般是由持久层完成
static{
bookList.add(new OffNovelBook("天龙八部",3200,"金庸"));
bookList.add(new OffNovelBook("巴黎圣母院",5600,"雨果"));
bookList.add(new OffNovelBook("悲惨世界",3500,"雨果"));
bookList.add(new OffNovelBook("金瓶梅",4300,"兰陵笑笑生"));
}
//模拟书店买书
public static void main(String[] args) {
NumberFormat formatter = NumberFormat.getCurrencyInstance();
formatter.setMaximumFractionDigits(2);
System.out.println("-----------书店卖出去的书籍记录如下： -----------");
for(IBook book:bookList){
System.out.println("书籍名称： " + book.getName()+"\t书籍作者： "
}
}
}
在定义了新的子类之后，输入的图书列表对象可能存在正常的 NovelBook，也会有 OffNovelBook，无论存在什么，业务主流程还是无需改动的。关键点在于
在 BookStore 类中，也可以将 bookList 看做是一种外界输入，参数的类型为接口类型，main 方法中也是使用的是接口类型对象进行操作。
开闭原则的意义
- 主业务流程不会改动的太频繁
- 单测用例不需要频繁改动
- 提高复用性
- 提高可维护性