[ASP.NET]91之ASP.NET由浅入深 不负责讲座 Day17 – 单一职责原则

[ASP.NET]91之ASP.NET由浅入深 不负责讲座 Day17 – 单一职责原则


前言
好的OO设计原则,可以达到高内聚低耦合的目的,
而什么是好的设计原则呢? 就是SOLID原则,刚好是由五个(也有人称六个)原则的首字母组成的缩写,SOLID也就是稳固的意思。遵守这些原则,可以让我们的设计更加稳固,更能拥抱变化。

今天这一篇,先介绍单一职责原则,也就是Single Responsibility Principle,简称SRP。

Issues
Single Responsibility Principle,简称SRP

  1. 定义
    应该有,且只有一个原因,会引起class的变更。
    原文解释:There should never be more than one reason for a class to change.

  2. 备受争议的原则
    这是一个备受争议的原则,因为要完全做到几乎是不可能的。但那是实践上的权衡取舍,基本上它还是一个好的设计原则,只单纯在实践上备受争议,在设计上这才是OO的细度到了极致的境界。

  3. 简单的说
    一个class只负责一个职责的内容。
    一个class如果要负责多个职责,其内容应该只是组合多个class,而每个被组合的class只负责单一职责,且通常这样的组合都是透过接口(interface/abstract)。

  4. 单一职责的好处
    1. class复杂性降低,因为实现什么职责都有很清楚的定义
    2. 可读性提高
    3. 可维护性提高
    4. 变更引起的风险降低,变更范围降低,扩展性提高
    单一职责,也就是高内聚力的实践方式。

  5. 实践上最困难的地方
    原则很简单,但实践上为何困难? 最难的就是定义所谓的‘职责’,以及切割class的粒度取舍。
    太细,就剁的太碎,失去实际应用上的目的。例如前一篇文章讲的乐高积木,我们要的,应该是每一个单位小到我想要组合成任何模型,都不会有本质上的困难。
    细到无穷止尽,可能就是原子的世界了,每一个人看原子,都不知道最后组出来会是长什么样子,更遑论应用它了。

  6. 取舍平衡点
    至少要做到interface的单一职责!

  7. 举例
    我们定义一个电话功能的interface
  8. public interface IPhone{
        public void dial(String phoneNumber);
        public void chat(Object o);
        public void hangUp();
    }


这是颇常见的interface定义方式,但dial与hangUp其实应该是同一职责,而chat是另一个职责才对。所以我们应该是Phone要实践这两个职责的interface。
如此一来,不论未来在修改或扩充电话的功能,都会更加清楚与独立。

Reference

  1. 设计模式之禅


或许您会对下列培训课程感兴趣:

  1. 2019/7/27(六)~2019/7/28(日):演化式设计:测试驱动开发与持续重构 第六梯次(中国台北)
  2. 2019/8/16(五)~2019/8/18(日):【C#进阶设计-从重构学会高易用性与高弹性API设计】第二梯次(中国台北)
  3. 2019/9/21(六)~2019/9/22(日):Clean Coder:DI 与 AOP 进阶实战 第二梯次(中国台北)
  4. 2019/10/19(六):【针对遗留代码加入单元测试的艺术】第七梯次(中国台北)
  5. 2019/10/20(日):【极速开发】第八梯次(中国台北)

想收到第一手公开培训课程资讯,或想询问企业内训、顾问、教练、咨询服务的,请洽 Facebook 粉丝专页:91敏捷开发之路。