设计模式之七大设计原则

最新推荐文章于 2024-10-04 08:38:41 发布

又十七

最新推荐文章于 2024-10-04 08:38:41 发布

阅读量367

点赞数

分类专栏：设计模式文章标签：设计模式 java

本文链接：https://blog.csdn.net/admin_lian/article/details/106128134

版权

设计模式专栏收录该内容

6 篇文章 0 订阅

订阅专栏

(一) 设计模式

1. 设计模式概述

软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式的目的:

代码重用性: 相同功能的代码, 不用多次编写
代码可读性: 编程规范性, 代码便于阅读、理解
代码的可扩展性: 当需要增加新的功能时, 易于扩展, 可维护性高
代码的可靠性: 当需要增加新的功能时, 对原有的功能没有影响
使程序呈现高内聚, 低耦合的特性

2. 设计模式分类

创建型模式: 单例模式、抽象工场模式、原型模式、建造者模式、工场模式.
结构型模式: 适配器模式、桥接模式、装饰者模式、组合模式、外观模式、享元模式、代理模式
行为型模式: 模板方法模式、命令模式、访问者模式、迭代器模式、中介者模式、备忘录模式、解释器模式(Interpreter模式)、状态模式、策略模式、职责链模式(责任链模式)

(二) 设计模式的七大设计原则

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

七大设计原则:

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

1. 单一职责原则

单一职责原则（SRP：Single Responsibility Principle）: 又称单一功能原则, 是面向对象五个基本原则之一(单一职责原则、开闭原则、接口隔离原则、里氏替换原则和依赖倒置原则). 对类来说的, 即一个类只负责一项职责(高内聚低耦合).
如果A类负责两个不同职责: 职责1、职责2, 当职责1需求变更而改变A类时, 可能会造成职责2的执行错误, 这就是不满足单一原则所产生的问题, 因此需要将A类按职责粒度分解为A1, A2

下面代码中的Vehicle交通工具类, run() 方法违反了单一职责原则

public class Vehicle {

	public void run(String vehicle) {
		System.out.println(vehicle + " 在公路上运行...");
	}

	public static void main(String[] args) {
		Vehicle vehicle = new Vehicle();
		vehicle.run("单车"); // 单车 在公路上运行...
		vehicle.run("汽车"); // 汽车 在公路上运行...
		vehicle.run("飞机"); // 飞机 在公路上运行...
	}
}

分解Vehicle类, 根据交通工具运行方法不同，分解成不同类即可 (类级别的单一职责原则)

public class SingleResponsibility_Class {
	
	public static void main(String[] args) {
		RoadVehicle roadVehicle = new RoadVehicle();
		roadVehicle.run("汽车"); // 汽车 在公路上运行...
		AirVehicle airVehicle = new AirVehicle();
		airVehicle.run("飞机"); // 飞机 在天空中运行...
		WaterVehicle waterVehicle = new WaterVehicle();
		waterVehicle.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 + " 在水中航行...");
	}
}

在分解后的交通工具类, 遵循类单一职责原则. 但改动稍大, 产生多个“子类”. 我们可以将类级别的单一职责原则缩小为
方法级别的单一职责原则

public class SingleResponsibility_Method {
	
	public static void main(String[] args) {
		Vehicle2 vehicle2 = new Vehicle2();
		vehicle2.roadRun("汽车"); // 汽车 在公路上运行...
		vehicle2.airRun("飞机"); // 飞机 在天空中运行..
		vehicle2.waterRun("航母"); // 航母 在水中航行...
	}
}

// 交通工具类
class Vehicle2 {
	
	public void roadRun(String vehicle) {
		System.out.println(vehicle + " 在公路上运行...");
	}
	
	public void airRun(String vehicle) {
		System.out.println(vehicle + " 在天空中飞行...");
	}
	
	public void waterRun(String vehicle) {
		System.out.println(vehicle + " 在水中航行...");
	}
}

单一职责原则注意事项和细节

降低类的复杂度, 一个类只负责一项职责
提高类的可读性, 可维护性
降低变更需求引起的风险
通常情况下, 我们都应该遵守单一职责原则. 只有逻辑足够简单, 才可以类级别违反单一职责原则; 只有类中方法数量足够少, 才可以在方法级别保持单一职责原则

2. 依赖倒转原则

依赖倒转原则(Dependence Inversion Principle):

依赖倒转(倒置)的中心思想是 面向接口编程
高层模块不应该依赖底层模块, 二者应该依赖其抽象(即: 类与类之间的依赖应建立在抽象上)
抽象(接口) 不应该依赖细节(实现类), 细节应该依赖抽象(即: 先有接口, 再有实现类)
依赖倒转原则是基于这样的设计理念: 相对于细节的多变性, 抽象的东西要稳定的多. 以抽象为基础搭建的架构比以细节为基础搭建的架构要稳定的多. (在JAVA中, 抽象为接口或抽象类; 细节为具体的实现类)
使用接口或抽象类的目的是制定好规范, 而不涉及到具体的操作. 把展现细节的任务交给实现类去完成

如图, 此UML类图违反了违反了依赖倒转原则
在这里插入图片描述

Email类中有一个 snedInfo() 发送消息的方法
Person类中的 receiverInfo(Email) 接受消息的方法依赖 Email类, 违反了依赖倒转原则(类与类之间的依赖没有建立在抽象上)

如果Person类发送对象是微信，短信等，则要新增类，同时Person也要增加相应的接收方法(复杂且不合理)
在这里插入图片描述
因此, 应该让Person类与 Email类之间的依赖建立在抽象上: 引入一个抽象的接口 ISender，表示发送者. 新增发送对象时, 只需要新增ISender接口实现即可, 无需改变Person类

ISender接口中只有 sendInfo()抽象方法, WeChat类和 Email类实现了 ISender接口
Person类通过 ISender接口依赖于 WeChat类和 Email类. 即: 类与类之间的依赖应建立在抽象上

依赖关系传递的三种方式:

通过接口传递: 参考上图, 在方法中传递依赖接口
通过构造方法传递依赖接口
通过setter方法传递依赖接口

依赖倒转原则的注意事项和细节:

底层模块尽量都要有抽象类或接口, 或者两种都有, 程序稳定性更好
变量的声明类型尽量为抽象类或接口, 这样我们的变量引用和实际对象间, 就存在一个缓冲层, 利于层序扩展和优化
继承时遵循里式替换原则(接下会介绍)

3. 接口隔离原则

接口隔离原则(Interface Segregate Principle): 客户端不应该依赖它不需要的接口, 即 一个类对另一个类的依赖应该建立在最小的接口上

如图, 此UML类图违反了接口隔离原则
在这里插入图片描述

接口 Interface1: 有 operation1、2、3 、4 、5 () 5个抽象方法, 类B 和类D 实现了接口 Interface1
类A 依赖于类B, 建立在接口 Interface1上, 但只会使用接口中 operation1、2、3 方法, 违反了接口隔离原则(operation4、5 () 类B也实现了, 但没有使用)
类C 依赖于类D, 建立在接口 Interface1上, 但只会使用接口中 operation1、4、5 方法, 违反了接口隔离原则(operation2、3 () 类D也实现了, 但没有使用)

改进UML类图, 使其遵守接口隔离原则
在这里插入图片描述

接口 Interface2 和接口 Interface3 继承接口 Interface1, 类B 实现了接口 Interface2, 类D 实现了接口 Interface3
类A 依赖于类B, 建立在接口 Interface2上, 且使用接口 Interface2中所有的方法, 遵循了接口隔离原则
类C 依赖于类D, 建立在接口 Interface3上, 且使用接口 Interface3中所有的方法, 遵循了接口隔离原则

4. 里氏替换原则

在解释里氏替换原则之前, 我们先思考一个问题: OO(面向对象)中的继承

继承就是子类继承父类的特征和行为，使得子类对象（实例）具有父类的属性和方法
继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
继承在给程序设计带来便利的同时, 也带来了弊端: 使用继承会给程序带来侵入性, 程序可移植性降低, 增加对象间的耦合性. 比如: 一个父类被其他的几个子类继承, 则当这个父类需要修改时, 必须考虑到所有的子类且父类修改后, 所涉及到子类的功能有可能产生故障
里氏替换原则就是规定继承需要遵守规则

里氏替换原则(LSP: Liskov Substitution Principle): 官方介绍, 如果对每个类型为T1的对象o1, 都有类型为T2的对象o2. 使得以T1定义的所有程序P在所有的对象o1替换成o2时, 程序P的行为没有发生变化, 那么类型T2是类型T1的子类型.

这句话读起来是不是很绕, 博主第一次看到也是如此. 下面用通俗的话来解释:

简单来说, 就是使用子类对象替换程序中的父类对象, 程序的运行结果没有发生变化或者说, 当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系
为了遵循里氏替换原则, 在使用继承时, 在子类中尽量不要重写父类方法
继承实际上让两个类耦合性增强了, 在不得已要重写父类方法的情况下, 可以通过 聚合、组合、依赖来解决问题

如代码所示: 类B 违反了里氏替换原则

public class LiskovSubstitution_error {

    public static void main(String[] args) {
        int num1 = 11, num2 = 5;

        A a = new A();
        System.out.println(a.add(num1, num2)); // 打印输出: 16

        a = new B();
        System.out.println(a.add(num1, num2)); // 打印输出: 17

    }

}

class A {

    /**
     * 返回两数纸之和
     *
     * @param num1
     * @param num2
     * @return
     */
    public int add(int num1, int num2) {
        return num1 + num2;
    }
}

class B extends A {

    /**
     * 重写父类的方法, 返回两数纸之和 + 1
     *
     * @param num1
     * @param num2
     * @return
     */
    @Override
    public int add(int num1, int num2) {
        return num1 + num2 + 1;
    }

}

类A 中有一个返回两数之和的 add(int, int)
类B 继承类A, 却重写了 add(int, int)方法, 使其返回两数纸之和 + 1
导致在Main函数中, 实例a 自身执行add方法返回的值(16) 和使用子类B 创建实例a 执行add返回值(17) 不一致, 违反了里氏替换原则(使用子类对象替换程序中的父类对象, 程序的运行结果没有发生变化)

在实际的编程中, 我们常常会通过重写父类的方法完成新的功能, 这样写起来虽然简单, 但会破坏整个继承体系, 使其复用性变差, 特别是运行多态比较频繁的时候
因此, 我们需要对其改进: 通常做法是, 将原来的父类和子类都继承一个更通俗的基类, 原有的继承关系去掉, 采用 依赖, 聚合, 组合等关系替代

在这里插入图片描述

5. 开闭原则

开闭原则(Open Closed Principle):

开闭原则是编程中最基础、最重要的设计原则. 编程中遵循其他原则, 以及使用设计模式的最终目的就是为了遵循开闭原则
一个软件实体, 如类、模块、函数应该是对扩展是开放的, 对修改时关闭的.用抽象构建框架, 用实现扩展细节
当软件需要修改时, 尽量通过扩展软件实体的行为来实现变化, 而不是通过修改已有的代码来实现

如代码所示: 违反了开闭原则

public class OpenClosedPrinciple_error {

    public static void main(String[] args) {
        GraphicEditor ge = new GraphicEditor();
        ge.drawShape(new Rectangle());
        ge.drawShape(new Circle());
    }
}

/**
 * 图形编辑器
 */
class GraphicEditor {

    public void drawShape(Shape s) {
        if (s.shapeType == 1) {
            System.out.println("绘制矩形");
        } else if (s.shapeType == 2) {
            System.out.println("绘制圆形");
        }
    }
}

/**
 * 图形基类
 */
class Shape {

    // 图形的种类
    int shapeType;
}

/**
 * 矩形 继承 图形基类, 种类为1
 */
class Rectangle extends Shape {
    Rectangle() {
        super.shapeType = 1;
    }
}

/**
 * 圆形 继承 图形基类, 种类为2
 */
class Circle extends Shape {
    Circle() {
        super.shapeType = 2;
    }
}

当需要绘制三角形时, 不但需要创建类Triangle 继承 Shape, 还要修改 GraphicEditor类中的 drawShape方法,增加eles if 判断. 此时需要通过修改已有的代码来实现新功能, 违反了开闭原则

改进: 图形类Shape 改造成图形接口Shape, 提供一个抽象的方法draw(). 子类实现它是去重写draw方法绘制具体的图形. 在图形编辑器类GraphicEditor 中的 drawShape方法直接传入 Shape接口, 调用draw方法绘制

public class OpenClosedPrinciple {

    public static void main(String[] args) {
        GraphicEditor ge = new GraphicEditor();
        ge.drawShape(new Rectangle());
        ge.drawShape(new Circle());
    }
}

/**
 * 图形编辑器
 */
class GraphicEditor {

    public void drawShape(Shape s) {
        s.draw();
    }
}

/**
 * 图形接口
 */
interface Shape {
     void draw();
}

/**
 * 矩形类Rectangle 实现 图形接口Shape
 */
class Rectangle implements Shape {

    @Override
    public void draw() {
        System.out.println("绘制矩形");
    }
}

/**
 * 圆形类Circle 实现 图形接口Shape
 */
class Circle implements Shape {

    @Override
    public void draw() {
        System.out.println("绘制圆形");
    }
}

此时, 需要绘制三角形时, 只需需要创建类Triangle 实现 Shape接口即可. 无需修改已有的代码. 遵循开闭原则

6. 迪米特法则

迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP）:

一个类对自己依赖的类知道的越少越好, 也就是说, 对于被依赖的类不管多么复杂, 都尽量将逻辑封装在类的内部, 对外除了提供public方法, 不对外泄露任何信息
迪米特法则还有一个更简单的定义, 只与直接朋友通信.
直接朋友: 每个对象都会与其他对象有耦合关系, 只要两个对象耦合关系, 我们就可以认为这两个对象之间是朋友关系. 耦合的方式有很多: 依赖、关联、组合、聚合等. 其中, 出现在成员变量、方法参数、方法返回值中的类称之为直接朋友; 出现在局部变量中的类称之为陌生朋友, 也就是说依赖的类最好不要以局部变量的形式出现在类的内部

如代码所示, 违反了迪米特法则

public class LeastKnowledgePrinciple_error {

    public static void main(String[] args) {
        new TeacherInfo().printTeacherAndStudentInfo();
    }
}

/**
 * 学生信息类
 */
class StudentInfo {
    private int sid;

    public int getId() {
        return sid;
    }

    public void setId(int sid) {
        this.sid = sid;
    }
}

/**
 * 教师信息类
 */
class TeacherInfo {
    private int tid;


    public void printTeacherAndStudentInfo() {

        List<TeacherInfo> teacherInfoList = initInfo();
        System.out.println("-----------教师信息-----------");
        for (TeacherInfo info : teacherInfoList) {
            System.out.println("教师编号: " + info.getId());
        }

        // 学生信息初始化, 违反了迪米特法则
        List<StudentInfo> studentList = new ArrayList<StudentInfo>();
        for (int i = 1; i <= 10; i++) {
            StudentInfo studentInfo = new StudentInfo();
            studentInfo.setId(i);
            studentList.add(studentInfo);
        }
        System.out.println("-----------学生信息-----------");
        for (StudentInfo info : studentList) {
            System.out.println("学生编号: " + info.getId());
        }

    }

    /**
     * 教师信息初始化
     *
     * @return
     */
    private List<TeacherInfo> initInfo() {
        List<TeacherInfo> list = new ArrayList<TeacherInfo>();
        for (int i = 1; i <= 2; i++) {
            TeacherInfo teacherInfo = new TeacherInfo();
            teacherInfo.setId(i);
            list.add(teacherInfo);
        }
        return list;
    }

    public int getId() {
        return tid;
    }

    public void setId(int tid) {
        this.tid = tid;
    }

}

在TeacherInfo类中的 printTeacherAndStudentInfo方法依赖 StudentInfo类且以局部变量的形式出现
或者说, 依赖的StudentInfo类的初始化学生信息和打印逻辑没有封装在StudentInfo类内部, 暴露出来了
因此, 需要将初始化和打印逻辑封装在StudentInfo类的内部(隐藏), 对外提供public方法

public class LeastKnowledgePrinciple {

    public static void main(String[] args) {
        new TeacherInfo().printTeacherAndStudentInfo(new StudentInfo());
    }
}

/**
 * 学生信息类
 */
class StudentInfo {
    private int sid;

    public int getId() {
        return sid;
    }

    public void setId(int sid) {
        this.sid = sid;
    }

    /**
     * 学生信息初始化
     *
     * @return
     */
    public List<StudentInfo> initInfo () {
        List<StudentInfo> studentList = new ArrayList<StudentInfo>();
        for (int i = 1; i <= 10; i++) {
            StudentInfo studentInfo = new StudentInfo();
            studentInfo.setId(i);
            studentList.add(studentInfo);
        }
        return studentList;
    }

    /**
     * 将初始化和打印逻辑封装在StudentInfo类的内部(隐藏), 对外提供public方法
     */
    public void print() {
        List<StudentInfo> studentList = initInfo();
        System.out.println("-----------学生信息-----------");
        for (StudentInfo info : studentList) {
            System.out.println("学生编号: " + info.getId());
        }
    }
}

/**
 * 教师信息类
 */
class TeacherInfo {
    private int tid;


    public void printTeacherAndStudentInfo(StudentInfo studentInfo) {

        List<TeacherInfo> teacherInfoList = initInfo();
        System.out.println("-----------教师信息-----------");
        for (TeacherInfo info : teacherInfoList) {
            System.out.println("教师编号: " + info.getId());
        }

        // 将初始化和打印逻辑封装在StudentInfo类的内部(隐藏), 对外提供public方法
        studentInfo.print();

    }

    /**
     * 教师信息初始化
     *
     * @return
     */
    public List<TeacherInfo> initInfo() {
        List<TeacherInfo> list = new ArrayList<TeacherInfo>();
        for (int i = 1; i <= 2; i++) {
            TeacherInfo teacherInfo = new TeacherInfo();
            teacherInfo.setId(i);
            list.add(teacherInfo);
        }
        return list;
    }

    public int getId() {
        return tid;
    }

    public void setId(int tid) {
        this.tid = tid;
    }

}