尚硅谷学习笔记——Java设计模式（一）设计模式七大原则

一、介绍

在软件工程中，设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，提出的解决方案。我们希望我们的软件能够实现复用性、高稳定性、扩展性、维护性、代码重用性，所以出现了设计模式的概念。

设计模式常用的七大原则：

1）单一职责原则

2）接口隔离原则

3）依赖倒转原则

4）里氏替换原则

5）开闭原则ocp

6）迪米特法则

7）合成复用原则

设计模式的目的：

1）代码重用性（即：相同功能的代码，不用多次编写）

2）可读性（即：编程规范性，便于其他程序员的阅读和理解）

3）可扩展性（即：需要增加新的功能时，非常方便）

4）可靠性（即：增加新的功能后，对原来的功能没有影响）

5）使程序呈现高内聚、低耦合的特性

二、单一职责原则

对一个类来说，一个类应该只负责一项职责。

1）降低类的复杂度，一个类只负责一项职责；

2）提高类的可读性，可维护性；

3）降低变更引起的风险；

4）通常情况下，我们应当遵守单一职责原则，只有逻辑足够简答，才能在代码级违反单一职责原则；只有类中的方法数量足够少，才可以在方法级别保持单一职责原则。

三、接口隔离原则

客户端不应该依赖它不需要的接口。即一个类对另一个类的依赖应该建立在最小的接口上。

改进前：

改进后：

四、依赖倒转原则

1）高层模块不应该依赖低层模块，二者都应该依赖其抽象；

2）抽象不应该依赖细节，细节应该依赖抽象；

3）依赖倒转（倒置）的中心思想是面相接口编程；

4）依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定得多。在java中，抽象就是接口或抽象类，细节就是具体的实现类；

5）使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展示细节的任务交给它们的实现类去完成。

改进前：

//方式1：实现Person接收消息的功能
class Person {public void receive(Email email) {System.out.println(email.getInfo());}
}

问题：如果我们获取的对方改变，Person也要增加相应的接受方法
解决思路：引入一个抽象的接口IReceiver，表示接受者，这样Person类与接口IReceiver发生依赖。其他实现都属于接收的范畴，只需各自实现IReceiver接口就可以。这样就符合依赖倒转原则

改进后：对接口进行依赖，稳定性提高

//方式2//定义接口
interface IReceiver {public String getInfo();
}class Email implements IReceiver {public String getInfo() {return "电子邮件信息：hello, world";}
}class Person {public void receive(IReceiver receiver) {System.out.println(receiver.getInfo());}
}public class DependencyReceiver {public static void main(String[] args) {//客户端无需改变Person person = new Person();person.receive(new Email());}
}

依赖传递的三种方式

依赖传递有三种方式，这里只写调用方法ChangHong changHong = new ChangHong();1）通过接口传递实现依赖
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.open(changHong);2）通过构造器进行依赖传递
OpenAndClose openAndClose = new OpenAndClose(changHong);
openAndClose.open();3）通过setter方法传递
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.setTv(changHong);
openAndClose.open();

五、里氏替换原则

继承性说明：

1）父类中凡是实现好的方法，实际上是某种规范和契约，虽然不强制所有子类必须遵守，但如果子类对这些已实现的方法进行任意修改，就会对整个继承体系造成破坏。

2）继承的弊端：使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性。如果一个类被其他类继承，当这个类需要修改时，必须考虑所有子类。且父类修改后，所有涉及到子类的功能都可能发生故障。

3）为了解决这一问题，我们提出里氏替换原则

里氏替换原则

1）如果每个类型为T1的对象O1，都有类型为T2的对象O2，使T1定义的所有程序P在所有对象O1被替换成O2时，程序P没有任何变化。那么T2是T1的子类型。也就是说，所有引用基类的地方必须能透明的使用其子类的对象。

2）在使用继承时，子类尽量不要重写父类的方法。

比如说，A类中有m1、m2、m3三个方法，B类继承A类，且重写了A类的所有方法，这样就无法做到透明化。

对此，我们可以让B类和A类共同继承一个更加基础的base类，使AB类耦合性降低，将AB类的公共方法提高base类中。

六、开闭原则

介绍：

1）开闭原则是编程中最基础、最重要的设计原则。

2）一个软件实体如类、模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节。

3）当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

4）编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则。

改进前：

//用于绘图的类
class GraphicEditor {//接受Shape对象，根据type绘制不同的图形public void drawShape(Shape s) {if(s.m_type == 1) drawRectangle(s);else if(s.m_type == 2) drawCircle(s);}public void drawRectangle(Shape s) {System.out.println("绘制矩形");}public void drawCircle(Shape s) {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;}
}public classOcp {public static void main(String[] args) {//存在的问题GraphicEditor graphicEditor = new GraphicEditor();graphicEditor.drawShape(new Rectangle());graphicEditor.drawShape(new Circle());}
}

存在的问题：

违反了设计模式的OCP原则，即对扩展开放，对修改关闭。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码。

思路：把shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现。这样当我们有新图形时，只需要让新的图形类继承shape、并实现draw方法。使用方的代码就不需要修改。

改进后：

//用于绘图的类
class GraphicEditor {//接受Shape对象，根据type绘制不同的图形public void drawShape(Shape s) {s.draw();}
}//Shape类，基类
abstract class Shape {int m_type;public abstract void draw();
}class Rectangle extends Shape {@Overridepublic void draw() {System.out.println("绘制矩形");}
}class Circle extends Shape {@Overridepublic void draw() {System.out.println("绘制圆形");}
}public classOcp {public static void main(String[] args) {//存在的问题GraphicEditor graphicEditor = new GraphicEditor();graphicEditor.drawShape(new Rectangle());graphicEditor.drawShape(new Circle());}
}

七、迪米特法则

基本介绍：

1）一个对象应该对其他对象保持最少的了解

2）类与类的关系越密切，耦合度越大

3）迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息。所以陌生的类最好不要以局部变量的形式出现在类的内部。

注意事项：

1）迪米特法则的核心是降低类之间的耦合。

2）由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间（对象间）耦合关系，并不是要求完全没有依赖关系。