避免过度设计的关键是让设计决策服务于当前需求，以变化点驱动抽象、优先组合而非继承、接口聚焦闭环操作、警惕设计模式滥用，使代码如对话般自然清晰。
避免面向对象的过度设计，关键不是少用类、少写继承，而是让每个设计决策都服务于当前需求——能简单解决的问题，不提前抽象；能直接表达意图的代码，不绕道封装。
用“变化点”驱动抽象，而不是用“可能性”驱动
很多过度设计源于预判未来可能的变化，比如一上来就定义接口、工厂、策略族，结果半年过去业务逻辑没变过，接口却改了三次。真正该抽象的，是已经发生过两次以上变化、或明确收到产品确认即将变动的模块。
- 新增一个支付方式？先写死一个具体类，等第二个支付渠道上线时再抽接口
- 日志格式要适配不同环境？等测试/生产日志字段真不一样了，再拆Logger实现
- 别为“以后可能加权限”提前搞RBAC框架，先用if (user.isAdmin()) 控制，等角色多于3种、规则开始嵌套时再重构
优先组合，谨慎继承
继承容易绑定父类契约，一旦父类方法语义模糊或职责膨胀，子类就被拖垮。组合更灵活，也更贴近业务语言。
- 不要让Order extends Report —— 订单不是报表，它只是“需要生成报表”，用reportGenerator.generate(order) 更直白
- 避免AbstractService → UserService → AdminUserService 这类三层继承链，90%场景用UserService + PermissionChecker 组合就够了
- 想复用逻辑？先考虑提取工具类或默认方法（Java 8+ interface default method），比继承更轻量
接口粒度以“一次调用闭环”为界
接口不是越小越好，也不是越大越好。合理接口应代表一个完整、可理解的协作单元，调用方无需关心内部步骤就能完成一件事。
立即学习“Java免费学习笔记（深入）”；
- ❌ 不合理：OrderService.create(), OrderService.validate(), OrderService.persist() —— 调用方必须记住顺序和依赖
- ✅ 合理：OrderService.placeOrder(OrderRequest) —— 内部封装校验+创建+落库，语义清晰、不易误用
- 接口方法名尽量动宾结构（sendEmail, calculateDiscount），避免名词化（getEmailSender, getCalculator）——后者常是暴露实现细节的信号
警惕“设计模式洁癖”
单例、观察者、模板方法这些不是勋章，是工具。用了模式但没解决实际问题，就是噪音。
- 全局配置管理？Spring @ConfigurationProperties 比手写单例安全又简洁
- 发通知？先用简单的回调或事件总线（如Spring ApplicationEvent），别一上来就建Observer接口+Subject抽象类
- 算法替换？如果只有两种实现且不会新增，用if-else比策略模式+上下文更易读
基本上就这些。OOP不是堆砌概念，而是让代码像对话一样自然——谁在做什么，为什么这么做，下一步大概率是什么，都能一眼看清。设计深度，永远跟着业务复杂度走，而不是跟着教科书走。
