方法重载与重写本身不是坏味道，但滥用会引发重复、耦合、语义模糊；重构应使其回归本意——重载简化接口，重写体现多态职责；常见重构方式包括合并委托、对象封装、删除无意义重载、提取钩子、组合替代继承及补全模板方法。
方法重载与重写本身不是坏味道，但滥用或误用会催生重复、耦合、语义模糊等典型坏味道。重构重点不在“删掉重载/重写”，而在于让它们回归本意：重载应简化调用接口，重写应体现多态职责；一旦偏离，就要干预。
重载引发的坏味道与重构方式
常见问题：为支持不同参数组合堆砌多个重载方法，实际逻辑高度重复，甚至出现“一个重载调另一个，再调第三个”的嵌套链；或重载仅因类型微小差异（如int/double）而存在，却没带来语义提升。
-
合并+委托：保留最通用的一个重载（如接收对象参数），其余退化为该方法的静态工厂或构造器调用。例如把
add(int, int)、add(double, double)、add(BigDecimal, BigDecimal)统一为add(Number a, Number b)，内部用策略分发，避免分支爆炸 -
用对象替代原始参数：当重载因字段组合不同而产生（如
createUser(String, String)、createUser(String, String, String)、createUser(String, String, String, Date)），提取为UserRequest类，只留一个createUser(UserRequest) -
删除无意义重载：若某个重载只是给参数设默认值（如
sendEmail(String to)调用sendEmail(to, null, null)），直接用方法默认参数（Java 21+）或构建者模式替代，避免接口膨胀
重写引发的坏味道与重构方式
常见问题：子类重写父类方法仅为了修改一两行逻辑，其余完全复制；或重写中大量条件判断区分自身类型（if (this instanceof PremiumUser)），违背里氏替换；又或父类方法空实现，迫使子类必须重写——这其实是模板方法缺失的信号。
-
提取钩子方法：将子类差异化逻辑抽象为
protected钩子方法（如beforeProcess()、formatResult()），父类统一调度，消除重复模板代码 -
用组合替代继承：当重写只为替换某段行为（如支付方式），把可变部分抽成策略接口，父类持有一个
PaymentStrategy，子类通过构造注入，而非继承后重写pay() -
补全模板方法：若发现多个子类重写同一组方法（如
validate()、execute()、notify()），在父类定义templateMethod()，按序调用钩子，强制流程一致性
重载与重写共存时的重构要点
当一个类既有多个重载，又被多个子类重写，结构极易失控。此时需判断：当前设计是否真需要“接口多态+行为多态”双重扩展？多数业务场景只需其一。
立即学习“Java免费学习笔记（深入）”；
-
降级重载为单入口：对外暴露唯一方法（如
process(Request request)），把原重载参数封装进Request子类，再由重写机制处理不同类型 -
拆分职责边界：重载负责“怎么调”，重写负责“怎么做”。例如
ReportGenerator提供generate(ReportType)（重载）和generate(HtmlReportRequest)（重载），而HtmlReportGenerator继承后只重写doGenerate()，不碰参数适配逻辑 -
命名直指意图：避免
handle()这种泛称重载，改用handleOrderCreated()、handleOrderShipped()；重写方法名也不要用handle()，而用handleAsVipCustomer()，让多态意图一目了然
