- 行为参数化
帮助你处理频繁变更的需求的一种开发模式
筛选苹果的例子
初试牛刀
- 选择绿色的苹果
private List<Apple> inventory;
@Before
public void init() {
inventory = asList(new Apple("red", 5), new Apple("green", 5), new Apple("red", 7));
}
/**
* 过滤出青苹果
*/
@Test
public void filterApple() {
selectApple();
}
private void selectApple() {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if (apple.getColor().equals("green")) {
result.add(apple);
}
}
}
如果说有一天需求改变了，需要选择出红苹果怎么办呢？
你可能认为：把if改一下，copy一份不就好了嘛！这个确实能够解决当前问题，但是，第一：这个方案不优雅，如果客户要求选择重量咋办，或者后面用户还会提各种需要怎么办？这个程序的扩展性太差了。
第二：存在很多冗余的代码，不易阅读。
再展身手
- 选择青苹果或者红苹果
/**
* 根据颜色过滤苹果
*/
@Test
public void selectApple(String color) {
selectWithColor(color);
}
private void selectWithColor(String color) {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if (apple.getColor().equals(color)) {
result.add(apple);
}
}
}
主要就完美了吗？如果需要变成根据重量过滤怎么办呢？难道你还打算写一个根据重量过滤的？那要是即根据颜色又根据重量过滤怎么办呢？你难道还有根据两个参数去判断，那代码也太混乱了，一个方法不是去做一件事，阅读起来也晦涩难懂。
那应该怎么做呢？请看参数行为化。
小小突破
- 对行为进行抽象
public interface ApplePredicate {
/**
* 选择苹果
*
* @param apple
* @return
*/
boolean test(Apple apple);
}
抽象行为，本例是测试苹果，具体怎么测试无需关心。有不同的子类去实现。
- 对抽象行为的不同实现
public class ColorApplePredicate implements ApplePredicate {
/**
* 根据颜色过滤苹果
*
* @param apple
* @return
*/
@Override
public boolean test(Apple apple) {
return apple.getColor().equals("green");
}
}
public class WeightApplePredicate implements ApplePredicate {
/**
* 根据重量过滤苹果
*
* @param apple
* @return
*/
@Override
public boolean test(Apple apple) {
return apple.getWeight() > 44;
}
}
这些其实就是设计模式里面的策略模式。所谓的策略模式也就是：定义一簇算法，把它们封装起来（称为策略），然后在运行时选择一个算法运行。
- 选择苹果
public class StrategyApple {
public static void main(String[] args) {
List<Apple> inventory = asList(new Apple("red", 5), new Apple("green", 5), new Apple("red", 7));
//根据颜色选择苹果
List<Apple> apples = selectStrategyApple(inventory, new ColorApplePredicate());
//根据重量选择苹果
List<Apple> appleList = selectStrategyApple(inventory, new WeightApplePredicate());
}
/**
* @param inventory 苹果集合
* @param predicate 操作的策略 或者是谓词
* @return
*/
public static List<Apple> selectStrategyApple(List<Apple> inventory, ApplePredicate predicate) {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if (predicate.test(apple)) {
result.add(apple);
}
}
return result;
}
}
试想一下，如果用户又加了需求，需要选择颜色加重量或者其他的等等，我们只需要添加一种策略就可以轻松搞定，不需要没用的copy,也不需要改动代码的主体。
这真的就是最完美的了吗？还有优化的空间吗？
在上面这段代码里我们可以看到，真正重要的是test这段代码，但令人遗憾的是它必须通过ApplePredicate来传递这种行为，也就是这种行为包裹在了ApplePredicate对象里面，而不是真正的传递行为。我们想一下lambda是实现的。
//lambda
List<Apple> lambdas = selectStrategyApple(inventory, apple -> apple.getColor().equals("green"));
List<Apple> lambdastwo = selectStrategyApple(inventory, apple -> apple.getWeight() > 4);
List<Apple> lambdasthree = selectStrategyApple(inventory,
apple -> apple.getWeight() > 4 || apple.getColor().equals("green"));
从上面这段代码我们可以看出，我们是真的把一段代码，一种行为，作为参数传递过去了。代码清新，易于阅读，同时还少了很多没必要的中间变量。
最后一次优化
从目前的代码来看还是只能使用苹果，要是换成梨子怎么办呢？不要告诉我copy一份，那要是再换成其他的呢？这也说明我们还有抽象的空间。
/**
* 抽象处理
*
* @param inventory
* @param predicate 操作的策略 或者是谓词
* @return
*/
public static <T> List<T> selectStrategyT(List<T> inventory, Predicate<T> predicate) {
List<T> result = new ArrayList<>();
for (T t : inventory) {
if (predicate.test(t)) {
result.add(t);
}
}
return result;
}
说明一下 static <T> 不是返回值，表示传入参数有泛型
