六大设计原则之单一职责原则（SRG）

最新推荐文章于 2024-08-12 09:31:39 发布

yhanw

最新推荐文章于 2024-08-12 09:31:39 发布

阅读量346

点赞数

文章标签：设计原则 java 接口

本文链接：https://blog.csdn.net/qq_34966814/article/details/79476040

版权

设计模式专栏收录该内容

3 篇文章 0 订阅

订阅专栏

在做代码练习或者开发的过程中，我们会发现自己写的类越来越大，该类的功能也越来越多。有一些开发者包括之前的我看到自己写的类够大，功能够多是往往会充满自豪感。但是当某个功能需要做一个小改动时，就会发现整个程序出现了各种大大小小的问题。

为什么知识对这个类的一个功能做了小小的修改就会引起这么大的问题？因为我们违反了单一职责原则。将多种功能集成在一个类中，就等于把这些功能耦合了起来，一个功能的变化可能会削弱或者抑制这个类完成其他职责的能力。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

1. 解说定义

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。

在一个类中，可以导致类变更的因素最多只能有一个。何为类变更呢？当你要改变该类中某些代码时，该类的某些用途或特性会随着改变。
但是无论你怎么改，这个类只有最多一个用途或特性改变了，而不会再有其他的改变。只有这样一个类的改变对其他使用到该类的模块影响才会达到最低。也只有一个类只实现一个功能时才能做到到这种最小的改变。

2. 问题由来

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

3. 解决办法

遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

4.职责扩散

很多程序员都清楚自己编程时要遵循单一职责原则，但总是在不经意间违反了这个原则。因为某种原因，某一职责需要分化为粒度更细的多个职责了，这就是职责扩散。

5.例子

public interface ICar { 
    //品牌
    void setPinPai(String pinpai);
    void getPinPai();
    //颜色
    void setColor(String color);
    void getColor();
    //启动
    boolean Start(boolean start);
    //停车
    boolean Stop(boolean stop);
}

从上面例子中，我们不知道这个接口的具体职责是什么，有点模糊不清。车子的品牌和颜色是车子的属性，而启动和停车是车子的行为，将车子的属性和行为耦合到一个接口中，给人一种结构职责不清的感觉，对后期的维护带来一定的麻烦。

为了解决这个问题，应当使用单一职责原则，将车子接口中的业务对象（属性）和业务逻辑（行为）解耦，分成两个接口，如下：

/**
 * BO：Bussiness Object，业务对象  
 * 负责车子的属性  
 * @author 叶汉伟
 */
public interface ICarBO {
    //品牌
        void setPinPai(String pinpai);
        void getPinPai();
        //颜色
        void setColor(String color);
        void getColor();
}

/**  
 * BL:Business Logic,业务逻辑  
 * 负责车子的行为  
 * @author 叶汉伟
 */ 
public interface ICarBL {
    //启动
    boolean Start(boolean start);
    //停车
    boolean St#p%Cspan class="hljs-params">(boolean stop);
}