3. 单一职责

按照管理，出一个文章节选

核心思想就是：一个类、甚至一个方法别做太多的功能，比如说订单接口不要去做支付相关接口，举例说明违背单一职责的缺点：

1. 代码可能会很多，一个方法可能会有好几千行代码
2. 阅读性不好，一个接口做很多事很难看清他的所有业务逻辑，也很难知道这个类到底是做什么的。
3. 扩展性不好 ，因为一个方法做了很多事情，一旦需求新增了一些功能点或者修改了功能点，五千来行代码的话对于应届生基本很难去改

但是有时候单一职责是可以打破的，原则就是用来打破的

1. 某个类只干一件事，里面有一个方法，只有一处用到了，但是的流程特别多，那么里面的流程都封装成一个个小类吗，那样只因为一个地方使用多出四五个类，对于架构设计是很不友好的。
   把这些流程封装成一个个小方法放到这个类中，并把小方法用private修饰上，写好注释，让主方法调用，会更好一些。因为如果设计过多的类只为了在一个地方用，就导致类臃肿了，架构就复杂了，有的人喜欢叫“类爆炸”。
2. 就业务层面，而非技术层面的场景。比如很多活动但是都是在近期，接口着急上线，活动过了就在也用不到的接口，比如今年的情人节促销，在明年肯定是不一样的活动， 既然都是要废弃的接口，而且着急上线，那就赶紧写完吧，过几天活动过完在申请接口下线删除就行了（之前有感慨，疯狂设计，服务下线）。