设计原则-单一职责原则

最新推荐文章于 2024-07-06 08:31:04 发布

阿常呓语

最新推荐文章于 2024-07-06 08:31:04 发布

阅读量386

点赞数

分类专栏：设计原则文章标签：单一职责原则

本文链接：https://blog.csdn.net/u010339879/article/details/122462586

版权

设计原则专栏收录该内容

5 篇文章 0 订阅

订阅专栏

单一职责原则

文章目录

单一职责原则

概述

在软件领域，我们有时候写代码的过程中，有时候会遇到一些问题，这些问题已经被前人进行总结归纳。帮助我们在遇到问题的时候，如何写出更加优雅的代码，更加简洁的代码，更加没有重复的代码等。于是就出现了很多设计原则，通过这些设计原则可以帮助我们写出更加优雅的代码，以及可以应对以后代码的可能变动。实现低耦合，高内聚，代码复用的特点。今天我们就来学习软件设计原则之一，单一职责原则这一原则开起来简单，但实际在工作编码过程中却很容易忽略。写代码的时候，可以多想想有没有坚持这个原则，刻意地朝这个方向努力吧。废话不多说，进入正题。

单一职责原则，英文缩写SRP，全称Single Responsibility Principle。

原始定义：There should never be more than one reason for a class to change。

官方翻译：应该有且仅有一个原因引起类的变更。简单点说，一个类，最好只负责一件事，只有一个引起它变化的原因。

一个类应该仅有一个引起它变化的原因
变化的方向隐含着类的责任(职责)

单一职责原则问题由来

类T 负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生问题.

如果一个类承担的职责过多，就等于把这些职责耦合在一起了。
一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。
此原则的在一定程度上解耦和增强内聚性，是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。

职责如何理解呢? 什么是职责呢 ?

在 SRP中职责就是 “变化的原因” (a reason for change), 如果你能想到有两个原因将来会修改这个类,那么就说明这个类承担了多个职责. 其实有的时候,我们却很难意识到这一点, 总是会把一个类写的比较大,功能比较全面,所谓"功能强大"的类.

举例1 Rectangle

class Rectangle:
    """
    假设这个类

    有两个不同的 application 使用

     一个application 有关计算几何学的, 这个类会提供几何形状计算方面的帮助, 但它从来不会绘制矩形

     另一个application 有关图形绘制方面的, 它可能也会进行几何学方面的工作,但是它一定会在屏幕上绘制矩形.



    这个设计违反了单一职责原则(SRP).Rectangle类具有两个职责
        第一个职责提供了一个矩形几何形状的数学模型；
        第二个职责是把矩形在一个图形用户界曲上绘制出来。

    """

    def draw(self) -> None:
        pass

    def area(self) -> float:
        pass

所以应该职责划分更加清晰一些,类似下面的代码一样, 职责明确.

class Rectangle:
    def draw(self) -> None:
        pass


class GeometricRectangle:
    def area(self) -> float:
        pass

个人理解

当然这些都是建立在我的虚拟假设上将来有一个应用会使用两个方法, 一个应用只会使用一个方法, 计算面积.并且两个这两个应用是独立的. 如果说这个应用同时会用到几何形状计算, 和绘制的方法, 我觉得就没有必要分成两个单独的类. 因为此时改变这个类的原因只有一个. 即职责也只有一个. 所以对职责的界定相对比较宽松,取决于你系统的环境.

再来回忆一下职责: 变化的原因

举例2 Modem

假设有一个调节器, 有以下接口:

from abc import abstractmethod


class Modem:
    """
    调制解调器
    """

    @abstractmethod
    def dial(self, pro):
        pass

    @abstractmethod
    def hungup(self):
        pass

    @abstractmethod
    def send(self):
        pass

    @abstractmethod
    def recv(self):
        pass

首先看这个类有四个接口. 都是和调解器的接口. 看起来也很合理. 但是仔细想想

这个有两个职责 ,连接管理和数据通信 .

连接管理
dail
hungup

数据通信
recv
send

这个时候有必要把它们分开吗? 这要考虑一个问题, 如果应用程序的变化会影响连接的方式,那么就要分开这个职责. 另外一方面如果应用程序变化会导致这两个职责同时变化,那么就没有必要拆分它们. 实际上拆分它们就会具有不必要的复杂性的臭味.

在此还有一个推论, 变化的轴线仅当变化实际发生时,才有意义. 如果没有征兆 ,就去应用SRP, 这是不明智的. 就是取决于系统的变化. 系统如果不变, 这样的设计也没有什么问题啊.

SRP核心思想

SRP 核心思想就是要降低类的修改成本,防止未来发生变化,改动一个类的很多处,难免会出现问题. 把职责明确划分好后,这样就可以应对以后的变化. 打个比方, 你是想把工具归置到许多抽屉, 每个抽屉中装有定义和标记良好的工具箱, 还是想把少数几个能随便把所有东西扔进一个抽屉呢? 我想你会把不同的物件归置到不同的抽屉里面吧,这样第一方便查找,第二方便修改,可以应对未来可能的变化.

目标:

我们的目标就是要分离耦合的职责, 使不同的职责在不同的类中, 而不是一个类中有多个职责.