舉個例子，比如客戶，有個客戶類別，一共分兩類，高凈值客戶，其它客戶，顯示界面，業務邏輯等不一樣，那么，最簡單的方法
業務A中：
if (Customer.Type=="高凈值")
{
....業務A高凈值
}
else
{
...業務A其它
}
業務B中
if (Customer.Type=="高凈值")
{
....業務B--高凈值
}
else
{
...業務B--其它
}
顯示界面A中：
if (Customer.Type=="高凈值")
{
....裝載A串列，禁用A按鈕等
}
else
{
...
}
還有業務C，業務D，界面B，界面C等
結果，某天，突然說，還要弄個低凈值，那么上面的if else 不行了
if (Customer.Type=="高凈值")
{
....
}
else if (Customer.Type=="低凈值")
{
...
}
else
{
...
}
當然，例子中簡化了，實際應用肯定復雜。其實本身修改很簡單，問題是
1、專案中寫了if else 的地方，比較多，時間一長，肯定不記得哪些地方要改，會漏了。專案比較龐大，要都找出來不容易
2、每個業務中的if else處理也不一樣，想集中也沒什么頭緒
3、業務方面的代碼，也能想辦法集中，但是涉及到界面方面的，asp.net中，涉及到很多頁面，想不到集中的辦法
4、如果下次再增加個“中凈值"，那又得重來一次，就想使得再來一次的作業量降到最低，
用if else 肯定不是種好的方法，還想請教下，這種問題，該怎么破？修改不是問題，能把代碼集中在一處，只要找起來方便也行啊
uj5u.com熱心網友回復：
想起了蛋騙雞中按鍵對應與值的代碼寫法改進，原來使用switch要寫16行代碼，最后修改為陣列，代碼大為縮小，例子可參。uj5u.com熱心網友回復：
如果業務簡單，不同業務只是換個值，那陣列就夠了。如果業務復雜，不同業務差別太大，那光從代碼上也簡化不了什么，
其實你這個主要是顯示什么，禁用什么對不對？
那就類似按用戶角色權限去設計，設計好了，有什么權限就顯示什么內容就得了，不糾結原本的業務。
做好了，你唯一要做就是配置每個型別的權限。
uj5u.com熱心網友回復：
感覺用策略模式就可以了定義統一介面
不同的物件進行不同的代碼實作
uj5u.com熱心網友回復：
可能是策略模式之類的吧，其實我不太懂設計模式，我不欣賞設計模式。我看過別人使用設計模式的代碼，像在講一個生硬的故事，而不關注解決問題本身。事實上，設計模式作為談資的重要性，遠遠超過了作為實踐方法的重要性。
如果你問這種情況應該使用什么設計模式，或者這種設計模式可以用在什么地方，得到的答案往往故事性要遠遠超過可操作性，像在談論段子，而不是談論工程。這些答案不會告訴你一個簡單的判斷標準。
其實，你問的問題很清楚，答案也是很清楚的，就是建立【條件和處理方法的映射】。然后你就可以根據條件回圈查找或者哈希查找處理方法了。
uj5u.com熱心網友回復：
不用特別的設計模式，設計模式都是為了服務那七個設計原則的，核心是設計原則。
1.
你這個業務可以先抽象出一個客戶物件作為基類，里面寫一些客戶的一些屬性、方法等等
然后每有一個比如高凈值客戶就新建一個高凈值客戶類繼承這個客戶物件。
2.
關于節省if else判斷：建一個類似工廠一樣的類，讓他幫你創建物件，傳進去一個字串名稱幫你新建一個對應的類（可以用C#的反射實作）。然后比如他們都具有你的業務統一交叫run（）方法，他們的區別只是這個run里不一樣，那就在工廠創建出的客戶物件.Run（）即可。
接著你仔細看那七個設計原則，可能就會發現這個設計好的地方了
uj5u.com熱心網友回復：
1.看條件復雜程度，就像上面說的條件簡單用簡單方式就可以，比如工廠，比如hashmap2.如果條件復雜，手段一般有兩類
a.集中控制，比如規則引擎，petri網（前2天還有問petri網的，不知何故不受待見被刪了）
b.分散控制：比如spark，storm，flink這類，基于狀態機，狀態訊息等東西拆成原子態的狀態，分散判定。然后各狀態原子自己根據決策表，決策書，拓撲圖進行自我回應。這類東西還可以是神經網路，說神經網路有些夸大，但是簡單有向圖還是可以的，所以neo4j也行
終歸來說如果條件復雜，統一叫做CEP復雜事務處理，現在基本傾向分散控制，因為規則復雜的化屬于離散系統，而且俺們是人不是神仙，所以要后期能擴，能改，能維護。
uj5u.com熱心網友回復：
找了一個esper的圖看看，你會發現我上面的描述，其實就是esper的核心架構方式
uj5u.com熱心網友回復：
用委托（將函式作為引數），要做什么，由呼叫者定義成函式，傳進來。uj5u.com熱心網友回復：
業務邏輯丟委托 ui頁面邏輯判斷 用基類。uj5u.com熱心網友回復：
if太多，邏輯是會復雜一些uj5u.com熱心網友回復：
想到了多型？？uj5u.com熱心網友回復：
很有點多型的神態在里面。同樣的代碼呼叫樣式，不一樣的呼叫代碼
uj5u.com熱心網友回復：
class Customer{
virtual 業務A() = 0;
virtual 業務B() = 0;
...增加業務
}
class 客戶1:Customer
{
}
class 客戶2:Customer
{
}
....
uj5u.com熱心網友回復：
使用陣列可還行uj5u.com熱心網友回復：
以前做過一個專案，界面上有一堆輸入框，有些輸入框需要強制輸入，有些則不需要。是否需要強制輸入是根據一些引數確定的，比如商品型別，省份等等，如果硬編碼感覺很麻煩，后來設計了一個xml，大致如下：<輸入框1 商品型別='a' />
<輸入框2 商品型別='a;b;' />
也就是把if else的判斷條件全部用xml來配置，然后只需撰寫決議處理xml的代碼，輸入引數比如說是輸入框id和商品型別， 大致邏輯是，先根據輸入框id 去找xml里有沒有，如果有，再找它的屬性“商品型別”，如果值和輸入引數相同，則說明需要強制輸入，否則說明不需要強制輸入。這里定義一種簡單的domain specific language，即a;b;表示a或者b, !a表示非a, 等等，以方便處理稍復雜的情形。
好處是判斷條件改變時，只需修改xml，而不必動代碼。
回到樓主的例子，是否可以考慮設計這樣的xml:
<A按鈕 客戶型別='高凈值' />
用它表示“如果客戶型別='高凈值'，則禁用A按鈕”，其余類推。這樣，以后如果增加了條件：如果客戶型別='中凈值'，則禁用A按鈕
只需修改xml為
<A按鈕 客戶型別='高凈值;中凈值' />
而無須修改代碼。
uj5u.com熱心網友回復：
把具體操作都仍方法里去，，上邊只是具體if else ，， 或是switch ，標注好，感覺挺清晰的，
uj5u.com熱心網友回復：
N多發雜邏輯，，你還想怎樣。uj5u.com熱心網友回復：
個人覺得用switch比if else 看起來直觀些，下次就算再加什么條件，只要再加個case就好了。舉例：
switch(Customer.Type):
{
case"高凈值1":
{
...
break;
}
case"高凈值2":
{
...
break;
}
case"低凈值":
{
...
break;
}
default:
{
break;
}
}
uj5u.com熱心網友回復：
在你這個場景里，不用什么特別的設計模式。把高凈值，其他，低凈值。
抽出來，作為方法。
客戶A和客戶B，是引數。
uj5u.com熱心網友回復：
我覺得，初學者，沒必要去搞設計模式。也搞不好設計模式。
通常到最后，都會變成過度封裝，難以拆解的緊耦合產物。
從最簡單的做起。
就是先把業務邏輯抽象出來。
就像前面說的，高凈值，低凈值，其他。都是業務邏輯。
客戶是引數。
uj5u.com熱心網友回復：
覺得用xml不錯的uj5u.com熱心網友回復：
使用訪問者模式因該可以abstract class Customer{
abstract void deal(Act act);
}
class highValCustomer extends Customer{
@Override
void deal(Act act) {
act.getHighValAction();
}
}
class elseValCustomer extends Customer{
@Override
void deal(Act act) {
act.getElseValAction();
}
}
class lowValCustomer extends Customer{
@Override
void deal(Act act) {
act.getLowValAction();
}
}
interface Act{
void getLowValAction();
void getHighValAction();
void getElseValAction();
}
class taskA implements Act{
@Override
public void getLowValAction() {
System.out.println("業務A低凈值客戶處理");
}
@Override
public void getHighValAction() {
System.out.println("業務A高凈值客戶處理");
}
@Override
public void getElseValAction() {
System.out.println("業務A其他型別客戶處理");
}
}
class taskB implements Act{
@Override
public void getLowValAction() {
System.out.println("業務B低凈值客戶處理");
}
@Override
public void getHighValAction() {
}
@Override
public void getElseValAction() {
}
}
//class tackC implements Act{}
//class taskD implements Act{}
uj5u.com熱心網友回復：
所謂“多種switch型別判斷”的設計，其實就是多型。可以通過提取一個統一的 interface 定義，然后讓你的各種相關業務視窗或者用戶控制元件都實作這個 interface，來規范呼叫。然后使用一個“工廠方法”來根據流程條件自動回傳實作了這個 interface 的物件實體。這是最基本的編程模式。
uj5u.com熱心網友回復：
“如無必要”，你不需要設計型別、介面之類的東西。包括使用設計模式等等概念也是這個基本原則。這里是恰好需要這個形式，因此選擇直截了當的方式，不要繁瑣。uj5u.com熱心網友回復：
將相同的東西抽象出來，不同的引數化uj5u.com熱心網友回復：
管你用工廠還是用設計模式，想清楚，用最合適的，千萬不要為了學習或者顯示自已的高明，搞的代碼極復雜,如極復雜，就配上極啰嗦的注釋，否則時間一長，你自已都不知道怎么改了。轉載請註明出處，本文鏈接：https://www.uj5u.com/net/38098.html
標籤：C#