Java 8 接口默认方法，适合用来收口哪些重复代码

Java 8 刚出来那阵，很多人讨论接口默认方法，讨论点常常是“它是不是打破了接口的纯粹性”。我后来在项目里真正用过几次后，反而觉得更实际的问题是：哪些重复代码适合放进去，哪些不适合。

默认方法不是为了让接口承载全部逻辑，而是给那些本来就围绕接口契约展开、又总在各个实现类里重复出现的小行为，提供一个稳定落点。

我会优先考虑的三类场景

1. 基于已有抽象的轻量组合

如果接口已经定义了几个基础方法，而某个常用行为只是把这些基础方法按固定顺序组合一下，默认方法就很合适。
它不引入额外状态，也不依赖具体实现细节，只是在抽象层补一条顺手路径。

2. 稳定、不太会分叉的通用行为

有些行为几乎所有实现类都一样，比如判空包装、简单状态转换、轻量便利方法。
这类代码如果每个实现都复制一遍，既啰嗦，也容易未来出现微妙偏差。

3. 为旧接口演进提供过渡

这一点在老项目里很有价值。
当你要给已有接口补一个新能力，但又不想瞬间修改所有实现类时，默认方法可以作为一层缓冲。

我不会往里面放的内容

也有一些东西我基本不建议往默认方法里塞：

• 依赖外部资源的复杂业务逻辑
• 需要大量状态或配置参与的行为
• 每个实现都大概率会重写的“伪通用逻辑”

这些代码一旦塞进去，看似减少重复，实际上只是把复杂性藏进了接口层。后面维护时，大家会越来越难判断默认实现到底是不是可靠默认值。

判断边界时，我只问一个问题

“这个行为是不是接口契约天然的一部分？”

如果答案是是，那默认方法往往有价值。
如果答案更像“只是某个项目当前刚好这么写”，那就应该留在实现层或工具类里。

一个实际收益

我后来最喜欢默认方法的一点，是它能让接口不仅定义“必须实现什么”，还能顺手提供一点“合理怎么用”。
只要边界不乱，它会提升抽象层的可读性，而不是破坏它。

小结

默认方法真正有用的地方，不在于它让接口变强大，而在于它让重复、稳定、贴近契约的小行为有了归宿。2017 年以后再看这件事，我更愿意把它当成边界工具，而不是语法糖。