- Published on
Java8之函数接口
- Authors
- Name
- Pursue
以方法作为参数传递时,Ruby 有 proc,C#有 Delegate,而 JavaScript 则更不用说,唯独 Java 在这方面很尴尬。但 Java8 提供了 Lambda 表达式和函数接口,这无疑是 Javer 的福音,也使得 Java 这门语言更佳的优秀和易用。
需求
C 团队是一个敏捷开发团队,它们的产品每天都会进行几十次的小版本发布,如此频繁的持续集成必须有良好的代码作为保证。为此,PM 在 CI 中的构建任务中设定了“门槛”,所有部署必须进行 Sonar 代码扫描,满足一定的阀值才可以进行正常发布,以此保证产品质量。具体指标如下:
- 1.工程的测试覆盖率必须大于 90%
分析
获取所有工程,筛选出测试覆盖率大于 90%的工程,进行发布,so easy~
实现
private static List<Project> getValidProjects(List<Project> projectList) {
List<Project> validProjects = new ArrayList<>();
for(Project project : projectList) {
if(project.getTestCoverage() > 0.9) {
validProjects.add(project);
}
}
return validProjects;
}
代码很简单,这是 java8 之前的实现。当然了,我们很还可以将project.getTestCoverage() > 0.9
抽象成project.isValid()
,这下看起来似乎没太大问题了。
需求 2 来了,PM 的规定的新指标如下:
- 1.工程的测试覆盖率必须大于 90%
- 2.code smell 数不能超过 3 个
同样很 easy,你很快速的在Project.java
里抽象出了:
public boolean isValid() {
return this.getTestCoverage() > 0.9 && this.getCodeSmellNum() < 3;
}
可部署时还时老出现问题,PM 再次提高质量门槛,指标如下:
- 1.工程的测试覆盖率必须大于 90%
- 2.code smell 数不能超过 3 个
- 3.扫描问题数不超过 3 个
- 4.API 测试用例数大于 10
- 5.UI 测试用例数大于 10
- ...
- ...
- ...
此时你的是不想把 PM 弄死,可你别无选择,还是得在此基础上添加了 N 多判断。
Java8 来啦。。。。
Predicate
仔细分析现在的需求,其实想要实现的方法是“某种行为”的结果来导向校验的集合,也就说上面的方法参数应该类似:
private static List<Project> getValidProjects(List<Project> projectList, Validation validation) {
List<Project> validProjects = new ArrayList<>();
for(Project project : projectList) {
if(validation.test()) {
validProjects.add(project);
}
}
return validProjects;
}
将所有的情况都统一抽象成 Validation 接口,接口中的test
方法表示校验结果。如果这样做,就变成了多态,当然可以实现,不过就得设计的比较复杂:好好的一个筛选,硬要写个接口而后再写 N 多类去实现,岂不是很槽糕。Java8 在此基础上帮我们实现了函数接口,可以将validation
看作是一个还未被执行的方法,对应的,我们可以这么写:
private static List<Project> getValidProjects(List<Project> projectList, Predicate<Project> p) {
List<Project> validProjects = new ArrayList<>();
for(Project project : projectList) {
if(p.test(project)) {
validProjects.add(project);
}
}
return validProjects;
}
List<Project> validProjects = getValidProjects(projectList, project-> project.getTestCoverage() > 0.9);
将project-> project.getTestCoverage() > 0.9
作为方法参数传递看起来很酷吧,对应的,我们可以聚合上面的多种predicate
:
Predicate<Project> testCoveragePredicate = project-> project.getTestCoverage() > 0.9;
Predicate<Project> codeSmellPredicate = project-> project.getCodeSmellNum() < 3;
Predicate<Project> issuePredicate = project-> project.getIssueCount() < 3;
Predicate<Project> apiPredicate = project-> project.getApiCount() > 10;
Predicate<Project> uiPredicate = project-> project.getApiCount() > 10;
Predicate<Project> projectPredicate = testCoveragePredicate
.and(codeSmellPredicate)
.and(codeSmellPredicate)
.and(issuePredicate)
.and(apiPredicate)
.and(uiPredicate);
List<Project> validProjects = getValidProjects(projectList, projectPredicate);
这样的代码,既然漂亮,又表意,而且可维护性还更高,很酷吧。不过不难看出,Predicate
是T->boolean
的形式,如果需要其他类型怎么办呢?这里简单介绍其他两个函数接口
Consumer and Function
Consumer
, Function
与Predicate
类似只不过前者是T->void
的形式,而后者是T->R
的形式,并且实现的方法略有不同。
Demo for Consumer:
private static void displyAllCodeSmell(List<Project> projectList, Consumer<Project> c) {
for(Project project : projectList) {
c.accept(project);
}
}
displyAllCodeSmell(projectList, project -> System.out.println(project.getCodeSmellNum()));
Demo for Function:
private static int calcAllIssueCount(List<Project> projectList, Function<Project, Integer> f) {
int sum = 0;
for(Project project : projectList) {
sum += f.apply(project);
}
return sum;
}
calcAllIssueCount(projectList, project -> project.getIssueCount());
其他函数接口
| Interface | | | | | Description |
| ----------------- | --- | --- | --- | --- | -------------- |
| Predicate<T> | | | | | T->boolean |
| Consumer<T> | | | | | T->void |
| Function<T> | | | | | T->R |
| Supplier<T> | | | | | ()->T |
| UnaryOperator<T> | | | | | T->T |
| BinaryOperator<T> | | | | | (T,T)->T |
| BiPredicate<L,R> | | | | | (L,R)->boolean |
| BiConsumer<T,U> | | | | | (T,U)->void |
| BiFunction(T,U,R) | | | | | (T,U)->R |