【设计模式】软件设计七大原则

最新推荐文章于 2024-04-25 10:49:29 发布

益箴

最新推荐文章于 2024-04-25 10:49:29 发布

阅读量264

点赞数

分类专栏：设计模式文章标签：设计模式 java 代码规范程序设计面试

本文链接：https://blog.csdn.net/weixin_46662141/article/details/113782585

版权

设计模式专栏收录该内容

6 篇文章 0 订阅

订阅专栏

做好自己

软件设计七大原则

软件工程中，设计模式是对软件设计中普遍存在（ 反复出现）的各种问题，所提出的 解决方案。

说白了，设计模式就是在软件开发中多次出现、被大多人所认同、和语言无关、被分类过的代码设计经验的总结。而使用设计模式可以使软件具有更高的代码可重用性、可拓展性、可维护性（可读性、规范性）、可靠性，使程序更加高内聚、低耦合。

既然设计模式是用于软件开发当中，那么它出现在软件的哪里呢？

面向对象编程（oo）先形成功能模块（设计模式+算法），之后就是框架（多种设计模式集合），最上面就是传说中的架构（服务器集群）。

所以设计模式最主要出现于框架之中，最先出现在功能模块之中。

软件设计七大原则

而设计模式也要遵循一定的原则，正如定理遵循真理，那么设计模式的“真理”便是软件设计七大原则，即设计模式为什么这样设计的依据。

设计模式并不是不完全遵循七大原则，也就是有的违背，有的则是遵守，有的使用，有的没有使用，这是一种取舍性质。

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

开闭原则OCP（Open-Closed Principle）

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭
用抽象（接口等）构建框架，用实现（实现类）扩展细节
实现开闭原则的关键就在于合理地抽象、分离出变化与不变化的部分，为变化的部分预留下可扩展的方式
编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则
优点：提高软件的可复用性和可维护性

For Example:

场景：比如你现在是一个大学生，你的属性有学号，姓名，选修课数量。

定义一个接口：

package com.ekin.softwaredesign.ocp;

/**
 * @Author: ekin
 * @Date: 2021/4/9 14:27
 */
public interface IStudent {
    Integer getID();
    String getName();
    Integer getCourseCount();
}

实现类：

package com.ekin.softwaredesign.ocp;

/**
 * @Author: ekin
 * @Date: 2021/4/9 14:39
 */
public class GoodStudent implements IStudent {
    private Integer id;
    private String name;
    private Integer count;

    public GoodStudent(Integer id, String name, Integer count) {
        this.id = id;
        this.name = name;
        this.count = count;
    }

    @Override
    public Integer getID() {
        return this.id;
    }

    @Override
    public String getName() {
        return this.name;
    }

    @Override
    public Integer getCourseCount() {
        return this.count;
    }

    @Override
    public String toString() {
        return "GoodStudent{" +
                "id=" + id +
                ", name='" + name + '\'' +
                ", count=" + count +
                '}';
    }
}

测试：

package com.ekin.softwaredesign.ocp;

/**
 * @Author: ekin
 * @Date: 2021/4/9 14:43
 */
public class OcpTest {
    public static void main(String[] args) {
        GoodStudent ekin01 = new GoodStudent(001, "ekin", 10);
        System.out.println(ekin01);
    }
}

UML图：
在这里插入图片描述

可是突然有一天早上醒来，你拿起手机看到群消息，教务处觉得平时课程太少，为了让你多学点东西，决定将选课数量加倍，让你加倍快乐~

这个时候不要去动接口，接口作为契约（抽象）是可靠的

增加一个子类：

package com.ekin.softwaredesign.ocp;

/**
 * @Author: ekin
 * @Date: 2021/4/9 14:59
 */
public class DoubleGoodStudent extends GoodStudent {
    public DoubleGoodStudent(Integer id, String name, Intege count) {
        super(id, name, count);
    }

    @Override
    public Integer getID() {
        return super.getID();
    }

    @Override
    public String getName() {
        return super.getName();
    }

    @Override
    public Integer getCourseCount() {
        return super.getCourseCount() * 2;
    }

    @Override
    public String toString() {
        return "GoodStudent{" +
                "id=" + super.getID() +
                ", name='" + super.getName() + '\'' +
                ", count=" + super.getCourseCount()*2 +
                '}';
    }
}

测试：

public class OcpTest {
    public static void main(String[] args) {
        GoodStudent ekin = new DoubleGoodStudent(001, "ekin",10);
        System.out.println(ekin);
    }
}

console:

GoodStudent{id=1, name='ekin', count=20}

UML图：
在这里插入图片描述

依赖倒转原则DIP（Dependence Inversion Principle）

要依赖于抽象，不要依赖于具体类
高层模块不应该依赖底层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖于抽象
底层的接口应该是由高层提出的，然后由底层实现的
依赖倒转（倒置）的中心思想是面向接口编程，而不是面向实现编程

在Java中，抽象指的是接口或者抽象类，细节则是具体的实现类:

相对于细节的多变性，抽象的东西更稳定。以抽象为基础搭建的架构比以细节为基础的架构稳定。
使用接口或者抽象类的目的：制定规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

特点：

是实现开闭原则的重要途径之一
实现方式：在代码中使用抽象类，而将具体类放在配置文件中
继承时遵循里氏替换原则

For Example:

场景：你现在是个大学生，你想学高等数学，又想学离散数学，只有小学生才会做选择，大学生应该全都要

编写一个接口：

package com.ekin.softwaredesign.dip;
/**
 * @Author: ekin
 * @Date: 2021/4/9 15:28
 */
public interface Courses {
    void studyCourses();
}

继承接口的类：

package com.ekin.softwaredesign.dip;

/**
 * @Author: ekin
 * @Date: 2021/4/9 15:30
 */
public class StudyHigherMath implements Courses {
    @Override
    public void studyCourses() {
        System.out.println("我要学高等数学");
    }
}

package com.ekin.softwaredesign.dip;

/**
 * @Author: ekin
 * @Date: 2021/4/9 15:31
 */
public class StudyDiscreteMath implements Courses {
    @Override
    public void studyCourses() {
        System.out.println("我要学离散数学");
    }
}

将实现类联系起来：

package com.ekin.softwaredesign.dip;

/**
 * @Author: ekin
 * @Date: 2021/4/9 15:33
 */
public class Study {
    public void study(Courses courses){
        courses.studyCourses();
    }
}

测试：

package com.ekin.softwaredesign.dip;

/**
 * @Author: ekin
 * @Date: 2021/4/9 15:35
 */
public class DipTest {
    public static void main(String[] args) {
        Study s = new Study();
        s.study(new StudyDiscreteMath());
        s.study(new StudyHigherMath() );
    }
}

Console:

我要学离散数学
我要学高等数学

UML图：
在这里插入图片描述

而这个时候，你觉得自己很强，想再学一门变态难的线性代数

这个时候我们就可以新增加一个Courses接口的实现类，也就是跟 StudyDiscreteMath 和 StudyHigherMath 平级的实现类

package com.ekin.softwaredesign.dip;

/**
 * @Author: ekin
 * @Date: 2021/4/9 15:44
 */
public class StudyLinearAlgebra implements Courses {
    @Override
    public void studyCourses() {
        System.out.println("我太强了，我要再学一门线性代数");
    }
}

具体的实现类Study是不用动的

测试：

package com.ekin.softwaredesign.dip;

/**
 * @Author: ekin
 * @Date: 2021/4/9 15:35
 */
public class DipTest {
    public static void main(String[] args) {
        Study s = new Study();
        s.study(new StudyDiscreteMath());
        s.study(new StudyHigherMath() );
        s.study(new StudyLinearAlgebra());
    }
}

Console:

我要学离散数学
我要学高等数学
我太强了，我要再学一门线性代数

UML图：
在这里插入图片描述
这就是面向接口编程，不需要改动实现类，Study是解耦的

现在多用Setter方法来注入具体实现类

package com.ekin.softwaredesign.dip;

/**
 * @Author: ekin
 * @Date: 2021/4/9 15:33
 */
public class Study {
    
    private Courses courses;

    public void setCourses(Courses courses){
        this.courses = courses;
    }
    
    public void study(){
        courses.studyCourses();
    }
}

单一职责原则SRP（Single Responsibility Principle）

一个类/接口/方法只负责一项职责，“穷则独善其身”，“各行其职”。
一个类应该仅有一个引起它变化的原因,原因就是“职责”
解耦

For Example:

两个交通工具类：

package com.ekin.softwaredesign.srp;

/**
 * @Author: ekin
 * @Date: 2021/4/9 16:12
 */
public class LandVehicle {
    public void mainMoveMethod(String lName){
        System.out.println(lName + "是陆上交通工具");
    }
}

package com.ekin.softwaredesign.srp;

/**
 * @Author: ekin
 * @Date: 2021/4/9 16:19
 */
public class MaritimeVehicle {
    public void mainMoveMethod(String mName){
        System.out.println(mName + "是海上交通工具");
    }
}

测试：

package com.ekin.softwaredesign.srp;

/**
 * @Author: ekin
 * @Date: 2021/4/9 16:21
 */
public class SrpTest {
    public static void main(String[] args) {
        LandVehicle landVehicle = new LandVehicle();
        MaritimeVehicle maritimeVehicle = new MaritimeVehicle();
        landVehicle.mainMoveMethod("高铁");
        maritimeVehicle.mainMoveMethod("航空母舰");
    }
}

Console:

高铁是陆上交通工具
航空母舰是海上交通工具

UML图：
在这里插入图片描述
这样每个类都只有一个职责，符合单一职责原则，如果需要增加种类的话，再创建一个交通工具类就可以了

接口隔离原则ISP（Interface Segregation Principle）

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

例子：
一个Ability接口中定义了eat() fly() swimming()方法
鱼继承了这个接口但是它并不能执行fly()
老鹰继承了这个接口但是它并不能执行swim()

如果要符合接口隔离原则,需要为fly() eat()
和 swimming() eat() 或者为fly() eat() swimming()分别定义一个接口

总结：

符合程序设计高内聚低耦合的思想，让代码具有更高的可维护、可拓展和可读性。
可以尽量细化接口，但是要适度

迪米特法则（最少知道原则）LKP（Least Knowledge Principle）

一个对象应该对其他对象保持最少的了解，只与直接的朋友通信，只和你的朋友谈话。

降低类之间的耦合
迪米特法则又叫最小知道原则，即一个类对自己依赖的类知道的越少越好。
也就是说，对于被依赖的类不管多么复杂，都尽量将多级封装在类的内部。对外除了提供public方法，不对外泄露任何消息
直接朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系，耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现在成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
- 当前对象本身
- 通过方法的参数传递进来的对象
- 当前对象所创建的对象
- 当前对象的实例变量所引用的对象
- 方法内所创建或实例化的对象

注意：

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

For Example：

场景：Form1、Form2都指向了DAO1和DAO2；Form1、Form2、Form3都指向了DAO1、DAO2和DAO3

原来：
在这里插入图片描述
改进：

实体应该尽量减少与其他实体的交互，改进后是不是更加简洁高效了呢？

里氏替换原则LSP（Liskov Substitution Principle）

子类型必须能够替换掉它们的父类型，如果对每一个类型为T1的对象o1，都有类型为T2的对象02，使得以T1定义的所有程序P在所有的对象o1都替换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。

所有引用基类的地方必须能透明地使用其子类对象
在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法，也就是说，子类可以扩展父类的功能，但不能改变父类原有的功能
继承实际上增强了两个类的耦合性，通常的做法是让T1、T2都继承于一个更通俗的基类Base，原有的继承关系去掉，（即，父子变兄弟）改用聚合，组合，依赖来解决问题

优点：

加强程序的健壮性，提高程序的维护性、扩展性。

For Example:

场景：鲨鱼和鲸鱼都继承了鱼，但是鲸鱼重写了鱼的繁殖方式方法，把卵生改为了胎生，所以鲸鱼不是鱼
在这里插入图片描述

合成复用原则CRP(Composite Reuse Principle)

尽量使用对象组合/聚合，而不是继承关系达到软件复用的目的

例子：
类T1有方法A，类T2若想用方法A则会继承T1，但当T1新增方法的时候T2依旧继承T1，这就会造成耦合，因此需要让T1与T2之间为组合/聚合关系。

将T1重构为抽象类或接口
类T3和类T4继承T1抽象类
测试

优点：

使系统更灵活，降低类之间的耦合度
合成复用原则和里式替换原则相辅相成，两者都是开闭原则的具体实现规范

引用材料

《研磨设计模式》

到这里软件设计七大原则就讲完了，屏幕前的你感觉怎么样呢？反正我的女朋友们看了都说好！

益箴

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
1
评论
【设计模式】软件设计七大原则

文章目录软件设计七大原则单一职责原则接口隔离原则软件工程中，设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。说白了，设计模式就是在软件开发中多次出现、被大多人所认同、和语言无关、被分类过的代码设计经验的总结。而使用设计模式可以使软件具有更高的代码可重用性、可拓展性、可维护性（可读性、规范性）、可靠性，使程序更加高内聚、低耦合。既然设计模式是用于软件开发当中，那么它出现在软件的哪里呢？面向对象编程（oo）先形成功能模块（设计模式+算法），之后就是框架（多种设计模式集合），最上面
复制链接

扫一扫