不要为了现在的需求写代码，要为了下一次修改写代码。
设计模式的全部出发点浓缩在这一条里。好的结构不是让当前代码更少，而是让下次改动时不用翻遍整个项目。每引入一层抽象都有成本，但如果这层抽象能让未来的变更局部化，成本就值了。
看到 if-else 不断膨胀，问题不在条件判断，在于行为没有被抽出去。
Strategy 模式的触发信号。if-else 本身没有错，但当每个分支里的逻辑越来越长、而且未来还会加新分支时，行为应该从控制流里独立出来，变成可替换的对象。
继承是"我是什么"，组合是"我有什么"。多数时候你需要的是后者。
Decorator 和 Composite 背后的设计判断。继承层级一旦深了就很难改，因为改父类会影响所有子类。组合关系更灵活——对象之间通过接口合作，换一个实现不影响其他部分。
创建对象的代码和使用对象的代码不应该在同一个地方。
Factory 系列模式的核心主张。new 操作散布在业务逻辑里，意味着每增加一种产品类型，所有 new 的地方都要改。把创建逻辑集中起来，变更范围就被限制住了。
如果你发现自己在给一个类加第四个职责，停下来。
单一职责不是教条，但一个类承担太多事情的后果很实际：改其中一个职责时会不小心破坏另一个。设计模式里的分角色思路——把不同职责拆到不同类里——核心理由就是降低意外耦合。
模式不是发明出来的，是从反复出现的问题里长出来的。
GoF 的 23 个模式不是谁坐在实验室里设计的，是从大量真实项目中提取的共性结构。所以学模式的正确方式不是先背定义再找应用场景，而是先遇到问题再去模式库里找有没有现成的解法。
一个好的抽象应该让阅读代码的人不需要看实现就知道意图。
Template Method、Facade、Mediator 都在做同一件事：把复杂的实现藏起来，让调用方只看到意图清晰的接口。抽象不是为了"高级"，是为了让代码的读者能快速理解"这段代码要做什么"而不被"怎么做"的细节淹没。
过度设计和设计不足一样危险。区别只在于：设计不足当下就痛，过度设计三个月后才痛。
一个只有两种支付方式的系统硬要上 Abstract Factory，就是过度设计。代价是多了三层抽象，每次调试都要跳好几个文件。判断标准很朴素：如果未来一年内变更的可能性低于 50%，先不引入模式。