设计模式六大原则(4)：接口隔离原则
28. 29. 30. 31. 32. 33. 34. 35.
接口隔离原则的含义是：建立单一接口，不要建立庞大 臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是 说，我们要为各个类建立专用的接口，而不要试图去建立一个 很庞大的接口供所有依赖它的类去调用。本文例子中，将一个 庞大的接口变更为3个专用的接口所采用的就是接口隔离原
public void method1() { System.out.println("类B实现接口I1的方法 1"); } public void method2() { System.out.println("类B实现接口I2的方法 2"); } public void method3() { System.out.println("类B实现接口I2的方法 3"); } }
ห้องสมุดไป่ตู้
44. public void depend3(I i){ 45. i.method5(); 46. } 47. } 48. 49. class D implements I{ 50. public void method1() { 51. System.out.println("类D实现接口I的方法 1"); 52. } 53. //对于类D来说，method2和method3不是必需的，但是 由于接口A中有这两个方法， 54. //所以在实现过程中即使这两个方法的方法体为空，也 要将这两个没有作用的方法进行实现。 55. public void method2() {} 56. public void method3() {} 57. 58. public void method4() { 59. System.out.println("类D实现接口I的方法 4"); 60. } 61. public void method5() { 62. System.out.println("类D实现接口I的方法 5"); 63. } 64. } 65. 66. public class Client{ 67. public static void main(String[] args){ 68. A a = new A(); 69. a.depend1(new B()); 70. a.depend2(new B()); 71. a.depend3(new B()); 72. 73. C c = new C(); 74. c.depend1(new D()); 75. c.depend2(new D()); 76. c.depend3(new D()); 77. } 78. }
interface I1 { public void method1(); } interface I2 { public void method2(); public void method3(); } interface I3 { public void method4(); public void method5(); } class A{ public void depend1(I1 i){ i.method1(); } public void depend2(I2 i){ i.method2(); } public void depend3(I2 i){ i.method3(); } } class B implements I1, I2{
33. 34. 35. 36. 37. class C{ 38. public void depend1(I i){ 39. i.method1(); 40. } 41. public void depend2(I i){ 42. i.method4(); 43. }
可以看到，如果接口过于臃肿，只要接口中出现的方 法，不管对依赖于它的类有没有用处，实现类中都必须去实现 这些方法，这显然不是好的设计。如果将这个设计修改为符合 接口隔离原则，就必须对接口I进行拆分。在这里我们将原有 的接口I拆分为三个接口，拆分后的设计如图2所示：
}
public public public public public
void void void void void
method1(); method2(); method3(); method4(); method5();
class A{ public void depend1(I i){ i.method1(); } public void depend2(I i){ i.method2(); } public void depend3(I i){ i.method3(); } } class B implements I{ public void method1() { System.out.println("类B实现接口I的方法 1"); } public void method2() { System.out.println("类B实现接口I的方法 2"); } public void method3() { System.out.println("类B实现接口I的方法 3"); } //对于类B来说，method4和method5不是必需的，但是 由于接口A中有这两个方法， //所以在实现过程中即使这两个方法的方法体为空，也 要将这两个没有作用的方法进行实现。 public void method4() {} public void method5() {} }
（图1 未遵循接口隔离原则的设计） 这个图的意思是：类A依赖接口I中的方法1、方法2、方 法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方 法4、方法5，类D是对类C依赖的实现。对于类B和类D来说， 虽然他们都存在着用不到的方法（也就是图中红色字体标记的 方法），但由于实现了接口I，所以也必须要实现这些用不到 的方法。对类图不熟悉的可以参照程序代码来理解，代码如 下：
（图2 遵循接口隔离原则的设计） 照例贴出程序的代码，供不熟悉类图的朋友参考：
[java] view plaincopy
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
设计模式六大原则（4）：接口隔离原则
分类： 设计模式2012-02-27 08:32 6517人阅读 评论(7) 收藏 举报
定义：客户端不应该依赖它不需要的接口；一个类对另一个类 的依赖应该建立在最小的接口上。 问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D， 如果接口I对于类A和类B来说不是最小接口，则类B和类D必须 去实现他们不需要的方法。 解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原 则。 举例来说明接口隔离原则：
则。在程序设计中，依赖几个专用的接口要比依赖一个综合的 接口更灵活。接口是设计时对外部设定的“契约”，通过分散定 义多个接口，可以预防外来变更的扩散，提高系统的灵活性和 可维护性。 说到这里，很多人会觉的接口隔离原则跟之前的单一职 责原则很相似，其实不然。其一，单一职责原则原注重的是职 责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责 原则主要是约束类，其次才是接口和方法，它针对的是程序中 的实现和细节；而接口隔离原则主要约束接口接口，主要针对 抽象，针对程序整体框架的构建。 采用接口隔离原则对接口进行约束时，要注意以下几 点： 接口尽量小，但是要有限度。对接口进行细化可以提 高程序设计灵活性是不挣的事实，但是如果过小，则 会造成接口数量过多，使设计复杂化。所以一定要适 度。 为依赖接口的类定制服务，只暴露给调用的类它需要 的方法，它不需要的方法则隐藏起来。只有专注地为 一个模块提供定制服务，才能建立最小的依赖关系。 提高内聚，减少对外交互。使接口用最少的方法去完 成最多的事情。 运用接口隔离原则，一定要适度，接口设计的过大或过小都不 好。设计接口的时候，只有多花些时间去思考和筹划，才能准 确地实践这一原则。
36. 37. 38. 39. class C{ 40. public void depend1(I1 i){ 41. i.method1(); 42. } 43. public void depend2(I3 i){ 44. i.method4(); 45. } 46. public void depend3(I3 i){ 47. i.method5(); 48. } 49. } 50. 51. class D implements I1, I3{ 52. public void method1() { 53. System.out.println("类D实现接口I1的方法 1"); 54. } 55. public void method4() { 56. System.out.println("类D实现接口I3的方法 4"); 57. } 58. public void method5() { 59. System.out.println("类D实现接口I3的方法 5"); 60. } 61. }
[java] view plaincopy
1. interface I {
2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.
本文转自 csdn：/nmgzhangds/article/details/7299254
PHP常用的五种设计模式及应用场景
PHP常⽤的五种设计模式及应⽤场景设计模式六⼤原则开放封闭原则：⼀个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
⾥⽒替换原则：所有引⽤基类的地⽅必须能透明地使⽤其⼦类的对象.依赖倒置原则：⾼层模块不应该依赖低层模块，⼆者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
单⼀职责原则：不要存在多于⼀个导致类变更的原因。
通俗的说，即⼀个类只负责⼀项职责。
接⼝隔离原则：客户端不应该依赖它不需要的接⼝；⼀个类对另⼀个类的依赖应该建⽴在最⼩的接⼝上。
迪⽶特法则：⼀个对象应该对其他对象保持最少的了解。
1.单例设计模式所谓单例模式，即在应⽤程序中最多只有该类的⼀个实例存在，⼀旦创建，就会⼀直存在于内存中！单例设计模式常应⽤于数据库类设计，采⽤单例模式，只连接⼀次数据库，防⽌打开多个数据库连接。
⼀个单例类应具备以下特点：单例类不能直接实例化创建，⽽是只能由类本⾝实例化。
因此，要获得这样的限制效果，构造函数必须标记为private，从⽽防⽌类被实例化。
需要⼀个私有静态成员变量来保存类实例和公开⼀个能访问到实例的公开静态⽅法。
在PHP中，为了防⽌他⼈对单例类实例克隆，通常还为其提供⼀个空的私有__clone()⽅法。
使⽤场景：只实例化⼀次，内部实例化，对外只有⼀个开放⽅法，只能通过调取该⽅法进⾏调取实例化对象。
数据库连接单例模式的例⼦：<?php/*** Singleton of Database*/class Database{// We need a static private variable to store a Database instance.private static $instance;// Mark as private to prevent it from being instanced.private function__construct(){// Do nothing.}private function__clone(){// Do nothing.}public static function getInstance(){if (!(self::$instance instanceof self)) {self::$instance = new self();}return self::$instance;}}$a = Database::getInstance();$b = Database::getInstance();// truevar_dump($a === $b);2.⼯⼚设计模式⼯⼚模式是另⼀种⾮常常⽤的模式，正如其名字所⽰：确实是对象实例的⽣产⼯⼚。
设计模式7大原则
设计模式7大原则设计模式的7大原则是指：1. 开放-封闭原则（Open-Closed Principle，OCP）：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。
即在向系统添加新的功能时，不应该修改原有的代码。
2. 单一职责原则（Single Responsibility Principle，SRP）：一个类应该只有一个引起它变化的原因。
即一个类应该只有一个职责，如果一个类承担了多个职责，就增加了它被修改的风险。
3. 里氏替换原则（Liskov Substitution Principle，LSP）：子类型必须能够替换它们的父类型。
也就是说，子类必须完全实现父类的方法，同时还可以在不违反原有功能的情况下进行扩展。
4. 依赖倒置原则（Dependency Inversion Principle，DIP）：高层模块不应该依赖于低层模块，而是应该依赖于抽象。
抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
5. 接口隔离原则（Interface Segregation Principle，ISP）：客户端不应该依赖它不需要的接口。
即一个类对另一个类的依赖应该建立在最小的接口上，而不是依赖于多个不相关的接口。
6. 迪米特法则（Law of Demeter，LoD）：一个对象应该对其他对象保持最少的了解。
即一个对象应该只与其密切的朋友进行通信，而不与非直接相关的对象进行通信。
7. 合成复用原则（Composite Reuse Principle，CRP）：尽量使用对象组合，而不是继承来达到复用的目的。
通过对象组合可以在运行时动态改变对象的行为，而继承是在编译时静态定义的。
java架构设计原则
java架构设计原则
Java架构设计原则是指在进行Java软件架构设计时需要遵循的一系列规则和准则。
这些原则包括：
1. 单一职责原则（SRP）：每个类或模块应该有一个明确的职责，而且该职责应该由该类或模块完全承担。
2. 开放封闭原则（OCP）：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。
意思是新增功能应该通过扩展现有对象来实现，而不是直接修改现有对象。
3. 里式替换原则（LSP）：子类型必须能够替换掉它们的父类型，而且程序不会出错。
4. 接口隔离原则（ISP）：不应该强迫客户端依赖于它们不需要的接口。
模块之间的依赖关系应该建立在最小的接口上。
5. 依赖倒置原则（DIP）：高层模块不应该依赖于底层模块，它们应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
6. 迪米特法则（LoD）：一个对象应该对其他对象有尽可能少的了解。
一个类应该对自己需要耦合或调用的类知道得最少，减少类间耦合。
7. 合成复用原则（CRP）：尽量使用对象组合，而不是继承来达到复用的目的。
复用时应该优先考虑使用组合或聚合等方式。
这些Java架构设计原则能够提高软件的可维护性、可扩展性、灵活性和可读性，使得软件架构更加合理和健康。
设计模式的设计原则
设计模式的设计原则设计模式的设计原则是指在软件设计过程中，根据经验总结出来的一些指导性原则，用于指导设计者进行合理的设计决策，以提高软件的可维护性、可扩展性和可复用性。
本文将介绍五个常用的设计原则，包括单一职责原则、开放封闭原则、里氏替换原则、依赖倒置原则和接口隔离原则。
一、单一职责原则单一职责原则（Single Responsibility Principle，SRP）要求一个类只负责一个功能或职责。
这样可以提高类的内聚性，降低类的耦合性，使类更加易于理解、扩展和维护。
例如，在一个图书馆管理系统中，应该将图书的借阅和归还功能分别封装到不同的类中，而不是将这两个功能都放在同一个类中。
二、开放封闭原则开放封闭原则（Open-Closed Principle，OCP）要求软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。
这意味着当需要添加新功能时，应该通过扩展已有的代码来实现，而不是修改已有的代码。
通过遵守这一原则，可以保证软件的稳定性和可维护性。
例如，在一个电商平台中，如果需要添加一种新的支付方式，应该通过添加新的支付类来实现，而不是修改现有的支付类。
三、里氏替换原则里氏替换原则（Liskov Substitution Principle，LSP）要求子类对象必须能够替换掉父类对象，并且程序的逻辑不应该发生变化。
也就是说，在使用继承关系时，子类应该保持父类的行为和接口，不能改变父类的功能。
通过遵守这一原则，可以提高代码的可复用性和可扩展性。
例如，在一个图形绘制程序中，矩形类是一个子类，如果矩形类的实例不能替换掉父类（如图形类）的实例，那么就违反了里氏替换原则。
四、依赖倒置原则依赖倒置原则（Dependency Inversion Principle，DIP）要求高层模块不应该依赖低层模块，两者都应该依赖于抽象。
抽象不应该依赖于具体实现细节，具体实现细节应该依赖于抽象。
通过遵守这一原则，可以降低模块间的耦合性，提高系统的扩展性和可维护性。
UML和设计模式六大原则
UML和设计模式六⼤原则UML：UML是⼀种为⾯向对象系统的产品进⾏说明、可视化和编制⽂档的⼀种标准语⾔，是⾮专利的第三代建模和规约语⾔。
UML是⾯向对象设计的建模⼯具，独⽴于任何具体程序设计语⾔。
UML作为⼀种统⼀的软件建模语⾔具有⼴泛的建模能⼒。
UML不仅是在消化、吸收、提炼⾄今存在的所有软件建模语⾔的基础上提出的，UML还突破了软件的限制，⼴泛吸收了其他领域的建模⽅法。
UML⽴⾜于对事物的实体、性质、关系、结构、状态和动态变化过程的全程描述和反映。
UML可以建⽴需求模型、逻辑模型、设计模型和实现模型等，但UML在建⽴领域模型⽅⾯存在不⾜，需要进⾏补充。
作为⼀种建模语⾔，UML有严格的语法和语义规范。
UML建⽴在元模型理论基础上，包括4层元模型结构，分别是基元模型、元模型、模型和⽤户对象。
4层结构层层抽象，下⼀层是上⼀层的实例。
UML中的所有概念和要素均有严格的语义规范。
UML采⽤⼀组图形符号来描述软件模型，这些图形符号具有简单、直观和规范的特点，开发⼈员学习和掌握起来⽐较简单。
所描述的软件模型，可以直观地理解和阅读，由于具有规范性，所以能够保证模型的准确、⼀致。
UML系统开发中有三个主要的模型：功能模型：从⽤户的⾓度展⽰系统的功能，包括⽤例图。
对象模型：采⽤对象，属性，操作，关联等概念展⽰系统的结构和基础，包括类别图、对象图。
动态模型：展现系统的内部⾏为。
包括序列图，活动图，状态图。
设计模式：设计模式，是⼀套被反复使⽤、多数⼈知晓的、经过分类编⽬的、代码设计经验的总结。
使⽤设计模式是为了可重⽤代码、让代码更容易被他⼈理解、保证代码可靠性、程序的重⽤性。
⼤家都开始注意设计模式。
那么，到底我们为什么要⽤设计模式呢？根本原因是为了代码复⽤，增加可维护性。
六⼤设计原则：⼀、单⼀职责原则就⼀个类⽽⾔，应该仅有⼀个引起它变化的原因。
做编程的时候，如果讲每⼀个类加上各种各样的功能就意味着，⽆论任何需求要来，你都需要更改这个类，这样会让维护⾮常⿇烦，复⽤不可能，也缺乏灵活性。
设计模式6大原则
设计模式6大原则
1、开闭原则（Open Close Principle）：一个软件实体应该对扩展开放，对修改关闭。
也就是说，它允许进行功能的扩展，但是不允许进行修改。
2、里氏替换原则（Liskov Substitution Principle）：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
3、依赖倒转原则（Dependence Inversion Principle）：高层模块不应该依赖低层模块，二者都应该依赖其抽象。
4、接口隔离原则（Interface Segregation Principle）：使用多个专门的接口，而不使用单一的总接口。
5、迪米特法则（Law Of Demeter）：一个对象应该对其他对象有最少的了解，只和朋友交流，不和陌生人说话。
6、合成复用原则（Composite Reuse Principle）：尽量使用合成/聚合的方式，而不是使用继承。
设计模式：面向对象设计的六大原则（绝对详细）
设计模式：⾯向对象设计的六⼤原则（绝对详细）⽬录前⾔很久没有写博客了，⼀直给⾃⼰找借⼝说太忙了，过⼏天有空再写，⼏天之后⼜⼏天，时间就这么快速的消逝。
说到底就是⾃⼰太懒了，不下点决⼼真是不⾏。
我决定逼⾃⼰⼀把，从今天开始学习设计模式系列，并写成博⽂记录下来，做不到的话，就罚⾃⼰⼀个⽉不玩游戏 (作孽啊。
)六⼤原则⾔归正传，这是我学习设计模式系列的第⼀篇⽂章，本⽂主要讲的是⾯向对象设计应该遵循的六⼤原则，掌握这些原则能帮助我们更好的理解⾯向对象的概念，也能更好的理解设计模式。
这六⼤原则分别是：单⼀职责原则——SRP开闭原则——OCP⾥式替换原则——LSP依赖倒置原则——DIP接⼝隔离原则——ISP迪⽶特原则——LOD单⼀职责原则单⼀职责原则，Single Responsibility Principle，简称SRP。
其定义是应该有且仅有⼀个类引起类的变更，这话的意思就是⼀个类只担负⼀个职责。
举个例⼦，在创业公司⾥，由于⼈⼒成本控制和流程不够规范的原因，往往⼀个⼈需要担任N个职责，⼀个⼯程师可能不仅要出需求，还要写代码，甚⾄要⾯谈客户，光背的锅就好⼏种，简单⽤代码表达⼤概如此：public class Engineer {public void makeDemand(){}public void writeCode(){}public void meetClient(){}}代码看上去好像没什么问题，因为我们平时就是这么写的啊，但是细读⼀下就能发现，这种写法很明显不符合单⼀职责的原则，因为引起类的变化不只有⼀个，⾄少有三个⽅法都可以引起类的变化，⽐如有天因为业务需要，出需求的⽅法需要加个功能 (⽐如需求的成本分析)，或者是见客户也需要个参数之类的，那样⼀来类的变化就会有多种可能性了，其他引⽤该类的类也需要相应的变化，如果引⽤类的数⽬很多的话，代码维护的成本可想⽽知会有多⾼。
所以我们需要把这些⽅法拆分成独⽴的职责，可以让⼀个类只负责⼀个⽅法，每个类只专⼼处理⾃⼰的⽅法即可。
Python6大设计原则
Python6⼤设计原则内容总览六⼤设计原则都有哪些⼀、单⼀职责原则⼆、⾥⽒替换原则三、依赖倒置原则四、接⼝隔离原则五、迪⽶特法则六、开放封闭原则内容详解⼀、单⼀职责原则单⼀职责原则：英⽂名称是Single Responsiblity Principle，简称是SRP。
定义：应该有且仅有⼀个原因引起类的变更。
单⼀职责原则要求：⼀个接⼝或类只有⼀个原因引起变化，也就是⼀个接⼝或类只有⼀个职责，它就负责⼀件事情。
单⼀职责原则的好处：1. 类的复杂性降低，实现什么职责都有清晰明确的定义；2. 可读性提⾼，复杂性降低，那当然可读性提⾼了；3. 可维护性提⾼，可读性提⾼，那当然更容易维护了；4. 变更引起的风险降低，变更是必不可少的，如果接⼝的单⼀职责做得好，⼀个接⼝修改只对相应的实现类有影响，对其他的接⼝⽆影响，这对系统的扩展性、维护性都有⾮常⼤的帮助。
注意：单⼀职责原则提出了⼀个编写程序的标准，⽤“职责”或“变化原因”来衡量接⼝或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项⽬⽽异，因环境⽽异。
对于单⼀职责原则，接⼝⼀定要做到单⼀职责，类的设计尽量做到只有⼀个原因引起变化。
⼆、⾥⽒替换原则⾥⽒替换原则（Liskov Substitution Principle，LSP），有两种定义：第⼀种定义，也是最正宗的定义：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T ,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果对每⼀个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的⾏为没有发⽣变化，那么类型S是类型T的⼦类型。
设计模式六大规则
设计模式六⼤规则1.单⼀职责原则（六⼤规则中的⼩萝莉，⼈见⼈爱）：描述的意思是每个类都只负责单⼀的功能，切不可太多，并且⼀个类应当尽量的把⼀个功能做到极致。
2.⾥⽒替换原则（六⼤原则中最⽂静的姑娘，但却不太招⼈喜欢）：这个原则表达的意思是⼀个⼦类应该可以替换掉⽗类并且可以正常⼯作。
3. 接⼝隔离原则（六⼤原则当中最挑三拣四的挑剔⼥，胸部极⼩）：也称接⼝最⼩化原则，强调的是⼀个接⼝拥有的⾏为应该尽可能的⼩。
4.依赖倒置原则（六⼤原则中最⼩鸟依⼈的姑娘，对抽象的东西⾮常依赖）：这个原则描述的是⾼层模块不该依赖于低层模块，⼆者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。
5.迪⽶特原则（六⼤原则中最害羞的姑娘，不太爱和陌⽣⼈说话）：也称最⼩知道原则，即⼀个类应该尽量不要知道其他类太多的东西，不要和陌⽣的类有太多接触。
6.开-闭原则（六⼤原则中绝对的⼤姐⼤，另外五姐妹⼼⽢情愿⾂服）：最后⼀个原则，⼀句话，对修改关闭，对扩展开放。
《简介》说到设计模式，当初第⼀次听到时，第⼀反应就是很深奥，完全理解不了这个概念到底是什么意思，下⾯我先从⽹上摘录⼀份定义。
设计模式（Designpattern）是⼀套被反复使⽤、多数⼈知晓的、经过分类编⽬的、代码设计经验的总结。
上⾯是百度当中的解释，来解释⼀下这句简单的话的含义，⼏个关键词。
反复使⽤：这个不⽤过多解释，设计模式被使⽤太多了，上个系列spring源码当中就出现了很多模式，记忆中⽐较深刻的有模板模式，代理模式，单例模式，⼯⼚模式等等。
多数⼈知晓：这个就不需要过多解释了。
分类编⽬：就是说可以找到⼀些特征去划分这些设计模式，从⽽进⾏分类。
代码设计经验：这句很重要，设计经验的总结，也就是说设计模式，是为了指导设计⽽从经验中总结出来的套路。
还有⼀种说法是说，设计模式是可以解决特定场景的问题的⼀系列⽅法，其实我觉得这个解释更贴切⼀点。
《为何学习设计模式》上⾯简单的介绍，是让各位⾸先搞清楚设计模式是什么，下⾯我们来说说为什么要学习设计模式，学习总要有个驱动⼒。
程序设计模式六大原则--个人理解
程序设计模式六⼤原则--个⼈理解
原则⼀：单⼀原则
理解：解决代码耦合度，每个⽅法只做⼀件事，尽可能把⼀个功能放在⼀个模块⾥⾯
吃饭就是吃饭，睡觉就是睡觉
原则⼆：⾥⽒替换原则
原则三：依赖倒置原则
理解：多个⼦类继承⽗类时，⽗类只提供模型（全部⼦类的相同功能），剩余的⼦类去实现
原则四：接⼝隔离原则
理解：⽗类只有接⼝的声明，没有⽅法的具体实现，⽅法的具体实现交个⼦类
原则五：迪⽶特法则
原则六：开闭原则
总结：
1.在程序设计的时候，职责尽可能独⽴，不要混在⼀起。
2.如果⼀个功能⽤到很多次，尽可能⽤继承，但继承不能够去覆写⽗类的内容
3.为了使代码更健壮，拓展性更好，尽可能写抽象/接⼝，具体实现交个⼦类
4.如果要去继承⼀个接⼝，要尽可能的⽤“最⼩的接⼝”
5.类和类之间，为了彼此拓展性更好，耦合性更低，要减少对彼此的“认识”
6.在做功能或者项⽬修改的时候，⼀般的话，不是在原有的代码去改，这样⼯程量太⼤，通常的做法是去拓展，原来⾥⾯的需要的东西，就继承，原来⾥⾯没有的，就⾃⼰写。