什么是设计原则？
?向对象过程中，前辈?咖们推荐的?些
指导性原则
，遵循这些原则可以让你的设计更有竞争力。
S.O.L.I.D 是面向对象设计（OOD）的头五大基本原则的首字母缩写，由俗称「鲍勃大叔」的 Robert C. Martin
提出。这些原则，结合在一起能够方便程序员开发易于维护和扩展的软件，也让开发人员轻松避免代码异味，易于重构代码，
也是敏捷或自适应软件开发的一部分。
注意：这只是一篇“欢迎来到S.O.L.I.D”的简单介绍文章，它只是揭示了S.O.L.I.D是什么。
S.O.L.I.D代表什么:
虽然缩略词展开后看似复杂，但其实非常容易掌握。
S – 单一职责原则
O – 开放封闭原则
L – 里氏替换原则
I – 接口隔离原则
D – 依赖倒置原则
让我们来单独看看每个原则，来理解为什么 S.O.L.I.D 能帮助我们成为更优秀的开发人员。
五大基本原则：
一、单?职责原则（SRP：Single Responsibility Principle）
背景：
单?职责原则，SRP?称单?功能原则，?向对象五个基本原则（SOLID）之?。它规定?个类应
该只有?个发?变化的原因。该原则由罗伯特·C·?丁（Robert C. Martin）于《敏捷软件开发：原
则、模式和实践》?书中给出的。
----------------------------------------------------------------------------------------------------------------------------------
定义：
1.?个模块只负责?件事。
2.?个类只负责?件事。
3.?个?法只负责?件事。
----------------------------------------------------------------------------------------------------------------------------------
如何遵守单?职责原则:
1.定义抽象?类
or
?类虚?法
2.?类继承后重写，不同的实现
何时遵循？何时不遵守？
1.类型逻辑?够简单，?法?够少，可以不遵守
2.类型复杂，?法很多，?定要遵循单?职责原则
----------------------------------------------------------------------------------------------------------------------------------
单?职责的优缺点:
优点
1,每个类相对简单，只负责??的事情。
2.需求变更时，只修改变更类，其他类不受影响。
缺点
1.代码量会有所增加
2.解读代码成本增加
----------------------------------------------------------------------------------------------------------------------------------
单?职责的不同层?:
1.以?法为单位
?个?法只负责?件事
?法中可以封装成?个新?法的，就封装成?个新?法
2.以类为单位
?个类只负责?件事
不属于该类的内容，创建新的类去封装
3.以模块
/
项?为单位
?个模块
/
项?只负责?件事
不属于该模块的内容，交由属于的模块去负责
----------------------------------------------------------------------------------------------------------------------------------
常?违背单?职责场景:
1.在?法中出现多个分?，分别去执?各?的逻辑，功能虽然可以实现。
2.但如果需求变更，就会?常的不稳定。
----------------------------------------------------------------------------------------------------------------------------------
实例：不同动物的叫声处理，喊叫?法中多个分?，还是不同类不同喊叫?法。
二、??替换原则（LSP：Liskov Substitution Principle）
背景：
??替换原则，
LSP
作为
OO
的?层原则，主张使?
“
抽象
(Abstraction)”
和
“
多态
(Polymorphism)”
将
设计中的静态结构改为动态结构，维持设计的封闭性。
“
抽象
”
是语?提供的功能。
“
多态
”
由继承语
义实现。
----------------------------------------------------------------------------------------------------------------------------------
定义：
1.任何使?基类的地?，都可以安全的去使?其?类。
2.?类有的内容，?类必须有【类的强继承】
3.如果?类出现了?类不应该有的内容，那么就应该断开两个类的继承关系 。然后，重新创建新的
?类，包含?类该拥有的内容
----------------------------------------------------------------------------------------------------------------------------------
?类必须有??的?为和特征：
1.?类已经实现的内容，?类不要再写【
不要使?
new
关键词隐藏?类?法
】
2.如果?类希望可以重写?类?法，?类?法?
abstruct
或
virtual
修饰
----------------------------------------------------------------------------------------------------------------------------------
实例：游戏??中的攻击?法，不能被不能攻击的?类继承。
三、依赖倒置原则（DIP：Dependence Inversion Principle）
背景：
依赖倒置原则（
Dependence Inversion Principle
）是程序要依赖于抽象接?，不要依赖于具体实
现。简单的说就是要求对抽象进?编程，不要对实现进?编程，这样就降低了客户与实现模块间的
耦合。
----------------------------------------------------------------------------------------------------------------------------------
定义：
?层模块不应该依赖于低层模块，两者应该
依赖抽象
，?不是依赖细节。
?层：?法调??
底层：被调??
----------------------------------------------------------------------------------------------------------------------------------
?向抽象编程：
1.属性、字段、?法参数、返回值，?切都尽量使?抽象【类
/
接?】
2.抽象不变，?层就不变
3.抽象?般是稳定的，低层的扩展变化不会影响到?层，低层就可以横向的?由扩展，架构稳定
80%
的设计模式跟抽象有关
----------------------------------------------------------------------------------------------------------------------------------
抽象的好处：
1.?个?法可以满?不同类型的参数传?
2.?持动态扩展，只要是实现了这个抽象，不需要修改上层
----------------------------------------------------------------------------------------------------------------------------------
实例：学?类实现不同?机的使??法，学?依赖?机，新?机出现时，学?类也要更新新?法。
不同的?机应该依赖抽象（?机），学?类也应该依赖于抽象（?机?户）
四、接?隔离原则（ISP：Interface Segregation Principle）
背景：
客户端不应该依赖它不需要的接?。?个类对另?个类的依赖应该建?在最?的接?上。
----------------------------------------------------------------------------------------------------------------------------------
定义：
1.使?多个专?的接??使?单?的总接?要好，但也不建议?个接?只对应?个?法。
2.?个类对另外?个类的依赖性应当是建?在
最?的接?
上的。
3.?个接?代表?个??，不应当将不同的??都交给?个接?。没有关系的接?合并在?起，
形成?个臃肿的?接?，这是对??和接?的污染。
----------------------------------------------------------------------------------------------------------------------------------
接?的正确定义：
1.既不能??全，也建议不能?个接??个?法
2.应该按照功能的密不可分来定义接?
3.应该是动态的，随业务变化?变化，设计的时候要留好提前量，避免抽象的变化
----------------------------------------------------------------------------------------------------------------------------------
实例：?机的核?功能就是打电话和发短信，拍照、上?等其他功能的接?，不要被?机所依赖。
参看
.Net
类中的接?的设计与实现
五、开闭原则（OCP：Open Closed Principle）【总则】
背景：
在?向对象编程领域中，开闭原则规定
“
软件中的对象（类，模块，函数等等）应该对于扩展是开
放的，但是对于修改是封闭的
”
，这意味着?个实体是允许在不改变它的源代码的前提下变更它的
?为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元
测试以及诸如此类的?以确保产品使?质量的过程。遵循这种原则的代码在扩展时并不发?改变，
因此?需上述的过程。
----------------------------------------------------------------------------------------------------------------------------------
定义：
对扩展开放，对修改关闭
扩展：添加新代码（类）
修改：修改原代码（类）
开闭原则是?个?标，没有任何?段，?被称为总则。
----------------------------------------------------------------------------------------------------------------------------------
为什么要遵循开闭原则：
?向对象语?是静态语?，最害怕变化，因为会波及很多东?。
最理想的就是新增类，对原代码没有改动，原有代码才是可信的。
----------------------------------------------------------------------------------------------------------------------------------
遇到需求变更该怎么办呢：
直接修改现有?法（最不可取）
增加?法（稍好?些）
增加类
（那更好啦）
增加类库
/
框架（那最好啦）
其他原则：
一、迪?特原则（LKP：Least Knowledge Principle ）
背景：
迪?特法则（
Law of Demeter
）?叫作最少知识原则（
Least Knowledge Principle
简写
LKP
），
?个类对于其他类知道的越少越好，就是说?个对象应当对其他对象有尽可能少的了解，只和朋友
通信，不和陌??说话。
----------------------------------------------------------------------------------------------------------------------------------
定义：
?个对象应该对其他对象保持
最少的了解
，只与直接朋友进?通信。
----------------------------------------------------------------------------------------------------------------------------------
类与类之间的关系：
纵向：继承关系
横向：聚合、组合、关联、
依赖
「出现在?法内部」
----------------------------------------------------------------------------------------------------------------------------------
?内聚、低耦合
降低耦合度的?法
1.
少使?类的继承，多?接?隐藏实现的细节。
2.
模块的功能化分尽可能的单?，道理也很简单，功能单?的模块供其它模块调?的机会就少。（其
实这是?内聚的?种说法，?内聚低耦合?般同时出现）。
3.
遵循?个定义只在?个地?出现。
4.
少使?全局变量。
5.
类属性和?法的声明少?
public
，多?
private
关键字。
6.
多?设计模式，?如采?
MVC
的设计模式就可以降低界?与业务逻辑的耦合度。
7.
尽量不?
“
硬编码
”
的?式写程序，同时也尽量避免直接?
SQL
语句操作数据库。
8.
最后当然就是避免直接操作或调?其它模块或类（内容耦合）；如果模块间必须存在耦合，原则上
尽量使?数据耦合，少?控制耦合，限制公共耦合的范围，避免使?内容耦合。
增强内聚度?法
1.
模块只对外暴露最?限度的接?，形成最低的依赖关系。
2.
只要对外接?不变，模块内部的修改，就不得影响其他模块。
3.
删除?个模块，应当只影响有依赖关系的其他模块，?不应该影响其他?关部分。
4.通过降低访问修饰符权限，减少联系，减少耦合
----------------------------------------------------------------------------------------------------------------------------------
实例：学校介绍
->
班级介绍
->
学?介绍，两两联系，学校不要与学?直接联系
二、合成复用原则（CRP: Composite Reuse Principle）
合成复用原则就是指在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，
使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。
又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。
它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
简言之：要尽量使用组合/聚合关系，少用继承。
合成复用原则的重要性：
通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。- 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
- 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
- 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。
采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。
- 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
- 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
- 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。
合成复用原则的实现方法：
合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。下面以汽车分类管理程序为例来介绍合成复用原则的应用。
【例1】汽车分类管理程序。
分析：汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。图 1 所示是用继承关系实现的汽车分类的类图。
图1 用继承关系实现的汽车分类的类图
从图 1 可以看出用继承关系实现会产生很多子类，而且增加新的“动力源”或者增加新的“颜色”都要修改源代码，这违背了开闭原则，显然不可取。但如果改用组合关系实现就能很好地解决以上问题，其类图如图 2 所示。
图2 用组合关系实现的汽车分类的类图