多态是否过度设计，关键看是否真实解决扩展性、可维护性或解耦问题；若仅一种实现却提前抽象、层级过深、增加理解成本或违背开闭原则本意，则属过度设计。
评估多态是否过度设计，关键不是看用了没用，而是看它是否真正解决了扩展性、可维护性或解耦问题。如果只是为了“看起来像面向对象”而强行抽象，就容易滑向过度设计。
看有没有真实的多变行为需求
多态的核心价值是“同一行为，不同实现”。如果当前业务中某个操作确实存在多种稳定且差异明显的实现路径（比如支付方式有微信、支付宝、银行卡；通知渠道有短信、邮件、站内信），那引入接口+多态是自然选择。反之，若目前只有一种实现，未来半年也几乎不会新增第二种，却提前定义 PaymentService 接口、写三个实现类、再配 Spring 的 @Qualifier 注入——这就属于过早抽象。
- 真实信号：已有2种以上实现，或产品已明确排期支持第2种
- 危险信号：只有1个实现，其余全是“为以后留接口”的空壳类
看抽象层级是否合理
过度设计常表现为抽象过深、层次过多。比如为“发送一条消息”拆出 MessageSender → AsyncMessageSender → RetryableAsyncMessageSender → DistributedRetryableAsyncMessageSender，而实际业务只要发一次HTTP请求。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 健康做法：从最简接口起步（如 MessageService.send(String content)），等出现明显行为分叉（同步/异步、重试/不重试、本地/分布式）时，再按需拆分
- 典型陷阱：一上来就设计泛型+策略+模板方法+事件回调的“全能框架”，但调用方只传一个字符串
看是否增加了理解与协作成本
多态本应降低复杂度，但如果团队新人花半天才搞清 “为什么这里 new 的是 EmailNotifier，实际跑的是 SlackNotifier”，或者每次加一个新通知方式都要改配置、加 Bean、写 Factory、补单元测试——说明抽象已经反噬开发效率。
立即学习“Java免费学习笔记（深入）”；
- 好信号：新增一种实现只需写一个类 + 加个 @Service，其他代码零修改
- 坏信号：每次新增都要动入口类、改枚举、更新 switch-case、同步文档、协调上下游
看是否违背了开闭原则的本意
开闭原则说“对扩展开放，对修改关闭”，但很多人误读为“必须预留所有可能的扩展点”。其实它强调的是：当变化发生时，你能不能只加代码、不改老代码。如果为了“理论上可能扩展”，把每个方法都做成策略+工厂+配置化，结果90%的策略永远用不上，那不是开闭，是预支技术债。
- 务实做法：等第一个“变化”真实发生，再把重复逻辑抽成可替换的部分
- 反模式：用设计模式模拟设计模式，比如为“选策略”再套一层策略模式
