面向对象思想是企业级系统领域建模的底层操作手册,核心是用类、封装、继承、多态表达“谁在什么约束下做什么事”:类刻画有身份的领域实体(如订单),value object表达无身份度量(如金额),entity强调唯一标识,aggregate root划定一致性边界;封装将业务规则内聚于类内(如cancel()强制检查发货状态);多态替代if-else应对策略分化(如freightcalculator接口);继承慎用于真正“is-a”语义(如个人/企业客户),优先组合实现可复用能力;建模关键在于持续追问类的业务含义、状态完整性与行为职责。

面向对象思想不是抽象概念,而是企业级系统领域建模的底层操作手册。它把业务现实映射为可协作、可演进、可验证的代码结构,核心在于用类、封装、继承和多态去表达“谁在什么约束下做什么事”。
用类精准刻画领域实体与边界
领域建模第一步不是画UML图,而是识别有明确身份、状态和行为的业务概念。比如“订单”不是数据库里的一张表,而是一个具备生命周期(创建→支付→发货→完成)、状态约束(未支付不能发货)、聚合规则(含多个订单项,但订单项不能脱离订单独立存在)的类。
- 用value object表达无身份的度量概念,如“金额”“地址”,强调不可变与相等性语义
- 用entity表达有唯一标识的业务主体,如“客户ID”“订单号”,其相等性由ID判定
- 用aggregate root划定一致性边界,确保跨对象修改时数据始终处于合法状态
用封装保障业务规则内聚落地
企业系统最怕业务逻辑散落在Service层或SQL里。面向对象要求把规则锁进类内部:状态变更必须走方法入口,校验逻辑随状态共存。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 订单的
cancel()方法内强制检查“是否已发货”,而不是靠调用方判断 - “库存扣减”不暴露
stockCount--字段操作,而是提供reserve(quantity)并返回结果状态(成功/不足/超时) - 敏感操作如“退款”自动触发审计日志记录,无需上层重复编写
用多态替代条件分支应对业务分化
当同一行为在不同业务场景下策略不同(如“计算运费”在普通订单、跨境订单、会员订单中逻辑各异),if-else会快速腐化。多态让变化点显式化、可插拔。
- 定义
FreightCalculator接口,各实现类对应具体策略 - 订单对象持有一个计算器引用,运行时按订单类型注入对应实现
- 新增一种计费方式只需新增实现类+配置,不触碰原有订单逻辑
用继承谨慎表达可复用的领域层次
继承在领域建模中应少用、慎用——它表达的是“is-a”强语义,而非技术复用。滥用会导致子类被迫继承无关行为,破坏单一职责。
- 适合场景:如“个人客户”和“企业客户”都属于“客户”,共享认证、联系人等基础能力,且业务上明确存在分类层级
- 避免场景:为复用工具方法而设计父类;或用继承区分“已审核订单”“待审核订单”——这本质是状态,应使用状态模式
- 优先考虑组合:将通用能力(如“可审计”“可版本化”)抽为接口或委托组件,更灵活可控
真正落地的关键不在语法,而在建模时持续追问:这个类代表什么业务含义?它的状态是否完整覆盖该实体的关键约束?它的行为是否只做它该做的事?回答清楚这些,Java 的 class 关键字就不再是技术符号,而是业务语言的翻译器。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










