Pre

在软件工程中，不管你做什么，用户的需求肯定会变的，如何应对这样不断变化的需求？理想的状态下，应该把你的工作量降到最少。此外，类似的新功能实现起来还应该很简单，而且易于长期维护。

行为参数化就是可以帮助我们处理频繁变更的需求的一种软件开发模式。

简言之，它意味着拿出一个代码块，把它准备好却不去执行它。这个代码块以后可以被我的程序的其他部分调用，这意味着我可以推迟这块代码的执行。例如，我可以将代码块作为参数传递给另一个方法，稍后再去执行它。这样，这个方法的行为就基于那块代码被参数化了。

为啥需要lambda

举个例子哈：有个项目，老板说需要组建一个研发团队，巴拉巴拉~

老板说来俩Java程序猿


public class EnginnerTest {

    public List getJavaEngineers(List<Enginner> enginnerList){
        List javaEnginnerList = new ArrayList();
        for (Enginner enginner: enginnerList) {
            if ("Java".equals(enginner.getJob())){
                javaEnginnerList.add(enginner);
            }
        }
        return javaEnginnerList;
    }

    public static void main(String[] args) {
        List<Enginner> enginnerList = Arrays.asList(new Enginner("Java", 18), new Enginner("GO", 20), new Enginner("Python", 15), new Enginner("DBA", 15),new Enginner("Java", 25));
        EnginnerTest enginnerTest= new EnginnerTest();
        List javaEngineers = enginnerTest.getJavaEngineers(enginnerList);
        System.out.println(javaEngineers);
    }
}

来看下重点 "Java".equals(enginner.getJob())

隔天，老板说，再来个GO的…

我在弄个 getGoEngineers方法？那要是老板在要个Python的， C++的，那我这里岂不是满屏的Ctrl +C ,Ctrl +V ?

一个良好的原则是在编写类似的代码之后，尝试将其抽象化。

一种做法是给方法加一个参数，把Job变成参数，这样就能灵活地适应变化了


    public List getEngineersByJob(List<Enginner> enginnerList , String job){
        List targetEngineerList = new ArrayList();
        for (Enginner enginner: enginnerList) {
            if (job.equals(enginner.getJob())){
                targetEngineerList.add(enginner);
            }
        }
        return targetEngineerList;
    }

结果，老板又说了，我要几个有开发经验的工程师，这。。。。

那我写这么一个方法，你看可好？

    public List getEngineersByJobAndAge(List<Enginner> enginnerList , String job,int age){
        List targetEngineerList = new ArrayList();
        for (Enginner enginner: enginnerList) {
            if (job.equals(enginner.getJob()) && enginner.getAge() > age){
                targetEngineerList.add(enginner);
            }
        }
        return targetEngineerList;
    }

我只是Ctrl+C了大部分的代码稍微修改下，实现了这个需求。但却不是一个好的办法，因为它打破了DRY（Don’t Repeat Yourself，不要重复自己）的软件工程原则。如果你想要改变筛选遍历方式来提升性能呢？那就得修改所有方法的实现，而不是只改一个。从工程工作量的角度来看，这代价太大了。

那改怎么办比较理想呢？

策略设计模式了解下

选择Enginner的不同策略

你需要一种比添加很多参数更好的方法来应对变化的需求。让我们后退一步来看看更高层次的抽象。

一种可能的解决方案是对你的选择标准建模：你考虑是 Enginner，需要根据 Enginner的某些属性（比如它是Java的吗? 年龄超过30吗？）来返回一个
boolean 值。

我们把它称为谓词（即一个返回 boolean 值的函数）。让我们定义一个接口来对选择标准建模：


public interface EnginnerFilter {
    boolean getMatchedEnginner(Enginner enginner);
}

现在你就可以用 EnginnerFilter 的多个实现代表不同的选择标准了，比如

public class JavaEnginnerFilter implements EnginnerFilter {
    @Override
    public boolean getMatchedEnginner(Enginner enginner) {
        return "Java".equals(enginner.getJob());  // 仅筛选Java的
    }
}

public class AgeGte30JavaEnginnerFilter implements EnginnerFilter {
    @Override
    public boolean getMatchedEnginner(Enginner enginner) {
        return "Java".equals(enginner.getJob()) && enginner.getAge() >= 30;  // 筛选Java 并且年龄>=30的 
    }
}

你可以把这些标准看作 filter 方法的不同行为 , 它让你定义一族算法，把它们封装起来（称为“策略”），然后在运行时选择一个算法 . 在这里,算法族就是 EnginnerFilter ，不同的策略就是 AgeGte30JavaEnginnerFilter和 JavaEnginnerFilter 。

但是，该怎么利用 EnginnerFilter 的不同实现呢？你需要 getMatchedEnginner 方法接受 Enginner对象，对 Enginner做条件测试。这就是行为参数化：让方法接受多种行为作为参数，并在内部使用，来完成不同的行为。

要在我们的例子中实现这一点，你要给 getMatchedEnginner 方法添加一个参数，让它接受Enginner对象。

这在软件工程上有很大好处：现在你把 getMatchedEnginner方法迭代集合的逻辑与你要应用到集合中每个元素的行为（这里是一个谓词）区分开了。

利用 EnginnerFilter 改过之后，方法如下

   public List findEnginner(List<Enginner> enginnerList, EnginnerFilter filter){
        List targetEngineerList = new ArrayList();
        for (Enginner enginner: enginnerList) {
            if (filter.getMatchedEnginner(enginner)){ // 谓词对象封装了测试Enginner 的条件
                targetEngineerList.add(enginner);
            }
        }
        return targetEngineerList;
    }

测试下

List targetEngineerList4 = enginnerTest.findEnginner(enginnerList,new AgeGte30JavaEnginnerFilter());
 System.out.println(targetEngineerList4);
        
List targetEngineerList5 = enginnerTest.findEnginner(enginnerList,new JavaEnginnerFilter());
 System.out.println(targetEngineerList5);

这段代码比我们第一次尝试的时候灵活多了，读起来、用起来也更容易！现在你可以创建不同的 EnginnerFilter对象，并将它们传递给 getMatchedEnginner方法。

当然了，也可以用匿名内部类

  List targetEngineerList6 = enginnerTest.findEnginner(enginnerList, new EnginnerFilter() {
            @Override
            public boolean getMatchedEnginner(Enginner enginner) {
                return "Python".equals(enginner.getJob());
            }
        });

在通往抽象的路上，我们还可以更进一步。目前， getMatchedEnginner方法还只适用于 Enginner 。你还可以将 List 类型抽象化，从而兼容更多类型

public interface  Filter<T> {
    boolean filter(T  t);
}

 public static <T> List filter(List<T> list, Filter<T> p) {
      List<T> targetList = new ArrayList();
      for (T t : list) {
          if (p.filter(t)) 
              targetList.add(t);
      }
      return targetList;
  }

lambda的妙用

上面的代码是不是很长？

让我们在接口上增加一个注解 @FunctionalInterface (标注这个接口是一个function的接口) 【可选操作】

@FunctionalInterface
public interface EnginnerFilter {
    boolean getMatchedEnginner(Enginner enginner);
}

使用lambda ，

 List targetEngineerList7 = enginnerTest.findEnginner(enginnerList,(Enginner enginer) -> {
            return "Java".equals(enginer.getJob());
        });
        System.out.println(targetEngineerList7);

(Enginner enginer) -> 这个地方还可以简写，因为你的EnginnerFilter 这个接口的入参就是Enginner 类型的，lambda自己可以反推到是这个类型，可以简写为 (enginer) -> ，就1个参数，也就没有用括号的必要了，最后就成了这样子


enginnerTest.findEnginner(enginnerList,engineer -> {
            return "Java".equals(engineer.getJob());
        });

@FunctionalInterface

Java 8为函数式接口引入了一个新注解@FunctionalInterface，主要用于编译级错误检查，加上该注解，当你写的接口不符合函数式接口定义的时候，编译器会报错。

加不加@FunctionalInterface对于接口是不是函数式接口没有影响，该注解知识提醒编译器去检查该接口是否仅包含一个抽象方法。
标注了@FunctionalInterface ， 抽象方法只能包含一个 , default 方法和 static的方法除外，看下面 @FunctionalInterface 并没有报错（可以看看Comparator接口的定义）