单一职责原则
基本介绍
顾名思义就是想要一个类或者一个方法只做一件事，这 "一件事" 的范围自己定义，合理就好(能把别人说服就合理)。这个原则看起来很简单，其实我认为在所有的设计原则中它是最重要的，也是我们日常工作中使用最多的思想准则。
代码示例
假设我们有一个支付系统，接通了很多支付方式，如微信，支付宝，银联等等。下面是不考虑单一职责的写法：
("SRP") publicclassSRPPriciple { publicvoidpay(StringpayType) { switch (payType) { case"wxpay"->System.out.println("这里使用微信支付"); case"alipay"->System.out.println("这里使用支付宝支付"); case"unionpay"->System.out.println("这里使用银联支付"); default->thrownewIllegalArgumentException("不支持该["+payType+"]支付方式"); } } }
这里使用了switch，如果是 if-else 也同理，如果业务上需要新增一种支付方式，那么就需要修改这段代码添加一个新的 case 语句。这样会有几个问题：
- 我们每次新增一种支付方式时，其实与其他支付方式无关，但是现在代码又耦合在一起，很容易在多次迭代以后导致其他支付方式的代码被无疑间修改了
- 如果写这段代码的人离职了，下一个接手的人来维护这段代码，随着业务逻辑又来越多，客户提出的支付形式越来越无理，这个类中的代码就会越来越复杂
综上所述，使用单一职责思想重构如下：
publicinterfacePayService { voidpay(); } publicclassWxpayServiceimplementsPayService { publicvoidpay() { System.out.println("这里使用微信支付"); } } publicclassAlipayServiceimplementsPayService { publicvoidpay() { System.out.println("这里使用支付宝支付"); } } publicclassUnionpayServiceimplementsPayService { publicvoidpay() { System.out.println("这里使用银联支付"); } }
其实就是将每一种的支付逻辑隔离出来，互不影响，做到低耦合。
闲扯时间
说实话有时候使用单一职责思想去重构项目中既存的代码，很难达到所给示例的效果，因为一座 "屎山" 怎么可能就用几个设计原则及模式就能优化好呢，所以我认为我们需要有这种单一职责的思想就好，至于用不用，何使用，怎么用，这就得分场景，分项目，分目前的情况而定，切勿为了用而用。
