设计模式七大原则

2023-07-09 56

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 在日常的开发工作中，常常会被领导要求代码易维护，可扩展，成体系等等的一系列要求，我想设计模式就是应对这种情况而生的吧。最开始我也很反感，觉得为什么总是把简单的代码复杂化，设计模式又很难运用，生搬硬套。但是当我反复的推敲这种思想后，发现并不是很难用，而是我不够熟练；并不是生搬硬套，而是我没有理解它的思想；我想说的是那么多的设计模式在实际使用中并不会仅单单的使用某一种去解决问题，大部分都是相互的组合使用，并且没有固定的方式，在合适的场景中使用合适的设计模式才能使我们的代码更加合理。而个人认为设计原则的重要性远在设计模式之上。

单一职责原则

基本介绍

顾名思义就是想要一个类或者一个方法只做一件事，这 "一件事" 的范围自己定义，合理就好(能把别人说服就合理)。这个原则看起来很简单，其实我认为在所有的设计原则中它是最重要的，也是我们日常工作中使用最多的思想准则。

代码示例

假设我们有一个支付系统，接通了很多支付方式，如微信，支付宝，银联等等。下面是不考虑单一职责的写法：

@Component("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();
}
@ComponentpublicclassWxpayServiceimplementsPayService {
@Overridepublicvoidpay() {
System.out.println("这里使用微信支付");
    }
}
@ComponentpublicclassAlipayServiceimplementsPayService {
@Overridepublicvoidpay() {
System.out.println("这里使用支付宝支付");
    }
}
@ComponentpublicclassUnionpayServiceimplementsPayService {
@Overridepublicvoidpay() {
System.out.println("这里使用银联支付");
    }
}

其实就是将每一种的支付逻辑隔离出来，互不影响，做到低耦合。

闲扯时间

说实话有时候使用单一职责思想去重构项目中既存的代码，很难达到所给示例的效果，因为一座 "屎山" 怎么可能就用几个设计原则及模式就能优化好呢，所以我认为我们需要有这种单一职责的思想就好，至于用不用，何使用，怎么用，这就得分场景，分项目，分目前的情况而定，切勿为了用而用。

设计模式七大原则

单一职责原则

基本介绍

代码示例

闲扯时间

热门文章

最新文章

相关课程

相关电子书