面向对象建模通过封装、继承、多态和抽象实现高内聚低耦合，提升可维护性的关键是合理划分对象边界与职责：遵循单一职责原则、依赖抽象而非实现、用策略模式+组合应对变化、以业务语义命名类与方法，并用值对象、枚举、聚合根等强化模型表达力。
面向对象建模通过封装、继承、多态和抽象四大机制，把业务逻辑组织成高内聚、低耦合的模块，让代码更易理解、修改和扩展。可维护性提升的关键不在于“用了类”，而在于是否用对了对象边界和职责划分。
职责清晰：用单一职责原则划清类的边界
一个类只负责一个明确的业务能力，比如OrderService处理订单流程，PaymentGateway专注支付对接，InventoryChecker只校验库存——不混杂日志、校验、通知等交叉逻辑。这样改支付方式时，只动PaymentGateway及其子类；调价策略调整，只需更新PricingStrategy实现类，不影响订单主干流程。
- 识别动因：如果一个类常因多种不同原因被修改（如“因为风控规则变”和“因为前端字段加校验”都要改同一个类），说明职责过载
- 提取行为：把校验、格式化、转换等通用动作拆为独立工具类或策略接口，避免在多个Service里重复写if-else
- 命名即契约：类名体现其唯一意图，如EmailNotificationSender比NotificationUtil更能约束后续开发行为
可替换性保障：依赖抽象而非具体实现
Java中大量使用接口（interface）和抽象类定义契约，让上层模块不绑定具体技术细节。例如订单创建流程依赖InventoryService接口，而不是RedisInventoryService或DBInventoryService。上线后发现缓存一致性难控？只需新增DBInventoryService实现类，配合Spring配置切换Bean，无需改动OrderService一行业务逻辑。
- 接口粒度适中：按使用方需要定义，避免“大而全”的接口（如CommonService），也避免过度拆分导致调用链太碎
- 构造注入优先：用构造函数传入依赖，既显式表达依赖关系，又方便单元测试Mock
- 避免静态工具类泄露实现：像DateUtils.format()看似方便，但一旦要支持时区/国际化/自定义格式，就变成全局污染点
变化隔离：用继承与组合应对不同维度的扩展
当系统需支持多种行为变体（如不同地区的税费计算、多种物流渠道履约），优先用策略模式+组合，而非深度继承树。例如定义TaxCalculator接口，由CNVatCalculator、USStateTaxCalculator等实现；订单对象持有一个TaxCalculator引用，运行时根据地区动态设置。这样新增国家税规，只加一个实现类，不碰原有类结构，也不会触发父类修改带来的回归风险。
立即学习“Java免费学习笔记（深入）”；
- 继承用于“是”关系且生命周期一致的场景（如AdminUser是User），慎用于“有”关系（如订单“有”物流信息→用组合）
- 模板方法模式适合流程固定、步骤可变的场景（如统一的退款审批流程，但各渠道驳回动作不同）
- 避免protected字段和方法暴露内部状态，削弱封装性——子类越容易绕过父类约束，后期越难重构
模型即文档：让类结构反映真实业务语义
好的领域模型不是数据库表的翻版，而是业务人员能看懂的表达。比如不用OrderDO、OrderVO这种技术导向命名，而用Order、Customer、ShippingAddress；把“status=2”封装为order.isShipped()，把金额计算逻辑收进Order.totalAmount()。这样新成员读代码就是在读业务规则，改需求时能快速定位到对应类，而不是grep一堆数字状态码和散落的计算公式。
- 值对象（Value Object）代替原始类型：用Money类封装金额和币种，避免BigDecimal到处传参丢失上下文
- 聚合根明确生命周期：比如Order是聚合根，OrderItem只能通过Order访问，防止外部直接修改导致数据不一致
- 用枚举替代魔法值：状态、类型、渠道等有限集合，全部用enum定义，并附带业务行为（如OrderStatus.CANCELLED.canRefund()）
基本上就这些。可维护性不是靠堆砌设计模式，而是持续用对象语言翻译业务问题——类是名词，方法是动词，接口是契约，继承是分类，组合是协作。写出来的代码，别人一眼能懂它在做什么、在哪改、改了影响谁。
