Java中使用lambda表达式替换类方法是否属于不良实践？

一、写法合法性与实践评价 #

1. 合法性 #

这段代码语法完全合法，Java 8及以上版本支持将函数式接口的实例作为类的成员字段声明和初始化。

2. 额外优势 #

除了写法简洁外，这种写法的唯一额外收益是：这些字段可以直接作为函数式参数传递给其他高阶方法（比如Stream API的filter/map等），无需临时编写lambda或方法引用。

3. 属于不良实践的原因 #

这种写法存在非常多的风险，不推荐在生产代码中使用：

• 初始化顺序风险：Java实例字段的初始化优先级高于构造函数执行逻辑，你声明的方法引用会在初始化阶段直接捕获entries的引用，而此时构造函数还未执行，entries还是默认值null，直接会导致实例化时抛出NullPointerException。
• 引用绑定失效问题：方法引用在初始化时就绑定了当时的entries对象，后续你调用setEntries修改entries的指向后，这些方法引用仍然指向旧的Deque实例，和类当前的entries完全脱节，逻辑直接出错。
• 封装性被破坏：这些函数式字段是public且未加final修饰，外部可以随意修改字段值，直接篡改类的核心行为，完全违背面向对象的封装原则。
• 语义不符合设计规范：push、isEmpty、size都属于类的核心行为，常规设计中应该定义为成员方法，而非可被修改的成员字段。

二、NPE警告的原因 #

1. 方法引用触发警告的原因 #

IDE的警告是完全正确的：
当你写public Predicate<Block> push = entries::offerLast;时，方法引用的解析会在该字段初始化阶段执行，此时需要先获取entries的当前引用值。而根据Java的初始化顺序，entries的赋值是在构造函数中执行的，字段初始化阶段entries还是null，这段代码在实例化Blocks类时会直接抛出NullPointerException，所以IDE会提前告警。

2. 替换为lambda后警告消失的原因 #

当你改成block -> entries.offerLast(block)时，lambda实例的初始化阶段并不会访问entries的值，只是把执行逻辑保存下来。只有当你实际调用这个push的test方法时，才会去读取当前entries的引用，而调用时构造函数肯定已经执行完成，entries已经被初始化，所以没有初始化阶段的NPE风险，警告自然消失。
而且这种lambda写法还有一个额外好处：每次调用都会读取最新的entries值，不会出现setEntries后逻辑失效的问题。 #

内容的提问来源于stack exchange，提问作者csoler