设计时预留实现扩展的可能性，不要堵死扩展的路就好。 千万不要真的实现扩展，除非你真的知道这里短时间内需要扩展以及扩展的明确方向。

@askfilm 没有双标，这段代码是同事写的，他也是前 dubbo contributor ，平时写代码喜欢炫技

这种我统称为被 java 污染了脑子（

封了好几层每一层职责是什么？现在看起来什么事也没做，就是大肠包小肠

绝大部分自以为是的扩展，最后根本用不上。其中大概一半多增加了不必要的复杂度，对相关开发造成困扰。一小部分会对后续的基于真实需求的扩展造成非常大的阻碍

javaer 写代码考虑的真多。换成 python 的话，就没有这种烦恼，绝大部分 Pythonista 估计都会用第一种直来直去的写法。

支持第一种 以前设计模式流行的时候，公司有的代码特别恐怖，所有的地方都支持扩展，但是 99%其实就一种实现

现在有 Coding Agent 了，这种场景就算未来发现有扩展了改一套设计，找个 Agent ，明显有特征的代码（ new Thread ）全部扫一遍重构成新的方案，不要太简单

业务变化无法预知，不要过早优化，也不要过度设计。 这段伪代码，对应业务是什么？没对应业务，那肯定越简单越好。

抽象一般是你发现或者预见到了需要抽象的东西才去做，而不是自己去制造抽象