java设计应平衡灵活性与复杂度，依据变化频率、影响范围和团队认知成本做取舍；优先为已知高频变更点抽象，用组合替代继承，接口粒度适中，善用final和不可变性提升可读性与安全性。
在Java中，灵活性和复杂度往往是一对矛盾体：过度追求可扩展性容易让代码臃肿难懂，而一味简化又会让后续修改举步维艰。关键不是选“灵活”还是“简单”，而是根据变化频率、影响范围和团队认知成本，做有依据的取舍。
从“可能变”到“真的会变”：用现实场景驱动设计
很多过度设计源于预设“将来可能会扩展”。但真实项目中，90%的预设扩展永远不会发生。建议只对已知会变、且变更成本高的部分提前抽象。
- 比如支付模块——已确认要接入微信、支付宝、银联，那定义
PaymentStrategy接口就合理；若目前只有一种支付方式，且半年内无接入计划，直接写死反而更清晰 - 日志级别切换、配置开关、Mock测试点这类高频调整项，适合用策略模式或依赖注入，而不是等出问题再硬编码改
用组合代替继承，降低耦合带来的隐性复杂度
继承看似简洁，但父类一动，所有子类都得跟着验证。组合把行为拆成独立组件，既保留复用性，又避免“牵一发而动全身”。
- 不要写
AdminUser extends User，而是让User持有RolePermissionHandler，权限逻辑单独演进 - 用
Function<t r></t>或自定义回调接口替代模板方法中的钩子函数，调用方按需传入，不强制子类实现空方法
接口粒度适中：太粗难复用，太细则难维护
一个接口该有多少方法？看它是否代表一个内聚的“能力契约”。如果实现类总要抛UnsupportedOperationException，说明接口被撑大了。
立即学习“Java免费学习笔记（深入）”；
-
FileStorage接口若同时包含upload()、download()、list()、delete()，但某些实现（如只读OSS）无法支持delete()，那就拆成ReadableStorage和WritableStorage - DTO对象不建议实现业务接口，它只是数据载体；行为应放在Service或Domain Service里，职责更清晰
善用final和不可变性，减少“灵活”带来的理解负担
不是所有地方都需要开放扩展。字段声明为final、类加final修饰、集合用unmodifiableList包装——这些“限制”反而提升了可读性和线程安全性。
- 配置类、枚举、领域模型中的核心属性，优先设为
final，避免运行时意外篡改 -
工具类（如
DateUtils）不提供实例化入口，全部静态方法+私有构造器，杜绝误用和状态污染
设计不是越通用越好，而是让下一个人接手时，能快速看懂“这里为什么这样写”，并且有信心改对。平衡点不在UML图里，而在你上次重构时删掉的那三行if-else中。
