design-is-taking-apart

# 组合优于构建 ## 核心洞察 > “设计就是拆解事物。” 好的设计不是关于添加功能。它是关于移除依赖。它是关于如此清晰地分离关注点，以至于每个部分都可以被独立理解、测试和更改。 ## 拆解事物 当你看到一个复杂的系统时，本能是去理解各个部分是如何组合在一起的。但真正的技能是看出如何将它们*拆解开来*。 - 这里混合了哪些不同的关注点？ - 哪些职责可以分开？ - 我们在哪里混淆了不同的概念？ 每一次分离都会减少复杂性。每一次耦合都会增加复杂性。 ## 从简单的部分构建 一旦你有了简单、独立的部分： - 它们可以自由组合 - 它们易于测试 - 它们可以安全地更改 继承会使事物复杂化。组合则带来自由。 一个由转换数据的小型、专注函数组成的系统： - 更易于理解（每个部分只做一件事） - 更易于测试（纯函数，清晰的输入/输出） - 更易于更改（修改一个部分而不触及其他部分） ## 反模式 组合的反面是“上帝对象”或“大杂烩”——一个知道所有事情、做所有事情，并且不破坏其他一切就无法更改的东西。 你添加到类中的每一个辅助方法都是迈向“大杂烩”的一小步。每一层抽象都是等待引发痛苦的耦合。 ## 实际应用 在添加方法、包装器或抽象之前： - 这是在*分离*关注点，还是在*组合*它们？ - 我是在让部分变得更独立，还是更耦合？ - 我能用一个接收数据并返回数据的函数来解决这个问题吗？ **分离，不要组合。组合，不要构建。** ## 外部参考 - [Simple Made Easy](https://www.infoq.com/presentations/Simple-Made-Easy/) - Rich Hickey 关于复杂化与组合的论述 - [Out of the Tar Pit](https://curtclifton.net/papers/MosesleyMarks06a.pdf) - Moseley & Marks 关于本质复杂性与偶然复杂性 - [A Philosophy of Software Design](https://www.amazon.com/dp/173210221X) - John Ousterhout 关于深层与浅层模块