设计模式：七大设计原则

Posted 2021-08-05 dxj1016

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了设计模式：七大设计原则相关的知识，希望对你有一定的参考价值。

1、设计模式的目的

1.1、目的

编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序（软件），具有更好
1）代码重用性（即：相同功能的代码，不用多次编写）
2）可读性（即：编程规范性，便于其他程序员的阅读和理解）
3）可扩展性（即：当需要增加新的功能时，非常的方便，称为可维护）
4）可靠性（即：当我们增加新的功能后，对原来的功能没有影响）
5）使程序呈现高内聚，低耦合的特性
分析金句：
设计模式包含了面向对象的精髓，“懂了设计模式，你就懂了面向对象分析和设计（OOA/D）的精要”

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础（即：设计模式为什么这样设计的依据）

1.2、设计原则核心思想

1）找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2）针对接口编程，而不是针对实现编程。
3）为了交互对象之间的松耦合设计而努力

2、面向对象的“六原则一法则”：

单一职责原则、开闭原则、依赖倒转原则、里氏替换原则、接口隔离原则、合成聚合复用原则和迪米特法则。

2.1、单一职责原则★★★★☆

2.1.1、基本介绍

对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2
单一职责原则想表达的就是"高内聚"，写代码最终极的原则只有六个字"高内聚、低耦合"，就如同葵花宝典或辟邪剑谱的中心思想就八个字"欲练此功必先自宫"，所谓的高内聚就是一个代码模块只完成一项功能，在面向对象中，如果只让一个类完成它该做的事，而不涉及与它无关的领域就是践行了高内聚的原则，这个类就只有单一职责。。

2.1.2、应用实例–交通工具案例讲解

方案1：

package Seven_principles.singleresponsibility;

public class SingleResponsibility1 {
    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 + "在公路上运行。。。");
    }

}
/*
运行结果：
摩托车在公路上运行。。。
汽车在公路上运行。。。
飞机在公路上运行。。。
 */

方案2：

package Seven_principles.singleresponsibility;

public class SingleResponsibility2 {
    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        AirVehicle airVehicle = new AirVehicle();
        WaterVehicle waterVehicle = new WaterVehicle();
        roadVehicle.run("摩托车");
        airVehicle.run("飞机");
        waterVehicle.run("轮船");
    }
}

//三个工具类
//方式二：
//方式二的分析：
//1.遵守单一职责原则
//2.但是这样做的改动很大，即将类分解，同时修改客户端
//3.改进：直接修改Vehicle类，改动的代码会比较少=》方式三
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 + "在水路上运行。。。");
    }

}

/*
运行结果：
摩托车在公路上运行。。。
飞机在天空上运行。。。
轮船在水路上运行。。。
 */

方案3：

package Seven_principles.singleresponsibility;

public class SingleResponsibility3 {
    public static void main(String[] args) {
        Vehicle2 vehicle2 = new Vehicle2();
        vehicle2.run("摩托车");
        vehicle2.runAir("飞机");
        vehicle2.runWater("轮船");
    }
}

//工具类
//方式三：
//方式三分析：
//1.这种修改方法没有对原来的类做大的修改，只是增加方法
//2.这里虽然没有在类这个级别上遵守单一职责原则，但是在方法级别上，仍然是遵守单一职责原则的
class Vehicle2{
    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.1.3、注意事项和细节

1）降低类的复杂度，一个类只负责一项职责。
2）提高类的可读性，可维护性
3）降低变更引起的风险
4）通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

2.2、接口隔离原则★★☆☆☆

2.2.1、基本介绍

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上
先看一张图：
类A通过接口Interface1依赖类B，类c通过接口Interface1依赖类D，如果接口Interface1对于类A和类c来说不是最小接口那么类B和类D必须去实现他们不需要的方法。
按隔离原则应当这样处理：将接口Interface1拆分为独立的几个接口，类A和类c分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
接口要小而专，绝不能大而全。
臃肿的接口是对接口的污染，既然接口表示能力，那么一个接口只应该描述一种能力，接口也应该是高度内聚的。例如，琴棋书画就应该分别设计为四个接口，而不应设计成一个接口中的四个方法，因为如果设计成一个接口中的四个方法，那么这个接口很难用，毕竟琴棋书画四样都精通的人还是少数，而如果设计成四个接口，会几项就实现几个接口，这样的话每个接口被复用的可能性是很高的。Java中的接口代表能力、代表约定、代表角色，能否正确的使用接口一定是编程水平高低的重要标识。

2.2.2、应用实例

类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D，请编写代码完成此应用实例。

package Seven_principles.segregation;

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 {
    @Override
    public void operation1() {
        System.out.println("B 实现了operation1");
    }
    @Override
    public void operation2() {
        System.out.println("B 实现了operation2");
    }
    @Override
    public void operation3() {
        System.out.println("B 实现了operation3");
    }
    @Override
    public void operation4() {
        System.out.println("B 实现了operation4");
    }
    @Override
    public void operation5() {
        System.out.println("B 实现了operation5");
    }
}
class D implements Interface1 {
    @Override
    public void operation1() {
        System.out.println("D 实现了operation1");
    }
    @Override
    public void operation2() {
        System.out.println("D 实现了operation2");
    }
    @Override
    public void operation3() {
        System.out.println("D 实现了operation3");
    }
    @Override
    public void operation4() {
        System.out.println("D 实现了operation4");
    }
    @Override
    public void operation5() {
        System.out.println("D 实现了operation5");
    }
}
//A 类通过接口Interface1 依赖（使用）B类，但是只会用到1,2,3方法。
class A {
    public void depend1(Interface1 interface1) {
        interface1.operation1();
    }
    public void depend2(Interface1 interface1) {
        interface1.operation2();
    }
    public void depend3(Interface1 interface1) {
        interface1.operation3();
    }
}
//C 类通过接口Interface1 依赖（使用）D类，但是只会用到1,4,5方法。
class C {
    public void depend1(Interface1 interface1) {
        interface1.operation1();
    }
    public void depend2(Interface1 interface1) {
        interface1.operation4();
    }
    public void depend3(Interface1 interface1) {
        interface1.operation5();
    }
}

应传统方法的问题和使用接口隔离原则改进

1）类A通过接口Interface1依赖类B，类c通过接口Interface1依赖类D，如果接口Interface1对于类A和类C来说不是最小接口，那么类B和类D必须去实现他们不需要的方法
2）将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
3）接口Interface1中出现的方法，根据实际情况拆分为三个接口4）代码实现

package Seven_principles.segregation.improve;

public class Segregation2 {
    public static void main(String[] args) {
//        使用一下
        A a = new A();
        a.depend1(new B());//A类通过接口去依赖B类
        a.depend2(new B());//A类通过接口去依赖B类
        a.depend3(new B());//A类通过接口去依赖B类

        C c = new C();
        c.depend1(new D());//C类通过接口去依赖D类
        c.depend2(new D());
        c.depend3(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{
    @Override
    public void operation1() {
        System.out.println("B 实现了operation1");
    }
    @Override
    public void operation2() {
        System.out.println("B 实现了operation2");
    }
    @Override
    public void operation3() {
        System.out.println("B 实现了operation3");
    }
}

class D implements Interface1,Interface3{
    @Override
    public void operation1() {
        System.out.println("D 实现了operation1");
    }
    @Override
    public void operation4() {
        System.out.println("D 实现了operation4");
    }
    @Override
    public void operation5() {
        System.out.println("D 实现了operation5");
    }
}

//A 类通过接口Interface1 Interface2依赖（使用）B类，但是只会用到1,2,3方法。
class A {
    public void depend1(Interface1 interface1) {
        interface1.operation1();
    }
    public void depend2(Interface2 interface2) {
        interface2.operation2();
    }
    public void depend3(Interface2 interface2) {
        interface2.operation3();
    }
}

//C 类通过接口Interface1  Interface3依赖（使用）D类，但是只会用到1,4,5方法。
class C {
    public void depend1(Interface1 interface1) {
        interface1.operation1();
    }
    public void depend2(Interface3 interface3) {
        interface3.operation4();
    }
    public void depend3(Interface3 interface3) {
        interface3.operation5();
    }
}
/*
执行结果：
B 实现了operation1
B 实现了operation2
B 实现了operation3
D 实现了operation1
D 实现了operation4
D 实现了operation5
 */

2.3、依赖倒转原则★★★★★

2.3.1、基本介绍

依赖倒转原则（Dependence Inversion Principle）是指：
1）高层模块不应该依赖低层模块，二者都应该依赖其抽象2）抽象不应该依赖细节，细节应该依赖抽象
3）依赖倒转（倒置）的中心思想是面向接口编程4）依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类
5）使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

针对接口编程，不要针对实现编程
高层模块不应该依赖底层模块，抽象不应该依赖细节，细节应该依赖抽象。
传递参数或者关联关系的时候尽量使用层次高的抽象层类
程序中尽量使用抽象层编码，而将具体类对象通过依赖注入的方法注入其它对象，使用到spring的依赖注入。

面向接口编程。

该原则说得直白和具体一些就是声明方法的参数类型、方法的返回类型、变量的引用类型时，尽可能使用抽象类型而不用具体类型，因为抽象类型可以被它的任何一个子类型所替代，请参考下面的里氏替换原则。

2.3.2、应用实例–Person发送消息的功能

方案1：

package Seven_principles.inversion;

public class DependecyInversion1 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());

    }
}

class Email {
    public String getInfo() {
        return "电子邮件信息：hello World";
    }
}
//完成Person接收消息的功能
//方式一
//方式一分析：
//1.简单，比较容易想到
//2.如果我们获取的对象是微信，短信等等，这新增类，同时Person也要增加相应的接收方法，
//3.解决思路：引入一个抽象的接口IReceiver，表示接受者，这样Person类与接口IReceiver发生依赖
//因为Email，WeiXin等等属于接收的范围，他们各自实现IReceiver接口即可，这样我们就符合依赖倒转原则
class Person {
    public void receive(Email email) {
        System.out.println(email.getInfo());

    }
}

方案2：

package Seven_principles.inversion.improve;

public class DependecyInversion2 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
        person.receive(new WeiXin());

    }
}

//定义接口
interface IReceiver {
    public String getInfo();
}
//邮件
class Email implements IReceiver{
    public String getInfo() {
        return "电子邮件信息：hello World";
    }
}
//微信
class WeiXin implements IReceiver{
    public String getInfo() {
        return "微信信息：hello World";
    }
}

//完成Person接收消息的功能
//方式二
class Person {
    public void receive(IReceiver iReceiver) {
        System.out.println(iReceiver.getInfo());

    }
}
/*
执行结果：
电子邮件信息：hello World
微信信息：hello World
 */

2.3.3、依赖关系传递的三种方式和应用案例

package Seven_principles.inversion.improve;

public class DependecyInversion3 {
    public static void main(String[] args) {
//        测试方式一：通过接口传递依赖
//        ChangHong changHong = new ChangHong();
//        OpenAndClose openAndClose = new OpenAndClose();
//        openAndClose.open(changHong);
//        测试方式二：通过构造器传递依赖
//        ChangHong changHong = new ChangHong();
//        OpenAndClose openAndClose = new OpenAndClose(changHong);
//        openAndClose.open();
//        测试方式三：通过set方法传递依赖
        ChangHong changHong = new ChangHong();
        OpenAndClose openAndClose = new OpenAndClose();
        openAndClose.setTV(changHong);
        openAndClose.open();

    }
}

方式一：通过接口传递实现依赖
开关的接口
//interface IOpenAndClose {
//    public void open(ITV tv);//抽象方法，接收接以上是关于设计模式：七大设计原则的主要内容，如果未能解决你的问题，请参考以下文章 
 设计模式软件设计七大原则 ( 依赖倒置原则 | 代码示例 )
 解密设计模式的七大原则
 设计模式软件设计七大原则 ( 接口隔离原则 | 代码示例 )
 设计模式软件设计七大原则 ( 迪米特原则 | 代码示例 )
 Python设计模式 - 基础 - 七大基本原则
 设计模式七大原则开闭原则