行为参数化

• 行为参数化
  帮助你处理频繁变更的需求的一种开发模式

筛选苹果的例子

初试牛刀

• 选择绿色的苹果

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> 不是返回值，表示传入参数有泛型