重写是运行时多态核心机制，非设计模式但支撑多模式落地；模板方法用重写固化流程放开细节，策略模式用重写替代条件分支，工厂方法用重写决定创建对象，观察者模式用重写定义响应动作。
方法重写（Override）是运行时多态的核心机制，它本身不是设计模式，但却是多个行为型和创建型模式落地的关键支撑。真正让重写“活起来”的，是把它放在合适的设计模式结构中，由框架或抽象层统一调度，子类只专注实现差异逻辑——这样既保留了重写的简洁性，又获得了模式带来的可扩展性与解耦能力。
模板方法模式：用重写固化流程、放开细节
这是最直接结合重写的模式。抽象父类定义算法骨架（final 方法），把可变步骤声明为 abstract 或 hook 方法，强制子类重写实现。
- 重写发生在具体子类中，比如 brew() 和 addCondiments()，不同饮料各自提供逻辑
- 父类的 prepareBeverage() 是 final 的，流程不可变，但每一步执行谁的重写方法，由运行时类型决定
- 新增一种新饮料（如 Matcha），只需新增一个子类并重写对应方法，原有代码完全不动，符合开闭原则
策略模式：用重写替代条件分支，让行为可插拔
当一段逻辑里充斥着 if-else 判断支付方式、通知渠道、校验规则时，可以把这些分支提取成策略接口，每个具体策略类通过重写接口方法来提供行为。
- 定义 PaymentStrategy 接口，含 pay(int amount) 方法
- AlipayStrategy、WechatPayStrategy 分别重写该方法，封装各自调用细节
- 上下文类（PaymentContext）只持有一个 Strategy 引用，运行时注入哪个实例，就调用哪个重写版本
- 加新渠道？写个新类实现接口、重写 pay 即可，不碰老代码，也不改 if-else
工厂方法模式：用重写决定创建什么，把 new 藏起来
工厂方法的本质，就是把“new 什么对象”这个决策，从客户端转移到子类的重写方法中。
立即学习“Java免费学习笔记（深入）”；
- 抽象工厂类声明 createProduct() 抽象方法
- 子类（如 MacFactory、WindowsFactory）重写它，分别返回 MacButton 或 WinButton
- 客户端只调用工厂的 createProduct()，实际执行的是子类重写后的版本，拿到的对象类型自然不同
- 新增操作系统支持？加一个 LinuxFactory 并重写 createProduct，其他地方零修改
观察者模式：用重写定义响应动作，解耦事件源与监听者
观察者模式中，被观察者只负责通知，真正“做什么”由观察者自己决定——这正是靠重写 update() 方法来实现的。
- Observer 接口定义 update(Subject s)
- 短信通知类、邮件通知类、日志记录类各自重写 update，内容完全不同
- 主题（Subject）遍历 observers 调用 update()，不用知道谁会做什么，也不用 if 判断类型
- 加一种新通知方式？写个新类实现 Observer、重写 update 就行，注册进主题即可
本质上，重写提供了“同名不同实”的能力，而设计模式提供了“谁来调用它、何时调用、如何组织调用关系”的框架。脱离模式，重写只是语法；嵌入模式，重写就成了可管理、可替换、可组合的行为单元。不复杂但容易忽略。
