C#初学者，对于项目中，增加if else判断导致修改量太大，该使用怎么样的设计模式破解？

[hwyqy]

举个例子，比如客户，有个客户类别，一共分两类，高净值客户，其它客户，显示界面，业务逻辑等不一样，那么，最简单的方法
业务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 肯定不是种好的方法，还想请教下，这种问题，该怎么破？修改不是问题，能把代码集中在一处，只要找起来方便也行啊

[闭包客]

可能是策略模式之类的吧，其实我不太懂设计模式，我不欣赏设计模式。 我看过别人使用设计模式的代码，像在讲一个生硬的故事，而不关注解决问题本身。事实上，设计模式作为谈资的重要性，远远超过了作为实践方法的重要性。 如果你问这种情况应该使用什么设计模式，或者这种设计模式可以用在什么地方，得到的答案往往故事性要远远超过可操作性，像在谈论段子，而不是谈论工程。这些答案不会告诉你一个简单的判断标准。 其实，你问的问题很清楚，答案也是很清楚的，就是建立【条件和处理方法的映射】。然后你就可以根据条件循环查找或者哈希查找处理方法了。

[极客诗人]

业务逻辑丢委托 ui页面逻辑判断 用基类。

[xiaoxiangqing]

if太多，逻辑是会复杂一些

[千梦一生]

想到了多态？？

[千梦一生]

引用 13 楼 千梦一生 的回复:

想到了多态？？

很有点多态的神态在里面。同样的代码调用样式，不一样的调用代码

[千梦一生]

class Customer
{
virtual 业务A() = 0;
virtual 业务B() = 0;
...增加业务
}

class 客户1:Customer
{

}

class 客户2:Customer
{

}

....

[threenewbee]

用委托（将函数作为参数），要做什么，由调用者定义成函数，传进来。

[weixin_42632211]

使用数组可还行

[使我做你和平之子]

以前做过一个项目，界面上有一堆输入框，有些输入框需要强制输入，有些则不需要。是否需要强制输入是根据一些参数确定的，比如商品类型，省份等等，如果硬编码感觉很麻烦，后来设计了一个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按钮 客户类型='高净值;中净值' />
而无须修改代码。

[惊喜不断]

把具体操作都仍方法里去，，上边只是具体if else ，， 或是switch ，标注好，感觉挺清晰的，

[惊喜不断]

N多发杂逻辑，，你还想怎样。

[SMYZRJY]

个人觉得用switch比if else 看起来直观些，下次就算再加什么条件，只要再加个case就好了。 举例： switch(Customer.Type): { case"高净值1": { ... break; } case"高净值2": { ... break; } case"低净值": { ... break; } default: { break; } }

[正怒月神]

在你这个场景里，不用什么特别的设计模式。 把高净值，其他，低净值。 抽出来，作为方法。 客户A和客户B，是参数。

[正怒月神]

我觉得，初学者，没必要去搞设计模式。 也搞不好设计模式。 通常到最后，都会变成过度封装，难以拆解的紧耦合产物。 从最简单的做起。 就是先把业务逻辑抽象出来。 就像前面说的，高净值，低净值，其他。都是业务逻辑。 客户是参数。

[weixin_43178250]

觉得用xml不错的

[sdu@xy]

使用访问者模式因该可以

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{}

[以专业开发人员为伍]

所谓“多种switch类型判断”的设计，其实就是多态。可以通过提取一个统一的 interface 定义，然后让你的各种相关业务窗口或者用户控件都实现这个 interface，来规范调用。然后使用一个“工厂方法”来根据流程条件自动返回实现了这个 interface 的对象实例。

这是最基本的编程模式。

[以专业开发人员为伍]

“如无必要”，你不需要设计类型、接口之类的东西。包括使用设计模式等等概念也是这个基本原则。这里是恰好需要这个形式，因此选择直截了当的方式，不要繁琐。

[wenhuizl]

将相同的东西抽象出来，不同的参数化

[ying1234]

管你用工厂还是用设计模式，想清楚，用最合适的，千万不要为了学习或者显示自已的高明，搞的代码极复杂,如极复杂，就配上极啰嗦的注释，否则时间一长，你自已都不知道怎么改了。