代码设计原则之单一原则

前言

设计原则是比设计模式更为抽象的概念，设计模式可以说是设计原则的具象化，因此学习并掌握设计原则，才能更好的使用设计模式。

在实际代码开发中，自己有时也会对该遵循哪种设计原则，运用哪种设计模式而难以抉择。不知你们是否会有这种感觉：遵循了设计原则A，但是又看起来违背了设计原则B。这或许便是对设计原则理解不够深刻，或许我们陷入了一个误区，为了设计原则/设计模式而去编写设计原则/设计模式的代码。
而实际上，设计原则/设计模式本质上是服务于编写高质量代码的，从而提高代码的可维护性、可读性、可扩展性、灵活性、简洁性等。

如何理解单一职责原则（SRP）

A class or module should have a single reponsibility
一个类或者模块只负责完成一个职责（或者功能）

单一职责原则的定义描述非常简单：
一个类只负责完成一个职责或者功能。也就是说，不要设计大而全的类，要设计粒度小、功能单一的类。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。

一看就会，一做就废系列.gif

案例分析一

一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。

在你们的产品首页，是一个返回各种数据的图表面板。下面是返回数据的类，你觉得是否满足单一原则

public class ChartServiceImpl {
    // 获取图表定义
    public List<Chart> getCharts() {...}
    // 获取图表数据
    public List<Data> getChartData() {
          ...
          Chart chart = parseChartConfig(chart);
          ...
    }
    // 解析图表配置
    private Chart parseChartConfig(Chart chart) {...}
}

随着需求的迭代变更，当图表的解析规则发生变化时，就需要改动parseChartConfig方法；当图表的取数逻辑或是数据的处理方式发生变动时，就需要更改getChartData方法。

两种情况，都会引起ChartServiceImpl类的修改。

刚开始，业务简单的时候，我们可以暂时将这些方法放置在一起，写一个粗粒度的类，满足业务需求。当随着业务的复杂，类开始朝着臃肿发展时，你就需要考虑将一些方法剥离出来，就如上面例子的parseChartConfig方法，你可以新建一个类专门去处理图表配置解析，如 ChartConfigParser。

类的职责是否越单一越好？

答案当然是否定的，类的粒度拆分得越细，我们需要维护的类就越多，反而导致功能过度分散，而不是内聚了。

看一个解析key字符串为对象和转换key对象为json的例子

public class KeyProcessor {
    // 解析规则，可能存在某些key需要特殊处理等
    private static final Map<String, Object> rules; 
    
    public Key parseJson2Key(Sting keyJson) {
        // 将json根据规则解析成key对象
    }
    
    public String convert2Json(Key key) {
        // 将key根据对着转换成json字符串，用于持久化等
    ｝
}

如果让类的职责更加单一的话，将上面的类拆分成两个：

public class KeyParser {
    // 解析规则，可能存在某些key需要特殊处理等
    private static final Map<String, Object> rules; 
    
    public Key parseJson2Key(Sting keyJson) {
        // 将json根据规则解析成key对象
    }
}

public class KeyConverter {
    // 解析规则，可能存在某些key需要特殊处理等
    private static final Map<String, Object> rules; 
    
    public String convert2Json(Key key) {
        // 将key根据对着转换成json字符串，用于持久化等
    ｝
}

拆分后类的职责更加单一了，但是当规则有所变更的时候，就需要同时对两个类进行修改，代码的内聚性没以前高了，维护成本也变高了，也就是说，经过拆分，代码的可维护性变差了，这可不是我们想要的结果。

实际上，不管是应用设计原则还是设计模式，最终的目的还是提高代码的可读性、可扩展性、复用性、可维护性等。我们在考虑应用某一个设计原则是否合理的时候，也可以以此作为最终的考量标准。

回顾总结

1. 如何理解单一职责原则（SRP）？
一个类只负责完成一个职责或者功能。不要设计大而全的类，要设计粒度小、功能单一的类。单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。

2. 如何判断类的职责是否足够单一？

类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
比较难给类起一个合适名字，很难用一个业务名词概括，这就说明类的职责定义得可能不够清晰；
类中大量的方法都是集中操作类中的某几个属性，此时应考虑对属性进行拆分