知识卡片
UI引擎的无谓抽象
内容
作者自述真实教训：设计UI引擎模块时，为”未来可能需要支持HTML、Excel等呈现方式”预先引入解析器接口+工厂接口+抽象工厂类三层结构，看似遵循单一职责原则，实则因抽象过度增加了方案复杂度——产品研发后期，预期的HTML/Excel需求根本没有发生。教训：面对不可预测的变化应先保证方案简单，等变化真正发生时再用”提炼接口”等重构手法应对，而不是为不可知的未来预先投资。
参考来源
- 位置：《解构领域驱动设计》第1章《软件复杂度剖析》1.3.1节《过度设计》（源文件：_epub-src/OEBPS/010.xhtml）
- 结论依据：原文用UI引擎模块的ViewElementResolver/Factory三层抽象设计为例，说明其为从未发生的HTML/Excel需求预留扩展点，反而增加了不必要的间接逻辑，并给出"先简单、变化发生时再重构"的应对原则。
- 原始内容：如此设计看似保证了视图元素呈现的可扩展性，也遵循了单一职责原则，却因为抽象过度而增加了方案的复杂度。……方案中工厂接口与抽象工厂类的引入，根本没有贡献任何解耦与扩展的价值……我所预期的HTML和Excel呈现的需求变化实际并没有发生。