设计模式：干掉if else的几种方法

问题

if (variable == value1) {
	// 业务逻辑1
} else if (variable == value2) {
	// 业务逻辑2
} else {
	// 业务逻辑3
}
1
2
3
4
5
6
7

存在的问题：

1. 如果业务逻辑过多if else可能要写多达几百行，这样代码可读性很差，不利于寻找bug和理解代码
2. 如果if后面的判断逻辑过长，则代码可读性不强
3. 如果将其写在一个核心代码里面，则新增功能时需要修改核心代码，要是不小心改到其他的代码就凉凉了
4. 当业务逻辑1、业务逻辑2、业务逻辑3存在通用逻辑时，则无法很好的复用代码
5. 总的来说就是代码可扩展性差、可读性差、可复用性差。可扩展性差，说明修改时需要修改以前的代码，增加了风险。可读性差，说明代码一大段一大段的，想要修改一个东西得到处找，而且逻辑复杂难以读懂。可复用性差，不止写的时候累，改的时候也累，因为虽然是同样的逻辑，但是你写在了10个地方，你就需要改10次。

初级：switch

switch (variable) {
       case value1:
           commonDoSomething();
           doSomething1();
           break;
       case value2:
       	   commonDoSomething();
           doSomething2();
           break;
       default:
           commonDoSomething();
           doSomething3();
           break;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

改进：

1. 使用switch增加了可读性，但是在一些复杂判断逻辑时，明显不如if else 方便
2. 将业务逻辑抽象成函数，将公有逻辑全部抽出来，增加了代码的可读性、可复用性

存在的问题：

1. 和if else一样，如果条件分支过多switch可能要写多达几百行，这样代码可读性很差，不利于寻找bug和理解代码
2. 和if else一样，如果将其写在一个核心代码里面，则新增功能时需要修改核心代码，要是不小心改到其他的代码就凉凉了

中级：多态

   public interface Animal {
       void makeSound();
   }
   public class Dog implements Animal {
       public void makeSound() {
           System.out.println("业务逻辑1");
       }
   }

   public class Cat implements Animal {
       public void makeSound() {
           System.out.println("业务逻辑2");
       }
   }
    public class Main {
      public static void main(String[] args) {
         Animal animalDog = new Dog();
   		 animalDog.makeSound();
   		 Animal animalCat = new Cat();
   		 animalCat.makeSound();
     }
   }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

改进：

1. 使用多态将业务逻辑拆分到各个类中，极大的降低了同一个模块中的代码了，使得可读性提高了很多
2. 可以使用继承抽象类方式的多态，这样还可以共用逻辑复用代码，提高了代码的可复用性

存在的问题：

1. 新增业务逻辑时仍然需要修改核心代码

高级：策略模式+Map

 public interface Strategy {
       void doSomething();
   }

   public class StrategyA implements Strategy {
       public void doSomething() {
           //业务逻辑1
       }
   }

   public class StrategyB implements Strategy {
       public void doSomething() {
            //业务逻辑2
       }
   }

  public class Main {
      public static void main(String[] args) {
         Strategy strategy = getStrategy();
   		 strategy.doSomething();
     }
  }
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

改进：
使用策略模式，可以发现策略模式和多态其实也没有多大的区别，但关键就在于getStrategy()方法，它的实现的多变，可以大大提高代码的可扩展性，无需修改了核心代码

Map的实现

public GetStrategy {
	private static final Map<String, Strategy> map = new HashMap(){{
		put("StrategyA", new StrategyA());
		put("StrategyB", new StrategyB());
	}};//双花括号表示一个类继承HashMap类并重写其构造方法
	public Strategy getStrategy(String strategyName) {
		return map.get(strategyName);
	};
}
1
2
3
4
5
6
7
8
9

实现：
1.将所有的策略中存储在一个Map中，这样当我们需要增加逻辑时只需要增加一个put即可，代码可扩展性很强，而且getStrategy()里面的代码和使用getStrategy()方法的核心逻辑都无需修改。
2.策略名可以在最开始的配置代码中传入，如配置类中就传入
存在的问题
如果是复杂的逻辑来决定需要选取的策略，而不是通过策略名来选取的话，就无法实现，如果要实现的话需要增加一个策略匹配器，如下：

public interface Matcher {
	public String match() {
		//判断逻辑，返回策略名
	}
}

//使用
public class Main {
      public static void main(String[] args) {
         Strategy strategy = getStrategy(new MatcherImpl().match());
   		 strategy.doSomething();
     }
  }
1
2
3
4
5
6
7
8
9
10
11
12
13

优缺点：

1. 使用策略匹配器的优点就是，方便自己传入不同的策略匹配器的实现，来进行不同的规则匹配，这样可以扩展。
2. 但是其缺点就是，如果一个匹配器中逻辑过于复杂，则又会陷入if else的困境
   解决方案：

class MatcherChain {
	private List<Matcher> matcherList = new ArrayList(){{
	add(new MatcherA());
	add(new MatcherB());
}};
	
	public String match() {
		for (Matcher matcher : matcherList) {
			String strategyName = matcher.match()
			if (strategyName != null) {
  				return strategyName;
  			}
		}
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

1. 将每个if都拆分为一个Matcher，使用List线性表数据结构将其存储起来，表明其的先后顺序关系，就类似不同的if直接的先后顺序关系。
2. 然后循环调用Matcher匹配器的match方法，如果判断逻辑匹配上，则改Matcher返回对应的策略名。
3. 扩展也很方便，只需新建一个Matcher将其加入matcherList即可，但要注意添加进列表的顺序，如果条件逻辑之间有重合