1 设计模式七大准则
设计模式准则，其实就是程序员在编程时，该当恪守的准则，也是各种设计模式的根底(即：设计模式为什么这样设计的根据)
设计模式罕用的七大准则有:
- 繁多职责准则
- 接口隔离准则
- 依赖倒转(倒置)准则
- 里氏替换准则
- 开闭准则（OCP）
- 迪米特法令
- 合成复用准则
2 繁多职责准则
繁多职责准则（Single Responsibility Principle）
2.1 根本介绍
对类来说的，即一个类应该只负责一项职责。如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需要变更而扭转 A 时，可能造成职责 2 执行谬误，所以须要将类 A 的粒度合成为 A1，A2。
2.2 利用实例
以交通工具案例解说。
public class SingleResponsibility { public static void main(String[] args) { Vehicle vehicle = new Vehicle(); vehicle.run("摩托车"); vehicle.run("汽车"); vehicle.run("飞机"); }}/** * 交通工具类 * 1. 在此形式 的 run 办法中，违反了繁多职责准则 * 2. 解决的计划十分的简略，依据交通工具运行办法不同，分解成不同类即可 */class Vehicle { public void run(String vehicle) { System.out.println(vehicle + " 在公路上运行...."); }}解决办法1:
/** * 计划 1 的剖析 * 1. 恪守繁多职责准则 * 2. 然而这样做的改变很大，行将类合成，同时批改客户端 * 3. 改良：间接批改 Vehicle 类，改变的代码会比拟少=>计划 2 */public class SingleResponsibility { public static void main(String[] args) { RoadVehicle roadVehicle = new RoadVehicle(); roadVehicle.run("摩托车"); roadVehicle.run("汽车"); AirVehicle airVehicle = new AirVehicle(); airVehicle.run("飞机"); }}class RoadVehicle { public void run(String vehicle) { System.out.println(vehicle + "公路运行"); }}class AirVehicle { public void run(String vehicle) { System.out.println(vehicle + "天空运行"); }}class WaterVehicle { public void run(String vehicle) { System.out.println(vehicle + "水中运行"); }}解决办法2：
/** * 计划2 * 1. 这种批改办法没有对原来的类做大的批改，只是减少办法 * 2. 这里尽管没有在类这个级别上恪守繁多职责准则，然而在办法级别上，依然是恪守繁多职责（举荐是在类级别上的繁多职责） */public class SingleResponsibility { public static void main(String[] args) { Vehicle vehicle2 = new Vehicle(); vehicle2.run("汽车"); vehicle2.runWater("轮船"); vehicle2.runAir("飞机"); }}class Vehicle { public void run(String vehicle) { //解决 System.out.println(vehicle + " 在公路上运行...."); } public void runAir(String vehicle) { System.out.println(vehicle + " 在天空上运行...."); } public void runWater(String vehicle) { System.out.println(vehicle + " 在水中行...."); }}2.3 繁多职责准则注意事项和细节
- 升高类的复杂度，一个类只负责一项职责。
- 进步类的可读性，可维护性。
- 升高变更引起的危险。
- 通常状况下，咱们该当恪守繁多职责准则，只有逻辑足够简略，才能够在代码级违反繁多职责准则；只有类中办法数量足够少，能够在办法级别放弃繁多职责准则
繁多职责准则是绝对的，要放弃一个类的绝对的职责繁多。若类的复杂性不高，可适当违反繁多职责准则。在理论开发者能不必if else if else if 简单的分支就尽量不必，采纳类进行代替。
3 接口隔离准则
接口隔离准则（Interface Segregation Principle）
3.1 根本介绍
- 客户端不应该依赖它不须要的接口，即一个类对另一个类的依赖应该建设在最小的接口上。
- 先看一张图:
- 类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C来说不是最小接口，那么类 B 和类 D 必须去实现他们不须要的办法。
- 按隔离准则该当这样解决：
将接口 Interface1 拆分为独立的几个接口(这里咱们拆分成 3 个接口)，类 A 和类 C 别离与他们须要的接口建设依赖关系。也就是采纳接口隔离准则。
3.2 利用实例
- 类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，请编写代码实现此利用实例。
- 看代码-没有应用接口隔离准则代码。
public class Segregation1 { public static void main(String[] args) { }}//接口interface Interface1 { void operation1(); void operation2(); void operation3(); void operation4(); void operation5();}class B implements Interface1 { public void operation1() { System.out.println("B 实现了 operation1"); } public void operation2() { System.out.println("B 实现了 operation2"); } public void operation3() { System.out.println("B 实现了 operation3"); } public void operation4() { System.out.println("B 实现了 operation4"); } public void operation5() { System.out.println("B 实现了 operation5"); }}class D implements Interface1 { public void operation1() { System.out.println("D 实现了 operation1"); } public void operation2() { System.out.println("D 实现了 operation2"); } public void operation3() { System.out.println("D 实现了 operation3"); } public void operation4() { System.out.println("D 实现了 operation4"); } public void operation5() { System.out.println("D 实现了 operation5"); }}class A { //A 类通过接口 Interface1 依赖(应用) B 类，然而只会用到 1,2,3 办法 public void depend1(Interface1 i) { i.operation1(); } public void depend2(Interface1 i) { i.operation2(); } public void depend3(Interface1 i) { i.operation3(); }}class C { //C 类通过接口 Interface1 依赖(应用) D 类，然而只会用到 1,4,5 办法 public void depend1(Interface1 i) { i.operation1(); } public void depend4(Interface1 i) { i.operation4(); } public void depend5(Interface1 i) { i.operation5(); }}解决办法：
public class Segregation2 { public static void main(String[] args) { // 应用一把 A a = new A(); a.depend1(new B()); // A 类通过接口去依赖 B 类 a.depend2(new B()); a.depend3(new B()); C c = new C(); c.depend1(new D()); // C 类通过接口去依赖(应用)D 类 c.depend4(new D()); c.depend5(new D()); }}// 接 口 1interface Interface1 { void operation1();}// 接 口 2interface Interface2 { void operation2(); void operation3();}// 接 口 3interface Interface3 { void operation4(); void operation5();}class B implements Interface1, Interface2 { public void operation1() { System.out.println("B 实现了 operation1"); } public void operation2() { System.out.println("B 实现了 operation2"); } public void operation3() { System.out.println("B 实现了 operation3"); }}class D implements Interface1, Interface3 { public void operation1() { System.out.println("D 实现了 operation1"); } public void operation4() { System.out.println("D 实现了 operation4"); } public void operation5() { System.out.println("D 实现了 operation5"); }}// A 类通过接口 Interface1,Interface2 依赖(应用) B 类，然而只会用到 1,2,3 办法class A { public void depend1(Interface1 i) { i.operation1(); } public void depend2(Interface2 i) { i.operation2(); } public void depend3(Interface2 i) { i.operation3(); }}// C 类通过接口 Interface1,Interface3 依赖(应用) D 类，然而只会用到 1,4,5 办法class C { public void depend1(Interface1 i) { i.operation1(); } public void depend4(Interface3 i) { i.operation4(); } public void depend5(Interface3 i) { i.operation5(); }}3.3 应用接口隔离准则改良
- 类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C来说不是最小接口，那么类 B 和类 D 必须去实现他们不须要的办法。
- 将接口 Interface1 拆分为独立的几个接口，类 A 和类 C 别离与他们须要的接口建设依赖关系。也就是采纳接口隔离准则接口 Interface1 中呈现的办法，依据理论状况拆分为三个接口。
4 依赖倒转准则
4.1 根本介绍
依赖倒转准则(Dependence Inversion Principle)是指：
- 高层模块不应该依赖低层模块，二者都应该依赖其形象。
- 形象不应该依赖细节，细节应该依赖形象。依赖接口而不是实现。
- 依赖倒转(倒置)的中心思想是面向接口编程 。
- 依赖倒转准则是基于这样的设计理念：绝对于细节的多变性，形象的货色要稳固的多。以形象为根底搭建的架构比以细节为根底的架构要稳固的多。在 java 中，形象指的是接口或抽象类，细节就是具体的实现类。
- 应用接口或抽象类的目标是制订好标准，而不波及任何具体的操作，把展示细节的工作交给他们的实现类去实现。接口和抽象类的价值在于设计。
4.2 利用实例
请编程实现 Person 接管音讯的性能。
实现形式：
public class DependencyInversion { public static void main(String[] args) { Person person = new Person(); person.receive(new Email()); }}class Email { public String getInfo() { return "电子邮件信息: hello,world"; }}/** * 实现 Person 接管音讯的性能 * 形式 1 剖析 * 1. 简略，比拟容易想到 * 2. 如果咱们获取的对象是 微信，短信等等，则新增类，同时 Person 也要减少相应的接管办法 * 3. 解决思路：引入一个形象的接口 IReceiver, 示意接收者, 这样 Person 类与接口 IReceiver 产生依赖 * 因为 Email, WeiXin 等等属于接管的范畴，他们各自实现 IReceiver 接口就 ok, 这样咱们就符号依赖倒转准则 */class Person { public void receive(Email email) { System.out.println(email.getInfo()); }}优化（依赖倒转）:
public class DependencyInversion { public static void main(String[] args) { //客户端无需扭转 Person person = new Person(); person.receive(new Email()); person.receive(new WeiXin()); }}//定义接口interface IReceiver { String getInfo();}class Email implements IReceiver { public String getInfo() { return "电子邮件信息: hello,world"; }}//减少微信class WeiXin implements IReceiver { public String getInfo() { return "微信信息: hello,ok"; }}//形式 2class Person { //这里咱们是对接口的依赖，而不是间接依赖实现类。 public void receive(IReceiver receiver) { System.out.println(receiver.getInfo()); }}4.3 依赖倒转准则的注意事项和细节
- 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好。
- 变量的申明类型尽量是抽象类或接口, 这样咱们的变量援用和理论对象间，就存在一个缓冲层，利于程序扩大和优化。
- 继承时遵循里氏替换准则。
4.4 依赖关系传递的三种形式
1）接口传递；2）构造方法传递；3）setter办法传递；public class DependencyPass { public static void main(String[] args) { // 通过接口传递 ChangHong changHong1 = new ChangHong(); OpenAndClose openAndClose1 = new OpenAndClose(); openAndClose1.open(changHong1); //通过结构器进行依赖传递 OpenAndClose2 openAndClose = new OpenAndClose2(changHong1); openAndClose.open(); //通过 setter 办法进行依赖传递 OpenAndClose3 openAndClose3 = new OpenAndClose3(); openAndClose3.setTv(changHong1); openAndClose.open(); }}// 形式 1： 通过接口传递实现依赖// 开关的接口interface IOpenAndClose { //形象办法,接管接口 void open(ITV tv);}interface ITV { //ITV 接口 void play();}class ChangHong implements ITV { @Override public void play() { System.out.println("长虹电视机，关上"); }}// 实现接口class OpenAndClose implements IOpenAndClose { @Override public void open(ITV tv) { tv.play(); }}// 形式 2: 通过构造方法依赖传递// 开关的接口interface IOpenAndClose2 { //形象办法,接管接口 void open();}class OpenAndClose2 implements IOpenAndClose2 { public ITV tv; //成员 public OpenAndClose2(ITV tv) { //结构器 this.tv = tv; } @Override public void open() { this.tv.play(); }}// 形式 3 ,通过 setter 办法传递interface IOpenAndClose3 { void open(); void setTv(ITV tv);}class OpenAndClose3 implements IOpenAndClose3 { private ITV tv; @Override public void setTv(ITV tv) { this.tv = tv; } @Override public void open() { this.tv.play(); }}5 里氏替换准则
5.1 OO中的继承性的思考和阐明
- 继承蕴含这样一层含意：父类中但凡曾经实现好的办法，实际上是在设定标准和契约，尽管它不强制要求所有的子类必须遵循这些契约，然而如果子类对这些曾经实现的办法任意批改，就会对整个继承体系造成毁坏。
- 继承在给程序设计带来便当的同时，也带来了弊病。比方应用继承会给程序带来侵入性，程序的可移植性升高，减少对象间的耦合性，如果一个类被其余的类所继承，则当这个类须要批改时，必须思考到所有的子类，并且父类批改后，所有波及到子类的性能都有可能产生故障。
- 问题提出：在编程中，如何正确的应用继承? => 里氏替换准则
5.2 根本介绍
- 里氏替换准则(Liskov Substitution Principle)在 1988 年，由麻省理工学院的认为姓里的女士提出的。
- 如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。换句话说，所有援用基类的中央必须能通明地应用其子类的对象。
- 在应用继承时，遵循里氏替换准则，在子类中尽量不要重写父类的办法。
- 里氏替换准则通知咱们，继承实际上让两个类耦合性加强了，在适当的状况下，能够通过聚合，组合，依赖 来解决问题。
5.3 一个程序引出的问题和思考
看个程序, 思考下问题和解决思路：
public class Liskov { public static void main(String[] args) { A a = new A(); System.out.println("11-3=" + a.func1(11, 3)); System.out.println("1-8=" + a.func1(1, 8)); System.out.println("-----------------------"); B b = new B(); //这里本意是求出 11-3 System.out.println("11-3=" + b.func1(11, 3)); // 1-8 System.out.println("11+3+9=" + b.func2(11, 3)); System.out.println("1-8=" + b.func1(1, 8)); }}// A 类class A { // 返回两个数的差 public int func1(int num1, int num2) { return num1 - num2; }}// B 类继承了 Aclass B extends A { //这里，重写了 A 类的办法, 可能是有意识 public int func1(int a, int b) { return a + b; } // 减少了一个新性能：实现两个数相加,而后和 9 求和 public int func2(int a, int b) { return func1(a, b) + 9; }}5.4 解决办法
- 咱们发现原来运行失常的相减性能产生了谬误。起因就是类 B 无心中重写了父类的办法，造成原有性能呈现谬误。在理论编程中，咱们经常会通过重写父类的办法实现新的性能，这样写起来尽管简略，但整个继承体系的复用性会比拟差。特地是运行多态比拟频繁的时候。
- 通用的做法是：原来的父类和子类都继承一个更艰深的基类，原有的继承关系去掉，采纳依赖，聚合，组合等关系代替。
- 改良计划：
代码实现：
public class Liskov { public static void main(String[] args) { A a = new A(); System.out.println("11-3=" + a.func1(11, 3)); System.out.println("1-8=" + a.func1(1, 8)); System.out.println("-----------------------"); B b = new B(); //因为 B 类不再继承 A 类，因而调用者，不会再 func1 是求减法。调用实现的性能就会很明确 //这里本意是求出 11+3 System.out.println("11+3=" + b.func1(11, 3)); // 1+8 System.out.println("11+3+9=" + b.func2(11, 3)); System.out.println("1+8=" + b.func1(1, 8)); //应用组合依然能够应用到 A 类相干办法 System.out.println("11-3=" + b.func3(11, 3));// 这里本意是求出 11-3 }}//创立一个更加根底的基类class Base {//把更加根底的办法和成员写到 Base 类}// A 类class A extends Base { // 返回两个数的差 public int func1(int num1, int num2) { return num1 - num2; }}// B 类继承了 A// 减少了一个新性能：实现两个数相加,而后和 9 求和class B extends Base { //如果 B 须要应用 A 类的办法,应用组合关系 private A a = new A(); //这里，重写了 A 类的办法, 可能是有意识 public int func1(int a, int b) { return a + b; } public int func2(int a, int b) { return func1(a, b) + 9; } //咱们依然想应用 A 的办法 public int func3(int a, int b) { return this.a.func1(a, b); }}6 开闭准则
6.1 根本介绍
- 开闭准则（Open Closed Principle）是编程中最根底、最重要的设计准则。
- 一个软件实体如类，模块和函数应该对扩大凋谢(对提供方来说)，对批改敞开(对应用方来说)。用形象构建框架，用实现扩大细节。（在提供方扩大或者批改代码是，应用方不须要批改，能够了解为兼容）。
- 当软件须要变动时，尽量通过扩大软件实体的行为来实现变动，而不是通过批改已有的代码来实现变动。
- 编程中遵循其它准则，以及应用设计模式的目标就是遵循开闭准则。
6.2 看上面一段代码
- 看一个画图形的性能。类图设计，如下:
- 代码演示
public class Ocp { public static void main(String[] args) { // 应用看看存在的问题。之前提供 Rectangle、Circle，然而新增Triangle 必须要批改代码 GraphicEditor graphicEditor = new GraphicEditor(); graphicEditor.drawShape(new Rectangle()); graphicEditor.drawShape(new Circle()); graphicEditor.drawShape(new Triangle()); }}//这是一个用于绘图的类 [应用方]class GraphicEditor { //接管 Shape 对象，而后依据 type，来绘制不同的图形 public void drawShape(Shape s) { if (s.m_type == 1) drawRectangle(s); else if (s.m_type == 2) drawCircle(s); else if (s.m_type == 3) drawTriangle(s); } //绘制矩形 public void drawRectangle(Shape r) { System.out.println(" 绘制矩形 "); } //绘制圆形 public void drawCircle(Shape r) { System.out.println(" 绘制圆形 "); } //绘制三角形 public void drawTriangle(Shape r) { System.out.println(" 绘制三角形 "); }}//Shape 类，基类class Shape { int m_type;}class Rectangle extends Shape { Rectangle() { super.m_type = 1; }}class Circle extends Shape { Circle() { super.m_type = 2; }}//新增画三角形class Triangle extends Shape { Triangle() { super.m_type = 3; }}6.3 形式 1 的优缺点
- 长处是比拟好了解，简略易操作。
- 毛病是违反了设计模式的 ocp 准则，即对扩大凋谢(对提供方来说)，对批改敞开(对应用方来说)。即当咱们给类减少新性能的时候，尽量不批改代码，或者尽可能少批改代码。
- 比方咱们这时要新减少一个图形品种 三角形，咱们须要做如下批改，批改的中央较多
6.4 改良的思路剖析
思路：把创立 Shape 类做成抽象类，并提供一个形象的 draw 办法，让子类去实现即可，这样咱们有新的图形品种时，只须要让新的图形类继承 Shape，并实现 draw 办法即可，应用方的代码就不须要修 -> 满足了开闭准则。
改良后的代码：
public class Ocp { public static void main(String[] args) { // 应用看看存在的问题。之前提供 Rectangle、Circle，然而新增Triangle 必须要批改代码 GraphicEditor graphicEditor = new GraphicEditor(); graphicEditor.drawShape(new Rectangle()); graphicEditor.drawShape(new Circle()); graphicEditor.drawShape(new Triangle()); }}//这是一个用于绘图的类 [应用方]class GraphicEditor { //接管 Shape 对象，调用 draw 办法 public void drawShape(Shape s) { s.draw(); }}//Shape 类，基类abstract class Shape { int m_type; public abstract void draw();//形象办法}class Rectangle extends Shape { Rectangle() { super.m_type = 1; } @Override public void draw() { System.out.println(" 绘制矩形 "); }}class Circle extends Shape { Circle() { super.m_type = 2; } @Override public void draw() { System.out.println(" 绘制圆形 "); }}//新增画三角形class Triangle extends Shape { Triangle() { super.m_type = 3; } @Override public void draw() { System.out.println(" 绘制三角形 "); }}//新增一个图形class OtherGraphic extends Shape { OtherGraphic() { super.m_type = 4; } @Override public void draw() { System.out.println(" 绘制其它图形 "); }}7 迪米特法令
7.1 根本介绍
- 一个对象应该对其余对象放弃起码的理解。
- 类与类关系越亲密，耦合度越大。
- 迪米特法令(Demeter Principle)又叫起码晓得准则，即一个类对本人依赖的类晓得的越少越好。也就是说，对于被依赖的类不论如许简单，都尽量将逻辑封装在类的外部。对外除了提供的 public 办法，不对外泄露任何信息。
- 迪米特法令还有个更简略的定义：只与间接的敌人通信。
- 间接的敌人：每个对象都会与其余对象有耦合关系，只有两个对象之间有耦合关系，咱们就说这两个对象之间是敌人关系。耦合的形式很多，依赖，关联，组合，聚合等。其中，咱们称呈现成员变量，办法参数，办法返回值中的类为间接的敌人，而呈现在局部变量中的类不是间接的敌人。也就是说，生疏的类最好不要以局部变量的模式呈现在类的外部。
7.2 利用实例
- 有一个学校，上司有各个学院和总部，现要求打印出学校总部员工 ID 和学院员工的 id。
- 编程实现下面的性能, 看代码演示
- 代码演示：
public class Demeter { public static void main(String[] args) { // 创立了一个 SchoolManager 对象 SchoolManager schoolManager = new SchoolManager(); // 输入学院的员工 id 和 学校总部的员工信息 schoolManager.printAllEmployee(new CollegeManager()); }}//学校总部员工类class Employee { private String id; public void setId(String id) { this.id = id; } public String getId() { return id; }}//学院的员工类class CollegeEmployee { private String id; public void setId(String id) { this.id = id; } public String getId() { return id; }}// 学院员工的治理类class CollegeManager { //返回学院的所有员工 public List<CollegeEmployee> getAllEmployee() { List<CollegeEmployee> list = new ArrayList<>(); //这里咱们减少了 10 个员工到 list for (int i = 0; i < 10; i++) { CollegeEmployee emp = new CollegeEmployee(); emp.setId("学院员工 id= " + i); list.add(emp); } return list; }}/** * 学校治理类 * 剖析 SchoolManager 类的间接敌人类有哪些 Employee、CollegeManager * CollegeEmployee 不是 间接敌人 而是一个生疏类，这样违反了 迪米特法令 */class SchoolManager { //返回学校总部的员工 public List<Employee> getAllEmployee() { List<Employee> list = new ArrayList<>(); //这里咱们减少了 5 个员工到 list for (int i = 0; i < 5; i++) { Employee emp = new Employee(); emp.setId("学校总部员工 id= " + i); list.add(emp); } return list; } //该办法实现输入学校总部和学院员工信息(id) void printAllEmployee(CollegeManager sub) { /** * 剖析问题 * 1. 这 里 的 CollegeEmployee 不是 SchoolManager 的间接敌人 * 2. CollegeEmployee 是以局部变量形式呈现在 SchoolManager * 3. 违反了 迪米特法令 */ //获取到学院员工 List<CollegeEmployee> list1 = sub.getAllEmployee(); System.out.println("------------学院员工------------"); for (CollegeEmployee e : list1) { System.out.println(e.getId()); } //获取到学校总部员工 List<Employee> list2 = this.getAllEmployee(); System.out.println("------------学校总部员工------------"); for (Employee e : list2) { System.out.println(e.getId()); } }}7.3 利用实例改良
- 后面设计的问题在于 SchoolManager 中，CollegeEmployee 类并不是 SchoolManager 类的间接敌人 (剖析)。
- 依照迪米特法令，应该防止类中呈现这样非间接敌人关系的耦合。
- 对代码依照迪米特法令 进行改良.
- 代码演示：
public class Demeter { public static void main(String[] args) { // 创立了一个 SchoolManager 对象 SchoolManager schoolManager = new SchoolManager(); // 输入学院的员工 id 和 学校总部的员工信息 schoolManager.printAllEmployee(new CollegeManager()); }}//学校总部员工类class Employee { private String id; public void setId(String id) { this.id = id; } public String getId() { return id; }}//学院的员工类class CollegeEmployee { private String id; public void setId(String id) { this.id = id; } public String getId() { return id; }}// 学院员工的治理类class CollegeManager { //返回学院的所有员工 public List<CollegeEmployee> getAllEmployee() { List<CollegeEmployee> list = new ArrayList<>(); //这里咱们减少了 10 个员工到 list for (int i = 0; i < 10; i++) { CollegeEmployee emp = new CollegeEmployee(); emp.setId("学院员工 id= " + i); list.add(emp); } return list; } // 输 出 学 院 员 工 的 信 息 public void printEmployee() { //获取到学院员工 List<CollegeEmployee> list1 = getAllEmployee(); System.out.println("------------学院员工------------"); for (CollegeEmployee e : list1) { System.out.println(e.getId()); } }}/** * 学校治理类 * 剖析 SchoolManager 类的间接敌人类有哪些 Employee、CollegeManager * CollegeEmployee 不是 间接敌人 而是一个生疏类，这样违反了 迪米特法令 */class SchoolManager { //返回学校总部的员工 public List<Employee> getAllEmployee() { List<Employee> list = new ArrayList<>(); //这里咱们减少了 5 个员工到 list for (int i = 0; i < 5; i++) { Employee emp = new Employee(); emp.setId("学校总部员工 id= " + i); list.add(emp); } return list; } //该办法实现输入学校总部和学院员工信息(id) void printAllEmployee(CollegeManager sub) { /** * 剖析问题 * 1. 将输入逻辑写到 CollegeManager 类中，升高耦合性，这样SchoolManager 就不必感知依赖类的逻辑。 */ sub.printEmployee(); //获取到学校总部员工 List<Employee> list2 = this.getAllEmployee(); System.out.println("------------学校总部员工------------"); for (Employee e : list2) { System.out.println(e.getId()); } }}7.4 迪米特法令注意事项和细节
- 迪米特法令的外围是升高类之间的耦合
- 然而留神：因为每个类都缩小了不必要的依赖，因而迪米特法令只是要求升高类间(对象间)耦合关系， 并不是要求齐全没有依赖关系
8 合成复用准则（Composite Reuse Principle）
8.1 根本介绍
准则是尽量应用合成/聚合的形式，而不是应用继承。
如果只是让B类去应用A类的办法，应用继承就会让B和A的耦合性加强。
通过以下三种形式代替继承：1）依赖(合成)形式：能够在B类新建一个办法，把A实例传进来，而后调用A的办法。2）聚合形式：能够在B类减少全局变量，并通过set办法赋值；3）组合形式：在B的全局变量中，间接new 一个A对象，把A间接组合到B中。
9 设计准则核心思想
- 找出利用中可能须要变动之处，把它们独立进去，不要和那些不须要变动的代码混在一起。
- 针对接口编程，而不是针对实现编程。
- 为了交互对象之间的松耦合设计而致力。