9條消除if...else的錦囊妙計,助你寫出更優雅的程式碼
前言
最近在做程式碼重構,發現了很多程式碼的爛味道。其他的不多說,今天主要說說那些又臭又長的if...else要如何重構。
在介紹更更優雅的程式設計之前,讓我們一起回顧一下,不好的if...else程式碼
一、又臭又長的if...else
廢話不多說,先看看下面的程式碼。
public interface IPay {
void pay();
}
@Service
public class AliaPay implements IPay {
@Override
public void pay() {
System.out.println("===發起支付寶支付===");
}
}
@Service
public class WeixinPay implements IPay {
@Override
public void pay() {
System.out.println("===發起微信支付===");
}
}
@Service
public class JingDongPay implements IPay {
@Override
public void pay() {
System.out.println("===發起京東支付===");
}
}
@Service
public class PayService {
@Autowired
private AliaPay aliaPay;
@Autowired
private WeixinPay weixinPay;
@Autowired
private JingDongPay jingDongPay;
public void toPay(String code) {
if ("alia".equals(code)) {
aliaPay.pay();
} else if ("weixin".equals(code)) {
weixinPay.pay();
} else if ("jingdong".equals(code)) {
jingDongPay.pay();
} else {
System.out.println("找不到支付方式");
}
}
}
PayService類的toPay方法主要是為了發起支付,根據不同的code,決定呼叫用不同的支付類(比如:aliaPay)的pay方法進行支付。
這段程式碼有什麼問題呢?也許有些人就是這麼幹的。
試想一下,如果支付方式越來越多,比如:又加了百度支付、美團支付、銀聯支付等等,就需要改toPay方法的程式碼,增加新的else...if判斷,判斷多了就會導致邏輯越來越多?
很明顯,這裡違法了設計模式 六大原則的:開閉原則 和 單一職責原則。
❝
開閉原則:對擴充套件開放,對修改關閉。就是說增加新功能要儘量少改動已有程式碼。
❞
❝
單一職責原則:顧名思義,要求邏輯儘量單一,不要太複雜,便於複用。
❞
那有什麼辦法可以解決這個問題呢?
二、消除if...else的錦囊妙計
1、使用註解
程式碼中之所以要用code判斷使用哪個支付類,是因為code和支付類沒有一個繫結關係,如果繫結關係存在了,就可以不用判斷了。
我們先定義一個註解。
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface PayCode {
String value();
String name();
}
在所有的支付類上都加上該註解
@PayCode(value = "alia", name = "支付寶支付")
@Service
public class AliaPay implements IPay {
@Override
public void pay() {
System.out.println("===發起支付寶支付===");
}
}
@PayCode(value = "weixin", name = "微信支付")
@Service
public class WeixinPay implements IPay {
@Override
public void pay() {
System.out.println("===發起微信支付===");
}
}
@PayCode(value = "jingdong", name = "京東支付")
@Service
public class JingDongPay implements IPay {
@Override
public void pay() {
System.out.println("===發起京東支付===");
}
}
然後增加最關鍵的類:
@Service
public class PayService2 implements ApplicationListener<ContextRefreshedEvent> {
private static Map<String, IPay> payMap = null;
@Override
public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {
ApplicationContext applicationContext = contextRefreshedEvent.getApplicationContext();
Map<String, Object> beansWithAnnotation = applicationContext.getBeansWithAnnotation(PayCode.class);
if (beansWithAnnotation != null) {
payMap = new HashMap<>();
beansWithAnnotation.forEach((key, value) ->{
String bizType = value.getClass().getAnnotation(PayCode.class).value();
payMap.put(bizType, (IPay) value);
});
}
}
public void pay(String code) {
payMap.get(code).pay();
}
}
PayService2類實現了ApplicationListener介面,這樣在onApplicationEvent方法中,就可以拿到ApplicationContext的例項。我們再獲取打了PayCode註解的類,放到一個map中,map中的key就是PayCode註解中定義的value,跟code引數一致,value是支付類的例項。
這樣,每次就可以每次直接透過code獲取支付類例項,而不用if...else判斷了。如果要加新的支付方法,只需在支付類上面打上PayCode註解定義一個新的code即可。
注意:這種方式的code可以沒有業務含義,可以是純數字,只有不重複就行。
2、動態拼接名稱
該方法主要針對code是有業務含義的場景。
@Service
public class PayService3 implements ApplicationContextAware {
private ApplicationContext applicationContext;
private static final String SUFFIX = "Pay";
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
public void toPay(String payCode) {
((IPay) applicationContext.getBean(getBeanName(payCode))).pay();
}
public String getBeanName(String payCode) {
return payCode + SUFFIX;
}
}
我們可以看到,支付類bean的名稱是由code和字尾拼接而成,比如:aliaPay、weixinPay和jingDongPay。這就要求支付類取名的時候要特別注意,前面的一段要和code保持一致。呼叫的支付類的例項是直接從ApplicationContext例項中獲取的,預設情況下bean是單例的,放在記憶體的一個map中,所以不會有效能問題。
特別說明一下,這種方法實現了ApplicationContextAware介面跟上面的ApplicationListener介面不一樣,是想告訴大家獲取ApplicationContext例項的方法不只一種。
3、模板方法判斷
當然除了上面介紹的兩種方法之外,spring的原始碼實現中也告訴我們另外一種思路,解決if...else問題。
我們先一起看看spring AOP的部分原始碼,看一下DefaultAdvisorAdapterRegistry的wrap方法
public Advisor wrap(Object adviceObject) throws UnknownAdviceTypeException {
if (adviceObject instanceof Advisor) {
return (Advisor) adviceObject;
}
if (!(adviceObject instanceof Advice)) {
throw new UnknownAdviceTypeException(adviceObject);
}
Advice advice = (Advice) adviceObject;
if (advice instanceof MethodInterceptor) {
return new DefaultPointcutAdvisor(advice);
}
for (AdvisorAdapter adapter : this.adapters) {
if (adapter.supportsAdvice(advice)) {
return new DefaultPointcutAdvisor(advice);
}
}
throw new UnknownAdviceTypeException(advice);
}
重點看看supportAdvice方法,有三個類實現了這個方法。我們隨便抽一個類看看
class AfterReturningAdviceAdapter implements AdvisorAdapter, Serializable {
@Override
public boolean supportsAdvice(Advice advice) {
return (advice instanceof AfterReturningAdvice);
}
@Override
public MethodInterceptor getInterceptor(Advisor advisor) {
AfterReturningAdvice advice = (AfterReturningAdvice) advisor.getAdvice();
return new AfterReturningAdviceInterceptor(advice);
}
}
該類的supportsAdvice方法非常簡單,只是判斷了一下advice的型別是不是AfterReturningAdvice。
我們看到這裡應該有所啟發。
其實,我們可以這樣做,定義一個介面或者抽象類,裡面有個support方法判斷引數傳的code是否自己可以處理,如果可以處理則走支付邏輯。
public interface IPay {
boolean support(String code);
void pay();
}
@Service
public class AliaPay implements IPay {
@Override
public boolean support(String code) {
return "alia".equals(code);
}
@Override
public void pay() {
System.out.println("===發起支付寶支付===");
}
}
@Service
public class WeixinPay implements IPay {
@Override
public boolean support(String code) {
return "weixin".equals(code);
}
@Override
public void pay() {
System.out.println("===發起微信支付===");
}
}
@Service
public class JingDongPay implements IPay {
@Override
public boolean support(String code) {
return "jingdong".equals(code);
}
@Override
public void pay() {
System.out.println("===發起京東支付===");
}
}
每個支付類都有一個support方法,判斷傳過來的code是否和自己定義的相等。
@Service
public class PayService4 implements ApplicationContextAware, InitializingBean {
private ApplicationContext applicationContext;
private List<IPay> payList = null;
@Override
public void afterPropertiesSet() throws Exception {
if (payList == null) {
payList = new ArrayList<>();
Map<String, IPay> beansOfType = applicationContext.getBeansOfType(IPay.class);
beansOfType.forEach((key, value) -> payList.add(value));
}
}
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
public void toPay(String code) {
for (IPay iPay : payList) {
if (iPay.support(code)) {
iPay.pay();
}
}
}
}
這段程式碼中先把實現了IPay介面的支付類例項初始化到一個list集合中,返回在呼叫支付介面時迴圈遍歷這個list集合,如果code跟自己定義的一樣,則呼叫當前的支付類例項的pay方法。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69989270/viewspace-2754879/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 專案管理的20條錦囊妙計(轉)專案管理
- 編寫更優雅的 JavaScript 程式碼JavaScript
- PowerJob 應對龐大任務的錦囊妙計:MapReduce
- 如何寫出優雅的程式碼?
- 寫出優雅的js程式碼JS
- 【硬核】23種設計模式娓娓道來,助你優雅的編寫出漂亮程式碼!設計模式
- MySQL DBA必備工具使用的6大錦囊妙計MySql
- 如何寫出優雅耐看的JavaScript程式碼JavaScript
- 如何寫出更優質的程式碼
- 程式碼質量管理——如何寫出優雅的程式碼
- 分享常用的CSS函式,助你寫出更簡潔的程式碼CSS函式
- 幾個簡單的技巧讓你寫出的vue.js程式碼更優雅Vue.js
- PHPer這樣寫程式碼也許更優雅PHP
- 程式碼這樣寫更優雅 (Python 版)Python
- 程式碼這樣寫更優雅(Python 版)Python
- 使用列舉來寫出更優雅的單例設計模式單例設計模式
- 騎行體驗?達索系統SIMULIA有“錦囊妙計”。
- 助您寫出優雅的Java程式碼七點建議Java
- 如何用 es6+ 寫出優雅的 js 程式碼JS
- React jsx 中寫更優雅、直觀的條件運算子ReactJS
- 編寫優雅程式碼的最佳實踐
- 程式設計師工作中的三個錦囊程式設計師
- 如何提高Java程式碼質量-優雅的寫程式碼Java
- 5款工具助你寫出更好的Java程式碼Java
- 優雅的程式碼
- golang如何優雅的編寫事務程式碼Golang
- 我是如何將業務程式碼寫優雅的
- 如何用 SpringBoot 優雅的寫程式碼Spring Boot
- JavaScript 複雜判斷的更優雅寫法JavaScript
- JavaScript複雜判斷的更優雅寫法JavaScript
- 使用Async,讓你的Node.js程式碼更優雅Node.js
- 一些技巧讓你的 Laravel 程式碼更優雅Laravel
- Go Interface 的優雅使用,讓程式碼更整潔更容易測試Go
- ASP.NET程式設計中的9條程式碼編寫規範ASP.NET程式設計
- 9個JavaScript小技巧:寫出更簡潔,高效程式碼JavaScript
- 【介面錦囊】免費好用的API介面,程式設計師必看API程式設計師
- 編寫高效且優雅的 Python 程式碼(1)Python
- uni-app(優雅的“排雷”集錦)APP