设计模式之设计原则

7大设计原则

设计模式是凌驾于任何开发语言之上的给你编程思想增加一些新的招数，让你站在巨人的肩膀上充分发挥你的硬技能。。。。。。言归正传。。。。

下面是我看《设计模式之禅（第2版）》记录的读书笔记，供大家参考。

设计模式是什么？它是一套理论，由软件界的先辈们（The Gang of Four：包括Erich
Gamma、Richard Helm、Ralph Johnson、John Vlissides）总结出的一套可以反复使用的经验，它可以提高代码的可重用性，增强系统的可维护性，以及解决一系列的复杂问题。做软件的人都知道需求是最难把握的，我们可以分析现有的需求，预测可能发生的变更，但是我们不能控制需求的变更

设计原则名称	定 义	使用频率
单一职责原则	应该有且仅有一个原因引起类的变更	★★★★☆
里氏代换原则	所有引用基类的地方必须能透明地使用其子类的对象	★★★★★
依赖倒置原则	抽象不应该依赖于细节，细节应该依赖于抽象	★★★★★
接口隔离原则	使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口	★★☆☆☆
迪米特法则	一个软件实体应当尽可能少地与其他实体发生相互作用	★★★☆☆
开闭原则	软件实体应对扩展开放，而对修改关闭	★★★★★
合成复用原则	尽量使用对象组合，而不是继承来达到复用的目的	★★★★☆

1. 单一职责原则 (Single Responsibility Principle, SRP)

接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

优点：
● 类的复杂性降低，实现什么职责都有清晰明确的定义；
● 可读性提高，复杂性降低，那当然可读性提高了；
● 可维护性提高，可读性提高，那当然更容易维护了；
● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修
改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大
的帮助。

2. 里氏替换原则 (Liskov Substitution Principle, LSP)

定义（一）：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
定义（一）：所有引用基类的地方必须能透明地使用其子类的对象

比如：List和Map都能透明的使用子类对象。

策略者模式就是遵循了里仕替换原则，后续我会自己手动撸代码供大家参考理解

优点：
● 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
● 提高代码的重用性；
● 子类可以形似父类，但又异于父类，“龙生龙，凤生凤，老鼠生来会打洞”是说子拥有
父的“种”，“世界上没有两片完全相同的叶子”是指明子与父的不同；
● 提高代码的可扩展性，实现父类的方法就可以“为所欲为”了，君不见很多开源框架的
扩展接口都是通过继承父类来完成的；
● 提高产品或项目的开放性。
自然界的所有事物都是优点和缺点并存的，即使是鸡蛋，有时候也能挑出骨头来，继承
的缺点如下：
● 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法；
● 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约
束；
● 增强了耦合性。当父类的常量、变量和方法被修改时，需要考虑子类的修改，而且在
缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大段的代码需要重构

注意：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发
生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承

3. 依赖倒置原则（Dependence Inversion Principle,DIP）

说白了就是人们常说的面向接口编程（Object-Oriented Design，OOD）
定义三层含义：
● 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
● 抽象不应该依赖细节；
● 细节应该依赖抽象。

比如：Java中的接口和抽象类就是符合依赖倒置原则，有效降低耦合，提升系统稳定性。

遵循以下的几个规则就可以：
● 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
这是依赖倒置的基本要求，接口和抽象类都是属于抽象的，有了抽象才可能依赖倒置。
● 变量的表面类型尽量是接口或者是抽象类
● 任何类都不应该从具体类派生
● 尽量不要覆写基类的方法
● 结合里氏替换原则使用

接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

4. 接口隔离原则（Interface Segregation Principle, ISP）

定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口

可以根据以下几个规则来衡量：
● 一个接口只服务于一个子模块或业务逻辑；
● 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨
肉”，而不是“肥嘟嘟”的一大堆方法；
● 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化
处理；
● 了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。千万别，环境不同，接口拆分的标准就不同。深入了解业务逻辑，最好的接口设
计就出自你的手中！

5. 迪米特法则（LeastKnowledge Principle, LKP）

迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP），虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以
提高。

如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中

6. 开闭原则(Open-Closed Principle, OCP)

定义：
一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。软件实体可以指一个软件模块、一个由多个类0组成的局部结构或一个独立的类。

7.合成复用原则（Composite Reuse Principle, CRP）

定义：尽量使用对象组合，而不是继承来达到复用的目的。

理解即可。。。