前言

今天来聊一聊单一职责原则

背景

有两个端，移动端和服务端，起先设计是有两个接口，一个接口用于查询，一个用于更新。

客户端要求在更新接口在没有查询到对应数据的时候可以把数据更新到数据库。但是服务端却没有做这个功能，他把这个功能做到了查询接口，也就是要想更新一条新的数据要先调用查询接口。

这对客户端来说是不能接受的，有以下这么几个缺点：

  1. 需要两次网络IO，时间变长了，网络操作比数据库操作要慢
  2. 更新接口就变成了必须要依赖查询接口
  3. 查询接口如果出问题了，更新接口就无法更新数据，这部分数据就会丢失，程序健壮性就低了
  4. 更新接口没有对返回结果进行错误处理，更新失败和成功都不知道，返回都是成功。

基于以上缺点，客户端向服务端提出在更新接口增加没有记录的时候可以插入到数据库中。

但是服务端却不愿意，给出的理由是单一职责，在更新接口不应该做插入操作，而且会增加时长。如果非要做更新操作就增加一个插入接口。

单一职责

首先单一职责是面向对象设计原则中的一条，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

虽然单一职责原则并不是针对服务端接口的原则，而是面向对象中的原则。我们假设单一职责适用于服务端接口设计，按照这个原则，严格来说更新接口做插入操作是有点不合适。

但是在这种情况下单一职责，会让问题变得复杂，影响用户体验。

本来单一职责原则的本意是提高系统的可维护性，可读性，降低复杂度。用在这个地方却增加了复杂度，多了一个接口可维护性也没有提高多少，可读性的提高也不大，总共就2个接口，对于人的记忆不会有负担。

思考

按照单一职责原则没有正收益，反而有许多坏处。但却还要一直坚持，就显得有些教条了。

我们学一个东西的时候，需要根据具体的场景去应用，并不是一味的去强调某个原则。

这些原则也是抽象出单一场景下的使用方式，但是现实往往比较复杂，应该从整个开发流程去看，寻找出一个最优解，在这些情况下需要对某些原则做一些权衡。

不能因为某个原则而忽略掉其它，用单一视角看问题。