设计模式之七大设计原则

最新推荐文章于 2024-11-15 22:23:28 发布

doordiey

最新推荐文章于 2024-11-15 22:23:28 发布

阅读量221

点赞数

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

本文链接：https://blog.csdn.net/doordiev/article/details/109146300

版权

设计模式笔记专栏收录该内容

2 篇文章 0 订阅

订阅专栏

设计模式

目的：为了让程序有更好的代码的重用性（相同功能代码不用多次编写）、可读性（编程的规范性）、可扩展性（增加新的功能时，非常的方便）、可靠性（当增加新功能后，对原有功能没有影响）、使程序呈现高内聚，低耦合。

单一职责原则

基本介绍

对类来说，即一个类只负责一项指责x

应用实例

交通工具运行方式举例
- 方式1中run 方法，违法了单一职责原则，解决该办法，根据不同的方式，拆分不同的类出来。
- 方式2中遵守了单一职责原则，但改动很大，将类分解了，修改过多。
- 方式3中没有对类进行大改动，只是增加方法，在方法级别上遵守单一职责，在类这个级别上没有遵守单一职责原则。

单一职责原则的注意和细节

降低类的复杂度
降低变更带来的风险
提高类的可读性，可维护性
通常情况下，要遵守单一职责原则，如果逻辑很简单，可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

接口隔离原则

基本介绍

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

应用实例

需求如下

按照需求编写接口及对应类

没有满足接口隔离原则，一个类对另一个类的依赖并不建立在最小的接口上

将原本的进行拆分

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ActonKFH-1603008619086)(C:\Users\lenovo\AppData\Roaming\Typora\typora-user-images\1597801719284.png)]

依赖倒转原则

基本介绍

高层模块不应该依赖底层模块，应该依赖其抽象
抽象不应该依赖细节，细节要依赖抽象
依赖倒转的中心思想是面向接口编程
设计理念：对应于细节的多变性，抽象的东西稳定的多
使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作

实际案例

有一个person类接收消息的功能

传统发放实现

简单
如果获取的对象是微信、短信等，就需要新增类，同时person类也要增加相应的接收方法

应用依赖倒转原则实现

引入一个抽象的接口，表示接收者，这样person类和接口发生依赖。

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

通过接口实现依赖传递

interface IOpenAndClose{
    public void open(ITV tv);
}
interface ITV{
    public void play();
}
class OpenAndClose implements IOpenAndClose{
    @Override
    public void open(ITV tv) {
        tv.play();
    }
}

通过构造方法依赖传递

interface IOpenAndClose{
    public void open();
}
interface ITV{
    public void play();
}
class OpenAndClose implements IOpenAndClose{
    public ITV itv;
    public OpenAndClose(ITV itv){
        this.itv = itv;
    }
    public void open(){
        this.itv.play();
    }
}

通过setter方法传递

interface IopenAndClose{
    public void open();
    public void setTv(ITV itv);
}
interface ITV{
    public void play();
}

class OpenAndClose implements IopenAndClose{
    private ITV itv;

    @Override
    public void setTv(ITV itv) {
        this.itv = itv;
    }

    @Override
    public void open() {
        this.itv.play();
    }
}

注意事项和细节

底层模块尽量都要有抽象类或接口，程序稳定性更好
变量的声明类型尽量是抽象类或接口，变量引用和实际对象间就存在一个缓冲，有利于程序扩展和优化
继承时遵循里氏替换原则

里氏替换原则

基本介绍

如果对每一个类型位T1的对象o1，都有类型位T2的对象o2，即所有引用基类的地方必须能透明地使用其子类的对象
在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法
继承实际上让两个类的耦合性增强，在适当情况下，可以通过聚合，组合，依赖来解决问题

实际案例

继承时无意修改了父类

按照里氏替换原则改写

让原有的父类和子类都继承一个更通俗的基本类，将原有的继承关系去掉，使用组合等方式替代

开闭原则

基本介绍

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

实际案例

完成一个画图形的功能
类图设计如下：

分析

好理解，简单
违反了设计模式的ocp原则
如果要多画三角形，要修改的地方较多

按照ocp原则修改

思路

把创建Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现就可

迪米特法则

基本介绍

一个对象应该对其它对象保持最少的了解
类与类关系越密切，耦合度越大
迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多复杂，都尽量将逻辑封装在类的内部
只与直接的朋友通信
- 直接的朋友：每个对象都会与其它对象有耦合关系，有耦合关系就是朋友关系，出现成员变量、方法参数、方法返回值中的类为直接朋友，如果是出现在局部变量中的类不是直接的朋友。
- 也就是说：陌生的类最好不要以局部变量的形式出现在类的内部