设计模式笔记:单一职责原则(SRP, Single Responsibility Principle)

1. 单一职责原则核心思想

  一个类应该有且只有一个变化的原因。

2. 为什么引入单一职责原则

  单一职责原则将不同的职责分离到单独的类,每一个职责都是一个变化的中心。

  在SRP中,把职责定义为变化的原因。

  当需求变化时,将通过更改职责相关的类来体现。如果一个类拥有多于一个的职责,则多个职责耦合在一起,会有多于一个原因来导致这个类发生变化。一个职责的变化可能会影响到其他的职责,另外,把多个职责耦合在一起,影响复用性。

3. 单一职责原则的优点

(1)降低类的复杂度;
(2)提高类的可读性,提高系统的可维护性;
(3)降低变更引起的风险(降低对其他功能的影响)。

4. 单一职责原则实现

  单一职责原则关键点:要求接口的职责单一,从而实现该接口的类的职责单一。

  《设计模式笔记:单一职责原则(SRP, Single Responsibility Principle)》

        Socket实现类的职责分离

  IDataChannel职责:数据通信

  IConnection职责:连接管理

  SocketImplementation:两个职责耦合,这不是所希望的,但或许是必要的。

5. 单一职责原则重构

  业务规则和持久化两个职责应该分开:业务规则往往会频繁变化,而持久化的方式却不会如此频繁的变化,并且变化的原因完全不同。

  违反SRP原则的重构可采取设计模式:外观模式(Facade)代理模式(Proxy)数据访问对象(DAO)

6. 使用单一职责原则的注意点

(1)单一职责最难划分的是职责。
(2)单一职责原则提出标准:用职责和变化原因来衡量接口或类设计的是否优良,但是职责和变化原因都是不可度量的,因项目、环境而异。
(3)接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。

    原文作者:libingql
    原文地址: https://www.cnblogs.com/libingql/p/3804327.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞