设计模式七大原则及代码示例
七大原则：
- 单一职责原则；
- 接口隔离原则；
- 依赖倒转原则；
- 里氏替换原则；
- 开闭原则ocp；
- 迪米特法则；
- 合成复用原则。
设计模式其实包含了面向对象的精髓，封装、继承、多态。
一、单一职责原则
对于类来说，一个类应该只负责一项职责。
假设A负责两个不同的职责1和2，如果1的内容需要改变，影响了2，那可能2会执行错误，所以需要将A分为两个类。
1.1 示例
public class SingleResponsibility1 {
public static void main(String[] args) {
Vehicle vehicle = new Vehicle();
vehicle.run("汽车");
vehicle.run("摩托车");
vehicle.run("飞机");
}
}
class Vehicle{
public void run(String vehicle){
System.out.println(vehicle+"在地上跑");
}
}
对于一个完成交通工具的类Vehicle来说，显然对不同的对象、汽车和飞机，提供的服务不应该都是在地上跑，并且修改之后，肯定会影响到其中一类对象的功能，所以按照单一职责，那就应该拆开，成两个类。
1.2 改进版本 1
public class SingleResponsibility2 {
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+"在天上飞");
}
}
但是这么写又有了新的问题：那就是类分解的时候，客户端代码也要改，调用方式改了。因此可以直接更改本来的Vehicle类，变成我们的第三种写法.
1.3 改进版本 2
public class SingleResponsibility3 {
public static void main(String[] args) {
Vehicle2 vehicle2 = new Vehicle2();
vehicle2.runRoad("汽车");
vehicle2.runWater("轮船");
vehicle2.runAir("飞机");
}
}
class Vehicle2{
public void runRoad(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更合适。
1.4 总结单一职责原则
- 降低类的复杂度，一个类只负责一项职责（上面的例子因为过于简单，所以看起来第三个写法更有效）；
- 提高类的可读性、可维护性，降低变更带来的风险；
- 通常情况下，我们应该遵守这个职责，只有在逻辑足够简单的时候，才可以在代码级别违反这个原则，也就是上面的，改为在方法级别保持单一职责原则。
二、接口隔离原则
接口隔离（Interface Segregation Principle）
意思是说，如果某一个类对另一个类的依赖通过的是接口，那么这个类对另一个类的依赖应该建立在最小的接口上，如果不是最小接口，则需要拆。
2.1 示例
例如如下的用例图：
A 和 B 是 Interface1 的实现类，所以必须实现它的 4 个方法，C 和 D 分别依赖于这个接口，使用 A 和 B 里面对应的方法，但不是全部，C 使用前三个方法，D 使用后三个方法，如果按照类图实现，代码会如下所示：
interface Interface1{
void fuc1();
void fuc2();
void fuc3();
void fuc4();
}
class A implements Interface1{
public void fuc1() {System.out.println("A实现了fuc1");}
public void fuc2() {System.out.println("A实现了fuc2");}
public void fuc3() {System.out.println("A实现了fuc3");}
public void fuc4() {System.out.println("A实现了fuc4");}
}
class B implements Interface1{
public void fuc1() {System.out.println("B实现了fuc1");}
public void fuc2() {System.out.println("B实现了fuc2");}
public void fuc3() {System.out.println("B实现了fuc3");}
public void fuc4() {System.out.println("B实现了fuc4");}
}
//C通过接口Interface1依赖，使用A这个实现类，但是只用A的前两个方法
class C {
public void depend1(Interface1 i){
i.fuc1();
}
public void depend2(Interface1 i){
i.fuc2();
}
public void depend3(Interface1 i){
i.fuc3();
}
}
//D通过接口Interface1依赖，使用B这个实现类，但是只用B的后两个方法
class D {
public void depend2(Interface1 i){
i.fuc2();
}
public void depend3(Interface1 i){
i.fuc3();
}
public void depend4(Interface1 i){
i.fuc4();
}
}
显然，A 和 B 两个实现类都做了多余的工作，也就是 C 和 D 依赖的这个接口有些方法是他们不需要的，这个接口写的不好。
2.2 改进
根据接口隔离原则，我们应该将其拆成满足最小接口的类型，也就是说多余的我们全都不应要，所以接口 Interface1 应该拆分为三个接口，接口 1 里面有方法 1 ，接口 2 里面有方法 23，接口 3 里面有方法 4，这样实现的时候A和B两个类就更加清晰，修改后的类图如下：
那么，这样 A 和 B 实现的方法就是需要的方法，不会有多余的方法，C 和 D 的依赖也就更加清楚，满足 最小接口。
interface Interface11{
void fuc1();
}
interface Interface12{
void fuc2();
void fuc3();
}
interface Interface13{
void fuc4();
}
class A1 implements Interface11,Interface12{
public void fuc1() {System.out.println("A实现了接口1的fuc1");}
public void fuc2() {System.out.println("A实现了接口2的fuc2");}
public void fuc3() {System.out.println("A实现了接口2的fuc3");}
}
class B1 implements Interface12,Interface13{
public void fuc2() {System.out.println("B实现了接口2的fuc2");}
public void fuc3() {System.out.println("B实现了接口2的fuc3");}
public void fuc4() {System.out.println("B实现了接口3的fuc4");}
}
class C1{
public void depend1(Interface11 i){
i.fuc1();
}
public void depend2(Interface12 i){
i.fuc2();
}
public void depend3(Interface12 i){
i.fuc3();
}
}
class D1{
public void depend2(Interface12 i){
i.fuc2();
}
public void depend3(Interface12 i){
i.fuc3();
}
public void depend4(Interface13 i){
i.fuc4();
}
}
这种写法就是遵循了接口隔离原则
客户端使用的时候：
C1 c = new C1();
c.depend1(new A1());//C类通过接口依赖（使用）的是A类
c.depend2(new A1());
c.depend3(new A1());
D1 d = new D1();
d.depend2(new B1());//D类通过接口依赖（使用）的是B类
d.depend3(new B1());
d.depend4(new B1());
三、依赖倒转原则
依赖倒转原则 ( Dependence Inversion Principle ) 指的是：
- 高层模块不应该依赖低层模块，二者都应该依赖其抽象；
- 抽象不应该依赖细节，细节应该依赖抽象；
- 依赖倒转的核心思想是面向接口编程。
为什么要有依赖倒转原则：主要是因为，相对于细节的多变，抽象的东西要稳定的多，以抽象为基础搭建的架构比以细节为基础的架构稳定的多，在java种，抽象指的就是接口或者抽象类，细节就是具体的实现类，抽象类制定好规范，展现细节的任务交给实现类去做。
依赖倒转原则需要注意：
- 底层模块尽量都要有抽象类或接口，或者两者都有，程序的稳定性会更好；
- 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象之间，就存在一个缓冲层，利于程序扩展和优化；
- 继承时遵循里氏替换原则。
例如：有一个功能，一个Person类，要有一个接收消息的功能。
3.1 示例
public class DependencyInversion1 {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
}
}
class Email{
public String getInfo(){
return "电子邮件信息";
}
}
class Person{
public void receive(Email email){
System.out.println(email.getInfo());
}
}
因为Person类需要的接受是一个功能，消息应该是另一个类，所以还有一个Email类。那么这种写法，显然直接犯在Person类里依赖了Email类，也就是上面所说的”高层模块依赖底层模块“。
那么这么写可能会带来哪些问题呢？
对于Person类，接受的这个动作可以扩展，如果要接受的不仅仅是Email，是很多短信、微信等信息，那么在新增短信、微信类的同时，Person类里要新增对应的方法，改动基本是所有的都改动。
按照依赖倒转原则，对于Email、短信这些不同的类，应该将他们抽象出一个接口，然后他们实现接口，这样的话，对于Person类，他的接受方法，就是对这个抽象接口的依赖，而不是直接依赖这些不同的实现类。
3.2 改进
public class Dependency1 {
public static void main(String[] args) {
Person1 person1 = new Person1();
person1.receive(new Email1());
}
}
interface IReceiver{
public String getInfo();
}
class Email1 implements IReceiver{
public String getInfo() {
return "电子邮件信息:";
}
}
class Person1{
public void receive(IReceiver receiver){
System.out.println(receiver.getInfo());
}
}
在客户端的调用方式也是几乎一样的，运行结果是一样的，同时，因为Person依赖的是抽象的接口而不是具体的Email。
当我们想要增加一个接受的类的时候，平行增加，同时都去实现接口里面的方法就可以，Person类不用做改变，那么调用的时候传入参数去变成具体的实现类就可以。
//扩展
class Wechat implements IReceiver{
public String getInfo() {
return "微信消息：";
}
}
那么main方法的客户端只需要：
person1.receive(new Wechat());
就可以。
3.3 扩展：依赖关系传递的三种方式
依赖关系的传递一般有三种方式：
- 接口传递；
- 构造方法传递；
- setter方法传递。
第一种：
//方式1：通过接口传递依赖
interface IOpenandClose{
public void open(ITV itv);
}
interface ITV{
public void play();
}
class OpenandClose implements IOpenandClose{
public void open(ITV itv) {
itv.play();
}
}
可以看到，因为第一个接口依赖于第二个接口，那么实现第一个接口的时候，就需要实现对应的方法，把接口作为参数，实现了依赖的传递。
第二种：
//方式2，通过构造方法传递依赖
interface IOpenandClose2{
public void open();
}
interface ITV2{
public void play();
}
class OpenandClose2 implements IOpenandClose2{
public ITV2 itv2;
public OpenandClose2(ITV2 itv2){
this.itv2 = itv2;
}
public void open() {
this.itv2.play();
}
}
通第一个接口和第二个接口虽然没有直接写明依赖，但是依赖体现在实现类里，实现类里通过构造方法传入一个参数，才能进行open方法的实现，所以在构造方法的部分体现了依赖关系。
第三种：
//方式3，通过set方法传递依赖
interface IOpenandClose3{
public void open();
public void setTV(ITV3 itv3);
}
interface ITV3{
public void play();
}
class OpenandClose3 implements IOpenandClose3{
private ITV3 itv3;
public void setTV(ITV3 itv3) {
this.itv3 = itv3;
}
public void open() {
this.itv3.play();
}
}
其实和第一种类似，不过没有在open的地方直接依赖，而是分成两个步骤，先给声明的ITV初始化，再进行使用，这样依赖也就传递成功了。
使用三种示例的方法，我们都用到一个ITV的实现类，实现一个play方法，然后调用开关这个类，体现开关接口的依赖性。比如第一种是
class Sumsang implements ITV{
public void play() {
System.out.println("三星电视开机啦");
}
}
然后在主方法里调用就是：
OpenandClose close = new OpenandClose();
close.open(new Sumsang());
因为使用开关机的时候，这个方法就是通过接口参数才能调用，所以这是第一种接口传递。
第二种就只用：
OpenandClose2 close2 = new OpenandClose2(new Sony());
close2.open();
虽然open没有参数，但是依赖是通过构造方法传递的。
第三种情况：
OpenandClose3 close3 = new OpenandClose3();
close3.setTV(new Xiaomi());//如果不先set，就会报空指针close3.open();
四、里氏替换原则
面向对象中继承的问题：
- 父类实现好的方法，实际上设定了规范，虽然不强制要求子类都要遵守，到那时如果子类对这些方法进行了修改，会对整个继承体系造成破坏；
- 如果使用继承会给程序带来入侵性，使得移植性降低，增加对象之间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，会影响所有子类；
- 那么，如何在编程中正确使用继承呢？=> 里氏替换原则
里氏替换：
- 里氏替换原则：如果每个类型 T1 的对象 o1 ，都有类型 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型，也就是说，引用基类（父类）的地方必须能透明的使用其子类（派生类）的对象。
- 使用继承的时候，遵循里氏替换原则，也就是尽量不要重写父类的方法；
- 这个原则告诉我们，继承让两个类的耦合性增强了，适当情况下，可以通过聚合、组合、依赖来解决问题。
如何理解这个原则呢，假如一个父类是 A，B extends A，结果把 A 类的所有方法都重写了，那肯定A类的对象所有行为都变化了，另一方面，B 还要继承 A 类纯属有病。适当的，A 和 B 更适合于，继承同一个更加基础的类 C，重新整理，这样解决这个问题会比较合适。
4.1 示例
例如：
class A{
public int func1(int a, int b){
return a - b;
}
}
class B extends A{
public int func1(int a, int b){
return a + b;
}
public int func2(int a, int b){
return func1(a, b)+9;
}
}
不管是无意还是有意，B 继承 A 的时候把 func1 重写了。
显然，这样 B 以为被正常调用的时候，求a-b的 func1 ，却输出了和调用 a 的 func 1不一样的结果。（可能例子不是很恰当，但是如果更复杂的情况下，调用一个子类的某一个方法，方法名是一样的，肯定会认为功能是一样的）
实际开发过程中，就是因为一些重写父类方法来完成新功能的操作，让整个继承体系的复用性变差，特别是用到多态比较多的时候。
通用的做法就是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系来替代。
4.2 改进
//更加基础的类
class Base{
}
class A1 extends Base{
public int func1(int a, int b){
return a - b;
}
}
class B1 extends Base{
public int func1(int a, int b){
return a + b;
}
public int func2(int a, int b){
return func1(a, b)+9;
}
//如果b要使用到A的方法，使用组合的关系
private A1 a1 = new A1();
//仍然使用A的方法
public int func3(int a, int b){
return this.a1.func1(a, b);
}
}
那么，这样的话A和B已经没有耦合的依赖关系了，那么调用的时候，想要减法的方法就可以调用fuc3，使用加法可以调用fuc1，此时不会和A的fuc1打架或者覆盖。
五、开闭原则ocp
开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则。
- 一个软件实体、如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节；
- 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过已有代码实现变化；
- 编程中遵循其他原则的目的就是遵循开闭原则。
5.1 示例
//绘图类，根据接受的shape不同来绘制图形，【使用方】
class GraphicEidtor{
public void drawShape(Shape s){
if(s.type == 1) drawRec(s);
if (s.type == 2) drawCir(s);
}
public void drawRec(Shape r){
System.out.println("矩形");
}
public void drawCir(Shape c){
System.out.println("圆形");
}
}
//基类
class Shape{
int type;
}
//【提供方】
class Rectangle extends Shape{
Rectangle(){
super.type = 1;
}
}
class Circle extends Shape{
Circle(){
super.type = 2;
}
}
调用的时候，给draw方法传入不同的参数，会根据类型画出不同的图形，我们调用一下：
GraphicEidtor graphicEidtor = new GraphicEidtor();
graphicEidtor.drawShape(new Rectangle());
graphicEidtor.drawShape(new Circle());
这种写法还是比较好理解的，但是这种写法很不好。
那么，这种写法的问题在哪里呢？
违反了设计模式的 OCP 开闭原则，也就是不满足对扩展开放，对修改关闭。这个原则希望当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码。
比如我们想加一个图形种类，那就要将这个图形多写一个类作为【提供方】，在画图类【使用方】里增加一个对应shape类型的调用，再增加一个方法。这就是违背原则了。
5.2 改进
思路就是：创建shape作为抽象类，提供一个抽线的draw方法，那么子类实现的时候去实现draw方法，这样的话，【使用方】就不用修改代码，满足了开闭原则。
（其实说白了就是面向对象的意思，这个对象自己本身需要向外提供方法，而不是让使用方去提供方法，同时，前面四个原则里也多多多少少有用到这个思路，就是让使用方不要改动）
class GraphicEidtor1{
public void drawShape(Shape1 s){
s.draw();
}
}
abstract class Shape1{
int type;
public abstract void draw();
}
class Rectangle1 extends Shape1{
Rectangle1(){
super.type = 1;
}
public void draw(){
System.out.println("矩形");
}
}
class Circle1 extends Shape1{
Circle1(){
super.type = 2;
}
public void draw(){
System.out.println("圆形");
}
}
这样的话，调用的写法是没有任何改变的。
但是呢，如果我们要加一个新的形状，那么就让他自己去实现方法就可以了，对于【使用方】GraphicEidtor 是修改关闭的。
六、迪米特法则
Demeter Principle 迪米特法则，又叫最少知道原则：
即一个类对自己依赖的类知道的越少越好，也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装再类的内部。对外提供public方法，不对外泄露任何信息。
迪米特法则还有个更简单的定义：只与直接的朋友通信。
什么是直接朋友？每个对象都会和其他对象之间有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系，耦合的方式有很多，依赖、关联、组合、聚合等。
其中我们称出现在成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中 的类不是直接的朋友，也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
比如A类里面直接有用到一个B b，或者某个方法有参数fuc1(B b)；或者返回值类型是B，那么这叫做B以直接朋友的形式出现在了A里面。
比如A类里面有个方法 fuc1，fuc1用到一个 B b = new B()；这样的局部变量形式让A里面出现了B，这就是陌生的类，而不是直接朋友。
6.1 示例
比如一个应用实例：
有一个学校，下属各个学院和总部，现在要求打印出学校总部的员工ID和学院员工的ID。
代码略长，但是逻辑很简单：
public class Demeter1 {
public static void main(String[] args) {
CollegeManager collegeManager = new CollegeManager();
collegeManager.printAllEmp(new SchoolManager());
}
}
//学校总员工
class Employee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}
//学院员工
class SchoolEmployee{
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//管理学院员工
class SchoolManager{
//添加学院员工
public List<SchoolEmployee> getAllEmployee(){
List<SchoolEmployee> list = new ArrayList<>();
for( int i=0; i<10; i++){
SchoolEmployee employee = new SchoolEmployee();
employee.setId("学院员工:"+i);
list.add(employee);
}
return list;
}
}
//学校管理类
//直接朋友类有：Employee、SchoolManager，第一个作为添加方法返回值，第二个作为输出方法的参数
//陌生类：SchoolEmployee，违背了迪米特法则
class CollegeManager{
//添加学校员工，返回值参数Employee：直接朋友
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<>();
for(int i=0; i<5; i++){
Employee employee = new Employee();
employee.setId("学校总部员工："+i);
list.add(employee);
}
return list;
}
//输出所有员工信息
//参数SchoolManager：直接朋友
public void printAllEmp(SchoolManager sub){
//SchoolEmployee：陌生朋友，局部变量的方式
List<SchoolEmployee> list1 = sub.getAllEmployee();
System.out.println("-----学院员工-----");
for(SchoolEmployee e: list1){
System.out.println(e.getId());
}
List<Employee> list2 = this.getAllEmployee();
System.out.println("-----学校员工-----");
for(Employee e: list2){
System.out.println(e.getId());
}
}
}
这里面的问题，关于直接朋友和非直接朋友已经标注。
按照迪米特法则，上面出现了 SchoolEmployee 是陌生朋友，出现在了 SchoolManager 类里。这是非直接朋友关系的耦合，根据迪米特法则是应该避免的。
6.2 改进
其实例子写的有点故意，显然出问题的那一段，学校的输出信息部分，要输出学院的信息，没必要，解决起来把输出学院员工信息的那段，放到学院员工自己的类里面就可以了。也就是遵守了前面说的 " 尽量将逻辑封装在类的内部 "。
那么就可以把 SchoolManager 部分输出学院信息部分改成：
//学院员工
sub.printEmployee();
然后对应的输出方法，写去CollegeManager类里面，添加一个方法：
//输出学院所有员工的信息
public void printEmployee(){
List<SchoolEmployee> list1 = this.getAllEmployee();//不用this也行
System.out.println("-----学院员工-----");
for(SchoolEmployee e: list1){
System.out.println(e.getId());
}
}
这样的话，逻辑在自己类内部，提供一个public方法供外部使用。
注意：每个类之间多多少少都会有耦合，迪米特法则只是要求降低耦合关系，而不是要求完全没有依赖关系。完全没有，就相当于每个对象干个啥都在自己类里写完，也用不着直接朋友了。
七、合成复用原则
合成复用原则：尽量使用组合/聚合的方式，而不要使用继承。
例如： A 类和 B 类，B 类想要使用 A 类的两个方法，第一个想到的是继承，但是这种做法耦合性很高，如果说仅仅是想要使用这两个方法，而没有别的根本上需要用到继承的必要性，那么可能会带来很多麻烦，比如还有别的类也继承了 A ，有必要修改 A 的时候还要考虑 B 会不会收影响。
所以尽量使用的做法就是聚合或者合成：
7.1 聚合
将 A 作为一个私有变量加入到 B 里面，在 B 里面写一个 set 方法将 A 实例化，然后去调用想要的方法，这就叫做聚合。类似于我们在前面第三个原则”依赖倒转原则“最后写的传递依赖的方式的setter方法。
7.2 组合
将 A 直接实例化在 B 里面，那么 B 创建的时候，A 就已经有了一个实例化的对象，然后调用方法，和前面的里氏替换法则后面的做法是一样的。
八、总结
其实上面的七个原则很多地方的解决方案和冲突都是有重复的部分，实际上我们总结一下核心思想就是：
- 尽量把需要变化的部分独立出来，不要和不变的代码写在一起；
- 如果对别的部分影响大，尽量写成接口；
- 为了松耦合努力。（可以说七个原则这个理论本身就是非常松耦合……）
