共计 15746 个字符，预计需要花费 40 分钟才能阅读完成。
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());
}
}
// 接 口 1
interface Interface1 {void operation1();
}
// 接 口 2
interface Interface2 {void operation2();
void operation3();}
// 接 口 3
interface 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";}
}
// 形式 2
class 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 类继承了 A
class 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 设计准则核心思想
- 找出利用中可能须要变动之处，把它们独立进去，不要和那些不须要变动的代码混在一起。
- 针对接口编程，而不是针对实现编程。
- 为了交互对象之间的松耦合设计而致力。
正文完
