策略型業務邏輯處理選擇

目前常見的分層結構是包括展現層、業務邏輯層、持久層的。

那麼在業務邏輯層中，是會有非常多的複雜的業務邏輯判斷的，例如：

if (a.geta() == type.a)  else if (a.geta() ==type.higher)  else 
} }}

這些if-else判斷是有非常多的弊端的

對於新的需求，**很難做出變更

隨著更多條件的加入，**效能顯著下降

如果要改變應用的行為，還需要重新編譯和重新發布應用程式

對於開發人員，難以修改**；對於領域專家，很難驗證業務邏輯，更別說修改業務邏輯

遇到這種情況來說，一種選擇是用一些設計模式去處理，最常見的就是策略模式，這種設計模式主要的核心就是將策略封裝成為類，並依賴於主題上下文中，，下面是策略模式例項的uml

圖：

這個模式在一定程度上是可以解除if

和else

帶來的判斷策略複雜性問題，而且能夠做到開閉原則，但是依舊沒有完全解決上面的那些弊端。並且這種設計模式還帶來了一些缺點，例如策略類的增加等。

其實還有一種選擇就是找乙個規則引擎工具，例如開源的drools

和商業的

ilog

等。規則引擎是一種巢狀在應用程式中的元件，實現了將業務規則從應用程式**中分離出來。規則引擎使用特定的語法編寫業務規則，規則引擎可以接受資料輸入、解釋業務規則、並根據業務規則做出相應的決策。下面是加入規則引擎和沒有加入規則引擎的對比圖：

利用規則引擎可以解決很多if-else帶來的弊端，這裡包括：易於理解；提高了可維護性；可處理更複雜的業務邏輯；靈活；合理的效能；；可重用等。

但是這種工具也是會有一定的侷限性和缺點，例如：規則引擎只是將事情變得簡單些，它不是****；開發人員需要站在業務人員角度制定規則；如果不懂得規則引擎的執行模式，除錯規則會有些困難；規則引擎消耗記憶體等。

在遇到業務邏輯層負責策略的時候，需要根據不同的情況來進行選擇，其實目的都是一致的，就是物件導向的好處--

易維護、易擴充套件、高質量等。