开始
编码多年,总有一些最佳实践,Java也是,比如设计模式,比如Effective Java 3 (ej3) 。 设计模式先后看过《大话设计模式》,《HeadFirst 设计模式》。而EffectiveJava3我打算阅读英语原版的,翻译过来,提高一下自己的英文阅读能力,同时也思考一下大师总结的编程最佳实践,应用到日常编码工作中。
开端从ef3作者的[宣讲PPT](https://www.yuque.com/office/yuque/0/2019/pptx/186661/1574762227798-103405a7-8cec-4953-b03c-26e8eff4150c.pptx)开始。
建议先快速看一遍ppt,不过全部是英文的,我把它翻译过来,作为我开始ej3的开始。
版本变化
变化 | ej3 | ej2 |
---|---|---|
新增章节 | 一个新章节 | |
新增规则 | 14条新规则 | |
重写规则 | 2个重写规则 | |
修改规则 | 所有规则条目彻底修改 | |
发布日期 | 2017 | 2008 |
jdk版本 | java9 | java6 |
页数 | 366 | 315 |
使用 lambdas优先匿名类
使用匿名内部类的代码可读性和简洁性不断提高;
file
类型推断:
Collections.sort(stringList,(s1,s2)->Integer.compare(s1.length(),s2.length()));
等价于:
Collections.sort(stringList,(Comparator<String>)(String s1,String s2)->Integer.compare(s1.length(),s2.length()));
类型推断很魔幻:
- 没有人知道规则,但是它是对的;
- 忽略类型除非它可以让程序更清晰;
- 编译器如果需要帮助它会告诉你;
类型推断的警告:
- 推断依赖于泛型信息; 比如 words被声明为List<String>,代码无法编译,如果words是一个原生的List;
- 第二版说不要使用原生类型:惩罚是不必要的运行期bug和令人讨厌的代码;
- 第三版本说的更严重:惩罚包括无法合适的使用lambdas;
- 你必须理解泛型之后才能使用lambdas;
使用labmbdas的警告:
- 它缺少名字和文档:它应该是自解释的,它应该不超过一定行数,最好是一行;
- 如果它必须很长或者复杂:抽取到方法中然后使用方法引用,枚举则或者使用指定实例的类体;
- 匿名类任然有使用场景:lambdas需要函数式接口,并且无法访问自己,在lambdas中this指向了一个封闭的实例;
把一个抽象方法的实现替换成了一个函数式接口;
方法引用优先lambdas
file说明:
- 参数越多,代码块约长;但是参数可以提供文档信息;
- 如果使用lambdas,需要小心的选择参数名字;
public class ExeTest {
public static void main(String[] args) {
new Thread(()->action()).start();
System.out.println("====");
new Thread(ExeTest::action).start();
Arrays.asList("aaa","bbb","CCC").stream().map(x->x).collect(Collectors.toList());
Arrays.asList("aaa","bbb","CCC").stream().map(Function.identity()).collect(Collectors.toList());
}
private static void action() {
System.out.println("do action ");
}
}
file
写在最后:
- 所有可以使用方法引用的地方,你都可以使用lambda替换;
- 方法引用通常更简洁;
- 有的时候,lambda更清晰
- 基于你自己的判断力,你总是可以改变主意;
优先使用标准函数式接口
jdk9中一共43个标准的函数式接口;
file
使用标准的函数式接口的好处:
-
api更好学习降低了概念领域的学习;
-
提供了互操作性便利:很多的标准函数式接口提供了有用的默认方法,比如Predicate提供了combine和negate;
-
例子中方法可以使用BiPredicate来替代;
为何如此关注比较器 Comparator?
-
每次在api使用的时候名字提供了文档:使用频率高;
-
在合法的实例列表中强烈需要:需要通用的比较协议,通过实现这个接口,你遵守了承诺;
-
很多有用的默认方法可以组合和转换实例,6种形式的thenComparing和reversed;
基于目的写函数式接口的标准:
-
接口应该共享一个或多个比较器comparator的特征:经常使用,有个很好描述的名字,很强的关联,可以从默认方法中收益;
-
如果你写了一个函数式接口,记住,它是一个接口:所有的接口都需要特别关注;
辩证的使用streams
什么是流?
- 一系列从集合,数组,输入设备等过来的数据对象,为了大量的数据处理;
- 按照管道处理数据:一个数据源,0个或多个中间操作,一个终止操作;
- 支持大部分函数式数据处理;
- 支持无痛并行:简单的替换流为parallelStream:你可能看到性能提升;
标准实现,不使用流
public static void test1(String[] args) throws FileNotFoundException {
File dictionary = new File(args[0]);
int minGroupSize = Integer.parseInt(args[1]);
Map<String, Set<String>> groups = new HashMap<>();
try (Scanner s = new Scanner(dictionary)) {
// Item 9
while (s.hasNext()) {
String word = s.next();
groups.computeIfAbsent(alphabetize(word), (unused) -> new TreeSet<>())
.add(word);
}
}
for (Set<String> group : groups.values()) {
if (group.size() >= minGroupSize) {
System.out.println(group.size() + ": " + group);
}
}
}
使用流,连字符串的处理都使用流
public static void test2(String[] args) throws IOException {
Path dictionary = Paths.get(args[0]);
int minGroupSize = Integer.parseInt(args[1]);
try (Stream<String> words = Files.lines(dictionary)) {
words.collect(
groupingBy(word -> word.chars().sorted()
.collect(StringBuilder::new,
(sb, c) -> sb.append((char) c),
StringBuilder::append).toString()))
.values().stream()
.filter(group -> group.size() >= minGroupSize)
.map(group -> group.size() + ": " + group)
.forEach(System.out::println);
}
}
使用流
public static void test3(String[] args) throws IOException {
Path dictionary = Paths.get(args[0]);
int minGroupSize = Integer.parseInt(args[1]);
try (Stream<String> words = Files.lines(dictionary)) {
words.collect(groupingBy(Test2::alphabetize))
.values().stream()
.filter(group -> group.size() >= minGroupSize)
.forEach(g -> System.out.println(g.size() + ": " + g));
}
}
为何不用streas去实现alphabetize方法?
- streams没有提供直接的支持char;
- 实现结果:不清晰,很难写正确,很难阅读,可能更慢;
看一下这段代码输出结果:
"Hello world".chars().forEach(System.out::print);
输出结果是:
7210110810811132119111114108100
因为chars得到的是一个IntStream;所以输出了整数;
修正:
"Hello world".chars().forEach(i-> System.out.print((char)i));
禁止使用streams处理char;
一个难题: 笛卡尔产品
private static List<Card> newDeck() {
List<Card> result = new ArrayList<>();
for (Suit suit : Suit.values()) {
for (Rank rank : Rank.values()) {
result.add(new Card(suit, rank));
}
}
return result;
}
private static List<Card> newDeck2() {
return Stream.of(Suit.values())
.flatMap(suit -> Stream.of(Rank.values()).map(rank -> new Card(suit, rank)))
.collect(toList());
}
写在最后:
- 流在很多事情上非常出色,但是它不是灵丹妙药;
- 你第一次学习流的时候,你可能会项把所有的循环转换成流式循环,别这么做,它可以让你的代码更短,但是不太简洁;
- 一边练习一边评价,合适的使用,流可以提高简介和清晰,但是很多的程序应该结合iteration和流;
- 并不是一开始就很清晰,如果你不懂,开始猜测然后开始探究源码,如果你感觉不对,尝试另外的方法
辩证的使用streams的并行化
并行化不一定更快。
file
为何例子中的并行程序跑的如此慢?
- 流的库中没有明确的注意如何去并行执行,这个探索很痛苦的失败了;
- 在最好的例子中,parallel没用:流的源头是stream.iteratoe或者中间操作被使用;
- 反例:limit操作的默认策略计算超额的元素,计算素数一个的时间是另外一个的两倍时间;
- 准则:不要无差别的并行化;
parallelize适合的场景:
-
Arrays,ArrayList,HashMap,HashSet,ConcurrentHashMap,int,long的区间;
-
这些数据源的公共特征:可以预见的分离,好的位置引用;
-
终止操作也会影响:必须快速并且容易并行化:减法比如min,max,count,sum是适合的,collectors不适合;
-
中间操作也会影响:mapping和filter非常适合,limit不适合;
parallel()仅仅只是优化:
-
优化需要判断;
-
不使用parallel除非你能证明它维护正确;
-
不适用parallel除非你确幸它能跑的更快;
-
测量性能在使用前后;
大神的小结
- java比以前庞大和复杂了;
- 现在一个多模式的语言;
- 不要仅仅关注如何使用特征,还要关注使用哪些;
- lambdas和streams是一个巨大的成功,但是你必须批判的使用他们;
- java的力量越大责任越大;
非神小白的小结
ppt首先对比了3个版本的effectiveJava的区别,然后挑选了新增的章节中的5个条目进行了演示,确实让人耳目一新。Java8,9最亮的点就是lambdas和streams .要好好利用和理解。
原创不易,转载请注明出处。
网友评论