ADT架构方法论视频课程(Chap.3)：碎片的互换性

很多人在做系统设计时，真正卡住的不是“不会写代码”，而是“改不动结构”。一个模块稍微调整需求，牵一发动全身；想替换某个实现，却发现它和周边代码长在了一起。这门课讲的就是这件事：如何让系统里的“碎片”具备互换性。

这门课解决什么问题

课程聚焦在 ADT（抽象数据类型）架构方法论下的“碎片互换性”问题。它不教语法，也不讲框架用法，而是讨论一个更底层的问题：当你在设计一个组件、一个服务、一个接口时，凭什么觉得它未来可以被替换？课程用“威尼斯海军”和“软件碎片PnP”两个比喻，把“互换性”从硬件世界迁移到软件世界，让你看清一个可替换的碎片应该具备哪些特征。

更实际的是，它专门花了篇幅拆解常见的迷思，比如“接口抽象了就等于可替换”“用插件机制就万事大吉”。这些迷思会让你的设计看起来漂亮，但真正需要替换时才发现接口背后藏着隐式依赖。课程后半段集中讲“设计决策的未来性”，通过“缺乏未来性的设计”和“设计出未来性”两组对比，让你看到同样的需求，不同设计在半年后、一年后的维护成本差异。这不是理论空谈，而是能直接指导你写代码时怎么做取舍。

适合什么基础

如果你已经写过一些业务代码，开始思考模块边界，但每次重构都感觉像在拆炸弹，这门课正好对胃口。它不需要你精通某种语言，但需要你理解“接口”和“实现”的基本关系。如果你对继承、组合、依赖注入这些词只有模糊印象，看这门课会有点吃力；反过来，如果你已经知道这些概念，却不知道为什么它们常常解决不了实际问题，那这门课就是来补这块短板的。

建议先看第 1、2、3 节，把“碎片”和“互换性”的定义吃透。这三节建立了课程的核心语言，后面讨论未来性时反复用到这些概念。中间第 4、5 节讲“古老的技术”，看起来像历史回顾，其实是在帮你溯源：为什么有些被淘汰的架构思想，换个场景又变得有价值。不要跳过，它们会让你对“技术选型”有新的判断力。

学完能做什么

学完这门课，你应当能独立回答几个问题：我现在的系统里，哪些碎片是不可替换的？为什么它们不可替换？如果要让它们可替换，我需要付出什么代价？更重要的是，你能够在一个新项目里，主动设计出具备“未来性”的边界，而不是等需求变了再被迫重构。

配套练习不要只看视频，要动手。找一个你正在开发或维护的项目，挑一个你觉得最“死”的模块，试着用课程里的方法画出它的依赖关系，找出那些“看似有接口、实则写死”的地方。然后按照课程讲的“设计出未来性”的思路，做一次最小改动，把替换点暴露出来。哪怕只改一个类，也比看完十遍视频有用。资料包里没有现成的源码，所以练习要基于你自己的项目。如果你手头没有项目，就选一个开源项目里的模块，分析它的设计决策，写出你发现的互换性缺陷。

最后，别急着把课程里的所有结论当成教条。它提供的是一套判断框架，不是标准答案。等你真正在项目里实践过，再回头看那些“迷思”和“未来性”的设计，会有更深的体会。