專案中的if else太多了,該怎麼重構?

2021-10-01 14:04:06 字數 1936 閱讀 7584

策略模式還挺簡單的,就是定義乙個介面,然後有多個實現類,每種實現類封裝了一種行為。然後根據條件的不同選擇不同的實現類。

實現過程

訊息物件,當然真實的物件沒有這麼簡單,省略了很多屬性

@data

@allargsconstructor

public class messageinfo 12

3456

78910

定義乙個訊息處理介面

public inte***ce messageservice 12

34有2個訊息處理介面,分別處理不同的訊息

處理文字訊息

@service

@msgtypehandler(value = msg_type.text)

public class textmessageservice implements messageservice }12

3456

789處理訊息

@service

@msgtypehandler(value = msg_type.image)

public class imagemessageservice implements messageservice }12

3456

789文章寫到這,可能大多數人可能會想到要需要如下乙個map, map《訊息型別,訊息處理物件》,這樣直接根據訊息型別就能拿到訊息處理物件,呼叫訊息處理物件的方法即可。我們就是這樣做的,但是我們不想手動維護這個map物件,因為每次增加新的訊息處理類,map的初始化過程就得修改

定義乙個訊息型別的列舉類

public enum msg_type }12

3456

78910

1112

1314

定義乙個註解

@documented

@inherited

@target(elementtype.type)

@retention(retentionpolicy.runtime)

public @inte***ce msgtypehandler 12

3456

78不知道你注意到了沒,前面的**中,每種訊息處理類上面都有乙個@msgtypehandler註解,表明了這個處理類

處理哪種型別的訊息

@service

@msgtypehandler(value = msg_type.text)

public class textmessageservice implements messageservice }12

3456

789用乙個context物件儲存了訊息型別->訊息處理物件的對映關係

@component

public class messageservicecontext

public void putmessageservice(integer code, messageservice messageservice) }12

3456

78910

1112

1314

最精彩的部分到了

@override

beans.foreach((name, bean) -> );

}

}12

3456

78910

1112

13在spring的啟動過程中,通過解析註解,將訊息型別->訊息處理物件的對映關係儲存到messageservicecontext物件中

@autowired

messageservicecontext messageservicecontext;

@test

public void contextloads() 12

3456

78910

1112

測試類正常工作,通過策略模式避免了寫大量的if else**,也更容易維護

專案中的if else太多了,該怎麼重構?

if msgtype 文字 else if msgtype else if msgtype else 就是根據訊息的不同型別有不同的處理策略,每種訊息的處理策略 都很長,如果都放在這種if else 快中,很難維護也很醜,所以我們一開始就用了策略模式來處理這種情況。策略模式還挺簡單的,就是定義乙個介...

專案中的if else太多了,該怎麼重構?

if msgtype 文字 else if msgtype else 就是根據訊息的不同型別有不同的處理策略,每種訊息的處理策略 都很長,如果都放在這種if else 快中,很難維護也很醜,所以我們一開始就用了策略模式來處理這種情況。策略模式還挺簡單的,就是定義乙個介面,然後有多個實現類,每種實現類...

專案中的if else太多了,該怎麼重構?

if msgtype 文字 else if msgtype else就是根據訊息的不同型別有不同的處理策略,每種訊息的處理策略 都很長,如果都放在這種if else 快中,很難維護也很醜,所以我們一開始就用了策略模式來處理這種情況。策略模式還挺簡單的,就是定義乙個介面,然後有多個實現類,每種實現類封...