设计模式（一）：单一职责原则

什么是单一职责原则？

定义：应该有且仅有一个原因引起类的变更

为什么要有单一职责原则？

单一职责原则为我们提供了一个编写程序的思想，要求我们在编写类，抽象类，接口时，要使其功能职责单一，将导致其变更的因素缩减到最少。如果一个类的职责过多，则多个职责耦合在一起，那么就会有多个因素导致这个类发生变化，并且一个职责的变化可能会影响到其他的职责，不利于可重用性。

单一职责具有以下优点：

• 降低类的复杂度；
• 提高类的可读性，提高系统的可维护性；
• 降低变更引起的风险；

单一职责的实现与思考

例：有一个需求要求实现：根据原材料加工生产出产品 A 和产品 B

可见通过 productA 和 productB 方法是可以正常加工生产出 A 产品和 B 产品，现由于 A 产品销量不好，工厂决定将 A 产品材料加工规则改变，B 产品不变。则按照上面代码的逻辑，B 产品也会使用新的材料加工规则，故不符合新的需求。

我们可以看出 ProductFactory 这个类有两个引起其发生变化的因素：A 产品更改因素和 B 产品更改因素，这就与单一职责原则相违背。

所以对于工厂的需求，按照单一职责原则我们应该这样设计：

将原先的 ProductFactory 设计成接口，通过实现该接口生成 AProductFactory类和 BProductFactory 分别生产 A 和 B

通过以上代码，我们可以发现无论任何一个产品改动的时候，也不会影响到其他产品的生产，即使后续新增产品，也可以横向添加XProductFactory 生产产品。

但是很遗憾 ProductFactory 依旧不是职责单一的，从纵向方向来看，ProductFactory 具有颗粒更小的职责：材料加工，生产产品的职责。为了贯彻单一职责的思想，我们将两个职责设计成两个接口

通过实现 IProductFactory，IMaterialProcessing 两个接口实现材料加工类和产品工厂类，通过对应的产品工厂类生成产品。至此代码已符合职责单一原则，显而易见地这也从一个类即可实现的功能变成六个类去实现，若只是单单几个小功能可以如上设计。而对于功能繁多的中大型系统而言，如此设计会导致功能实现繁琐，后期也不利于维护。

规矩是死的，人是活的

我们在接口设计的时候需要尽量做到职责单一，生搬硬套单一职责原则会引起类的爆增，不利于维护同时加大系统的复杂性。单一职责最难划分的是职责，类的职责和变更因素因项目而不同，因环境而不同，并不是要求类的功能拆分的越细越好，对类的功能细分需要我们有足够的开发经验和能力去具体分析。

下期文章《设计模式之里氏替换原则》

更多知识干货，欢迎关注我们的微信公众号:IT界的泥石流