面向对象系统分析与设计第4章 对象和类

面向对象系统分析与设计第4章对象和类—从基本概念到系统建模Contents本章知识框架面向对象系统分析与设计的核心概念脉络，从基础理论到工程实践。01面向对象基本概念总览02对象与类的深度解析03封装与状态管理04继承、多态与接口05UML可视化建模06面向对象系统分析与设计CHAPTER01面向对象基本概念总览从对象、类到组件与模式，构建面向对象方法论的完整认知框架Chapter04·Object&Class对象与类：面向对象的核心基石对象是系统中描述客观事物的基本封装单元，由标识、状态和行为三要素构成；类是对一组具有相同特征对象的抽象模板。Section01对象的三要素对象标识每个对象拥有唯一名称用于区分，如姓名为Joe的教师对象，标识使其在系统中可被唯一引用和定位。对象状态由一组属性值刻画对象当前特征，如Joe的性别、年龄、职位等个人信息构成其完整的状态集合。对象行为对象能够执行的操作集合，如教师对象具有授课、批改作业、指导学生等行为特征。Section02类的模板作用形式化描述类将实体的属性（数据）和操作（函数）封装为统一的整体结构，实现数据与行为的有机结合。实例与模板多个教师对象共享同一个Teacher类定义的结构与行为，确保系统的一致性和可维护性。抽象提取Teacher类定义所有教师共有的属性和方法，具体对象填充各自的状态值，实现从抽象到具体的映射。OBJECT-ORIENTEDDESIGN抽象与封装：从现实到模型的桥梁抽象是从具体实例中抽取共同特征形成概念的过程，帮助开发者聚焦与应用相关的核心特性；封装则将数据与操作组合为统一模块，通过接口控制外部访问，确保内部状态的安全性和一致性。抽象的本质特征抽取：从特定实例中抽取共同特征形成概念，保留与应用相关的特性并抛弃不相关特性两层抽象：对象是现实实体的抽象，类是一组对象的抽象——构成面向对象建模的认知阶梯实例：图书馆系统中对"书籍"的抽象只需保留书名、ISBN、借阅状态等核心属性封装的机制接口隔离：将数据和操作封装成整体对象，外部只能通过公开接口访问或修改内部数据信息隐藏：对象内部实现细节对外不可见，降低了系统各部分之间的耦合度实例：银行账户余额被封装保护，外部仅通过deposit()和withdraw()方法操作从现实到代码RealWorld现实世界实体书籍·账户·用户ABSTRACTION抽象Objects对象实例具体数据+行为ENCAPSULATION封装CodeModel类与接口模块化·低耦合·高内聚Inheritance&Polymorphism继承与多态：代码复用与灵活性的核心机制继承通过父子类层次关系实现特征传递和代码复用，多态则允许不同对象对同一消息做出差异化响应，二者共同构成面向对象设计的灵活性基础。继承层次Dog和Cat类从Mammal父类继承eyeColor等共有属性，子类无需重复定义即可使用父类特征，实现代码复用。Inheritance继承分类单继承（一个子类仅有一个父类）与多继承各有优劣，Java采用单继承加接口机制来规避多继承的菱形问题。JavaSingle多态行为不同对象对同一消息产生差异化响应：调用speak()时Dog返回"汪汪"而Cat返回"喵喵"，调用方无需判断具体类型。Polymorphism动态绑定多态的实现依赖继承与动态绑定：父类引用指向子类对象，运行时由JVM根据实际对象类型决定调用哪个方法。JVMRuntimeChapter4·Interfaces&Engineering接口、消息与工程化概念接口定义操作规范而将实现交由具体类完成，消息驱动对象间的交互协作；组件、复用和模式则是面向对象在软件工程层面的延伸——组件提供可替换的模块封装，复用提升开发效率，模式沉淀可重复使用的设计经验，三者共同推动面向对象从编码技术升级为工程方法论。接口与消息01接口（Interface）只描述操作规范的"做什么"而不定义"如何做"，实现类负责提供具体实现细节，实现规范与实现的分离。这种机制使得系统各模块可以独立开发、独立测试，大幅降低耦合度。02消息（Message）体现对象间的交互机制，通过向目标对象发送操作请求来触发行为，是对象协作的基本通信方式。消息传递隐藏了接收方的内部实现，支持运行时动态绑定。组件、复用与模式01组件（Component）是软件系统可替换的物理组成部分，封装模块功能实现，具备高内聚性和相对稳定的公开接口02复用（Reuse）将已有软件及其有效成分用于构造新系统，组件技术是实现软件复用的关键手段，显著提升开发效率03模式（Pattern）描述不断重复发生的问题及其解决方案，包含特定环境、问题和解决方案三要素，帮助设计者更快更好地完成系统设计CHAPTER04·OOPFUNDAMENTALS面向对象基本概念全景汇总面向对象方法论由11个核心概念构成完整体系：对象和类是基础构建块，抽象和封装是建模原则，继承和多态是复用与灵活性机制，接口和消息是交互方式，组件、复用和模式是工程化延伸。面向对象基本概念速查表概念核心定义典型示例对象由数据及操作构成的封装体，含标识、状态、行为三要素姓名为Joe的教师对象类现实世界实体的形式化描述，对象的模板Teacher类定义所有教师共有特征抽象从实例中抽取共同特征形成概念的过程从多位教师中提取共性形成Teacher类封装将数据与操作封装为整体，通过接口控制访问银行账户余额只能通过存取方法操作继承类之间的层次关系，子类继承父类特征Dog和Cat继承Mammal的eyeColor多态不同对象对同一消息产生不同行为Dog和Cat对speak()有不同实现接口操作规范说明，只定义做什么不定义怎么做Printable接口规定print()方法签名消息对象间交互的通信机制向订单对象发送submit()请求组件可替换的物理模块，封装功能实现支付组件可替换不同支付渠道实现复用将已有软件成分用于构造新系统复用认证组件到新项目中模式重复发生问题的解决方案模板单例模式确保全局只有一个实例CHAPTER02对象与类的深度解析从三要素到生命周期，从业务实体到类结构设计ObjectFundamentals对象三要素：标识、状态与行为的深层理解对象的标识确保其在系统中的唯一性和可追踪性，状态由属性值的集合构成并随方法调用而演变，行为通过方法定义对象能执行的操作和对外提供的服务。三者协同构成对象的完整语义，缺一不可。对象标识（Identity）是对象在系统中的唯一凭证：即使两个对象所有属性值完全相同，它们在内存中仍是不同实体，Java中通过==比较标识、equals()比较状态等价性。==/equals()对象状态（State）由全部属性的当前值构成动态快照：订单对象的状态包括编号、金额、创建时间和订单状态，状态随方法调用而持续演变。动态快照对象行为（Behavior）通过方法定义，分为两类：内部状态变更方法（如updateStatus()）和对外服务方法（如calculateTotal()），行为是对象能力的体现。内部/对外三要素协同关系标识确定"是谁"，状态描述"什么样"，行为定义"能做什么"——三者共同构成对象在系统中的完整语义画像。完整语义Chapter04·对象和类类的属性与方法设计原则高质量的类设计要求属性选择精确的数据类型以保证类型安全和业务语义清晰，方法遵循单一职责原则以确保每个操作意图明确，整体遵循高内聚低耦合原则使类成为独立且可复用的模块。属性设计金额字段精度保障使用BigDecimal而非float/double，避免浮点精度丢失导致财务计算错误，在电商和金融系统中尤为关键。BigDecimal方法设计单一职责拆分每个方法承担单一且明确的职责：将笼统的process()拆分为validateInput()、calculatePrice()、saveOrder()等意图清晰的方法。SRP属性设计枚举保障类型安全状态字段使用枚举类型（如OrderStatus.PENDING）而非int或String，保证类型安全和业务语义的可读性。Enum方法设计命名准确传达意图方法命名应准确描述业务意图：ship()比updateStatus(3)更直观，deductBalance()比modifyBalance(-100)更安全。ship()>updateStatus(3)属性设计时间字段类型化使用Instant或LocalDateTime而非String，利用类型系统自动处理时区和格式化问题。Instant方法设计高内聚低耦合类整体遵循高内聚低耦合原则：一个类只关注一个业务领域的职责，与其他类的依赖关系尽可能减少。内聚·解耦CLASSDESIGN从真实业务场景到类结构的映射业务场景到类结构的映射不是机械对应，而是聚焦"谁在做什么、状态怎么变、边界在哪里"三大核心的设计过程。类应体现角色、特征与动作的统一，每个类都是承载业务逻辑的实体而非简单的数据容器。电商仓储物流中心的真实业务场景01聚焦三大核心：类设计需明确该事物在系统中的角色（谁）、必须响应的动作（做什么）和稳定特征（有什么），而非简单罗列字段。02订单实体的类设计：不仅是编号、金额等字段的集合，更是有明确生命周期的业务实体，能执行提交、取消、发货、计算总价等业务动作。03库存项实体的类设计：核心不在于"有多少件"的数据属性，而在于"能否扣减""是否预警""归属哪个仓库"等业务能力的封装。04拒绝贫血模型：避免只提供getter/setter的纯数据容器类，应将业务规则嵌入对象行为中，使类成为具有业务智能的领域实体。ObjectLifecycle构造函数与对象生命周期管理构造函数是对象生命周期的起点，通过强制初始化关键字段确保对象诞生时即处于合法完整状态，避免"半成品"对象引发的运行时错误。01构造函数强制初始化关键字段订单号、用户ID、创建时间等核心属性必须在对象创建时确定，Java中可用final关键字由编译器保证赋值完整性，防止空值导致的空指针异常。final关键字·编译期检查02避免"半成品"对象不允许创建后再通过setter逐个填充属性，这种模式容易导致对象在中间状态下被错误使用，引发难以追踪的业务逻辑错误和数据不一致问题。Setter反模式·原子性创建03对象生命周期三阶段创建阶段通过构造函数初始化→使用阶段通过方法调用执行业务逻辑→销毁阶段由GC自动回收不再引用的对象，理解各阶段特性有助于优化内存使用。创建→使用→销毁04生命周期管理实践长生命周期对象（如数据库连接池、线程池）需要显式的close()或shutdown()方法来释放资源，不能仅依赖垃圾回收机制，否则会造成资源泄漏。close()/shutdown()·资源释放CASESTUDY综合案例：电商订单Order类的完整设计Order类完整展示了从业务需求到类结构的映射：精确类型选择、构造函数强制初始化、行为方法内嵌校验，是面向对象设计的典型应用。01·状态属性设计orderId（String）唯一标识，createTime（Instant）记录创建时间，amount（BigDecimal）精确表示金额避免浮点误差status字段使用OrderStatus枚举（PENDING/PAID/SHIPPED/COMPLETED/CANCELLED），类型安全且业务语义一目了然02·行为方法与业务规则submit()、pay()、ship()、cancel()等方法封装完整业务操作，每个方法内部校验当前状态是否允许该操作pay()内部检查：当前状态必须为PENDING、支付金额等于订单金额、订单未被取消，全部通过才更新状态为PAID03·构造函数与初始化构造函数接收userId和商品列表作为必传参数，自动生成orderId和createTime，初始状态设为PENDING关键字段声明为final，编译器强制保证构造时完成赋值，杜绝"半成品"订单对象进入系统流转CHAPTER03封装与状态管理从语法封装到业务封装，构建状态安全的对象行为设计ENCAPSULATION封装的三个维度：超越private与public封装的本质远超语法层面的访问控制，它包含信息隐藏、接口契约和不变量保护三个维度。真正的封装让对象成为自身状态的守护者，而非被动的数据容器。信息隐藏对象内部实现细节对外不可见，调用者只关心"能做什么"而非"怎么做"，修改内部实现不影响外部调用者，有效降低系统耦合度。接口契约公开方法定义了对象的服务承诺，调用者按约定使用接口即可获得预期结果，如deposit(amount)承诺合法金额入账后余额一定增加。不变量保护对象始终维护核心约束条件不被破坏，如银行余额不为负、订单状态不逆向回退、库存数量不低于零，这些约束由对象自身的方法逻辑保证。银行保险箱的安全机制，类比封装的信息隐藏与不变量保护ENCAPSULATION用封装控制状态变更的合法性状态变更不应通过直接赋值完成，而必须通过封装的业务方法触发，方法内部执行完整的合法性校验后才允许状态更新。订单状态流转控制禁止外部直接赋值：不允许order.status='shipped'这样的操作，必须通过ship()方法触发ship()完整校验链：已支付→库存充足→未超时，全部通过才更新状态并记录操作日志ship()账户余额安全操作禁止直接赋值：不提供setBalance()，只暴露addBalance()和deductBalance()deductBalance()校验：金额为正、余额非负、不超信用额度，任一不满足即抛出业务异常3Checks封装带来的系统收益精确追溯：所有状态变更有完整校验链路和操作日志，可精确定位异常来源集中维护：业务规则集中在对象方法内，避免散落各调用方导致规则不一致TraceableENCAPSULATIONPRACTICE封装实践对比：贫血模型vs充血模型贫血模型将对象退化为纯数据容器，业务逻辑散落在外部服务中，导致规则分散、状态不可控；充血模型将业务规则嵌入对象行为，使对象成为具有业务智能的实体。后者是面向对象设计的正确实践，显著提升代码的可读性、安全性和可维护性。ANTI-PATTERN反面案例：贫血模型01订单状态暴露为publicintstatus，任何地方都可以直接赋值修改，含义不明确且无法校验合法性02业务逻辑散落在外部Service类中，修改状态前需到处写if判断，规则重复且容易遗漏关键校验publicintstatusBESTPRACTICE正面案例：充血模型01状态字段为private，外部只能通过pay()、ship()等语义方法触发变更，可读性高且状态流转合法02业务规则集中在对象方法内部，pay()校验状态和金额，ship()校验库存和时效，修改规则只改一处private+pay()ship()DESIGNBENEFITS设计收益对比01安全性—充血模型杜绝非法状态流转，贫血模型无法阻止任意的状态赋值02可维护性—充血模型业务规则集中管理，贫血模型规则散落多处，修改时容易遗漏安全·可维护CHAPTER04继承、多态与接口掌握面向对象的三大高级特性，构建灵活可扩展的系统架构面向对象·继承继承机制：层次化建模与代码复用继承通过父子类层次关系实现代码复用和行为扩展，子类自动继承父类非私有成员并可添加新特性或重写已有方法。Java采用单继承+接口的设计避免了多继承的菱形问题，在保证结构清晰的同时保留了足够的灵活性。01继承的核心价值子类自动获得父类所有非私有属性和方法，可在此基础上添加新特性或重写方法实现差异化行为，如Circle继承Shape并重写getArea()。getArea()02单继承保持结构清晰一个子类只能有一个直接父类，避免了多继承中两个父类有同名方法时子类不知继承哪一个的菱形问题。菱形问题03Java的折中方案类单继承保证层次结构简洁，接口多实现提供灵活性——一个类只能extends一个父类但可以implements多个接口。extends+implements04继承的正确使用场景子类确实是父类的一种特殊类型（IS-A关系），如DogIS-AAnimal；而非仅仅为了复用代码，应改用组合。IS-ACHAPTER04·POLYMORPHISM多态：同一接口，差异化行为多态允许父类引用在运行时指向不同子类对象，通过动态绑定机制自动调用实际类型的方法实现。这种机制让系统具备强大的扩展能力——新增子类时无需修改已有调用代码，完美体现了"对扩展开放、对修改关闭"的开闭原则。多态的实现条件01存在继承关系（DogextendsAnimal），子类重写父类方法（Dog重写makeSound()），父类引用指向子类对象（Animala=newDog()）02编译器根据父类类型确认方法签名合法性，运行时JVM根据对象实际类型决定调用哪个具体实现动态绑定多态的应用价值01新增Animal子类时，所有使用Animal类型的代码无需修改，只需新子类实现makeSound()即可自动参与多态调用02调用方只依赖抽象类型Animal，不依赖具体实现类Dog或Cat，降低模块间耦合度，便于独立测试和维护低耦合开闭原则的体现01对扩展开放：可通过新增子类扩展系统行为，如新增Bird类只需实现makeSound()返回鸟鸣声02对修改关闭：已有的动物园管理系统代码不需要任何修改就能处理新加入的Bird对象，遍历代码自动适配OCPINTERFACEDESIGN接口：规范与实现分离的设计哲学接口定义了操作规范而不涉及实现细节，实现类负责提供具体行为，这种分离使系统各层之间通过契约交互而非直接依赖。接口的多重实现机制弥补了单继承的限制，让一个类可以同时扮演多种角色，极大提升了系统架构的灵活性。移动支付场景—接口规范在现实中的典型应用01接口的本质是契约：只声明方法签名（名称、参数、返回值），不提供实现代码，实现类必须完整实现接口中声明的所有方法02支付系统案例：定义Payment接口声明pay()方法，AlipayPayment和WechatPayment分别实现，调用方只依赖Payment接口而不关心具体支付渠道Payment→Alipay/Wechat03多重实现弥补单继承限制：一个类可以实现多个接口，如OrderServiceImpl同时实现OrderService和Serializable接口，兼具业务处理和序列化能力OrderService+Serializable04接口隔离原则：接口应当小而专注，每个接口只定义一组内聚的操作，避免"万能接口"导致实现类被迫实现大量不需要的方法CHAPTER04·OBJECTCOLLABORATION对象协作：构建反映业务依赖的引用关系对象间的引用关系应反映真实的业务依赖而非技术便利，过度耦合会导致系统僵化难以维护。引用的粒度控制订单持有用户引用表达购买关系，但不持有物流公司完整实例——只需运单号和物流状态，避免过度耦合部门与员工的双向关联需谨慎：员工存储Department引用，部门维护列表，需同步更新防止状态不一致Granularity引用共享的本质两个变量指向同一对象时共享状态：orderA和orderB引用同一订单，调用cancel()后状态同步更新这不是bug而是协作基础：多个对象通过共享引用实现状态同步，确保数据一致性Sharing协作设计原则最小知识原则：对象只应知道它直接协作对象的信息，不应穿透多层引用访问深层对象的内部状态单向依赖优先：尽量使用单向引用而非双向关联，减少生命周期管理的复杂度和内存泄漏风险PrinciplesCHAPTER05UML可视化建模统一建模语言的核心理念、图形类型与系统建模方法Chapter04·UMLUML概述：统一建模语言的定位与价值UML是面向对象的标准化可视化建模语言，用于描述、构造和记录软件系统设计，但不是编程语言。可视化建模语言而非编程语言用于描述系统设计蓝图，帮助团队沟通和记录设计决策，不能直接编译为可执行代码建模≠编程广泛的适用性适用于各种开发方法（瀑布、敏捷、迭代）、各生命周期阶段（需求、设计、实现、测试）以及各种应用领域全周期覆盖UML标准三要素语义（概念含义）、表示法（图形符号）和说明（使用规则），提供静态、动态、系统环境与组织结构四类模型语义·表示法·说明视图机制划分关注点不同视图聚焦系统不同方面（如逻辑视图、部署视图），每个视图可用一种或多种UML图来可视化表达多维度可视化CHAPTER04·UMLDIAGRAMSUML主要图形类型全景结构图描述系统静态组成，行为图描述动态交互，最常用组合：用例图+类图+序列图+状态图。STATICVIEW结构图（静态视角）01类图：描述系统的类结构及类之间的关联、继承、依赖关系，是最常用且最核心的UML图，用于系统架构设计和代码生成02对象图：展示某一时刻系统中对象实例及其关系，可视为类图在运行时的快照，用于验证设计或调试特定场景03组件图：描述系统的物理组件及其依赖关系，用于规划和管理系统模块划分，支持大规模系统的组件化开发04部署图：展示系统的物理部署架构，描述软件在硬件节点上的分布情况，用于系统运维和性能规划DYNAMICVIEW行为图（动态视角）01用例图：从用户角度描述系统功能需求，展示参与者与用例之间的关系，是需求分析阶段的重要交付物02序列图：展示对象间按时间顺序的消息交互过程，适合描述具体业务场景的调用流程，强调时序与协作03状态图：描述单个对象在其生命周期内的状态变化及触发条件，适合描述复杂状态机，如订单状态流转04活动图：类似流程图，描述业务流程的执行路径和分支判断，适合描述工作流，支持并行活动表示UML·CoreDiagrams用例图与类图：从需求到设计的核心桥梁用例图从用户视角描述系统功能需求，是需求分析的核心产出；类图从技术视角描述系统静态结构，是系统设计的基础蓝图。用例图：描述系统做什么📋三要素📋三要素参与者（Actor）代表与系统交互的用户或外部系统；用例（UseCase）代表系统提供的完整功能；关系描述二者的交互方式🛒电商系统示例🛒电商系统示例买家关联「浏览商品」「下单」「支付」三个用例；卖家关联「发布商品」「管理库存」用例USECASE类图：描述系统怎么构建🔗类之间关系🔗类之间关系关联（结构连接）、聚合（弱整体-部分）、组合（强整体-部分）、继承（父子类）、依赖（使用关系）🛒电商示例🛒电商示例Order与User关联；Order与OrderItem组合（同步删除）；User与Buyer继承CLASSDynamicBehaviorModeling序列图与状态图：描述系统的动态行为序列图从时间维度展示多对象间的消息交互流程，适合描述完整的业务场景调用链；状态图从状态维度展示单个对象的生命周期变化，适合描述状态逻辑复杂的实体。两者互补，共同构成系统动态行为的完整描述。序列图：对象交互的时间线01核心结构：垂直方向表示时间流逝，水平方向排列参与交互的对象每个对象拥有垂直的生命线，对象间通过水平箭头传递同步或异步消息，清晰展现调用时序关系02典型场景：用户下单完整调用链用户→OrderService创建订单→InventoryService检查库存→PaymentService生成支付链接，完整展示服务间协作与数据返回流程03适用场景：接口设计评审、性能瓶颈分析、分布式事务梳理帮助团队理解复杂业务流程中的服务依赖关系，识别不必要的同步调用和潜在的性能优化点多对象协作·时序调用链状态图：对象的生命周期01核心要素：状态节点与转换条件描述单个对象的所有可能状态及触发转换的事件条件。例如订单状态：PENDING→PAID由"支付成功"触发，PAID→SHIPPED由"卖家发货"触发02价值体现：边界情况全覆盖帮助开发者系统性地考虑所有状态转换路径，发现遗漏的异常场景，如CANCELLED状态下是否允许重新支付、SHIPPED后能否强制退回等边界规则03适用场景：复杂状态机设计、业务规则校验、代码生成为状态模式实现提供清晰蓝图，可直接映射为状态机代码，确保业务规则与实现的一致性单对象视角·状态机建模EngineeringPracticeRUP与迭代式开发：面向对象的工程实践RUP（Rational统一过程）是使用面向对象技术进行软件开发的最佳实践框架，它通过迭代式开发、需求管理、组件化架构、可视化建模、质量验证和变更控制六大实践，将面向对象方法论落地为可执行的工程流程。迭代式开发不追求一次性完成全部需求，而是通过多次迭代逐步完善系统，每次迭代交付一个可运行的增量版本。增量交付需求管理系统化管理需求变更，确保需求变更可追踪、可评估影响范围，避免无序变更导致项目失控。可追踪组件化架构使用以组件为中心的软件架构，构建模块化、可替换的系统结构，支持组件级别的独立开发和复用。模块复用可视化建模使用UML等建模工具进行设计文档化，让团队成员共享统一的设计视图，降低沟通成本。UMLCHAPTER06面向对象系统分析与设计从问题域分析到架构设计，构建完整的面向对象开发方法论SystemAnalysis面向对象系统分析：四大模型构建问题域认知面向对象系统分析的核心是运用面向对象方法建立问题域的业务模型，由用例模型、类对象模型、对象关系模型和对象行为模型四个子模型组成，共同形成对业务全貌的系统化认知。用例模型描述系统应该提供哪些功能，从用户角度定义系统边界：识别参与者（谁使用系统）和用例（系统提供什么功能）。功能需求类对象模型描述系统涉及哪些类和对象：从用例中提取业务实体，定义每个类的属性和方法，建立初步的类层次结构。实体结构对象关系模型描述对象间的结构关系：关联（如订单-用户）、聚合（如购物车-商品）、组合（如订单-订单明细）等关系的定义和多重性约束。实体关联对象行为模型描述动态交互：用状态图描述关键对象的状态流转（如订单生命周期），用序列图描述典型业务场景的对象协作流程。动态交互OBJECT-ORIENTEDDESIGN面向对象系统设计：从架构到详细类结构面向对象系统设计基于分析阶段的问题域模型，通过概要设计确定系统架构和子系统划分，通过详细设计完善每个类的完整结构和实现方案。设计活动涵盖用例设计、类设计和子系统设计三个层面，确保从宏观架构到微观实现的一致性。概要设计（架构层）确定子系统划分、模块间接口定义、技术选型和部署架构，回答系统分为几个模块、模块间如何通信等高层问题架构层详细设计（类层）定义每个类的完整属性列表、方法签名、内部实现逻辑和异常处理策略，为编码阶段提供精确的实施蓝图实施蓝图用例设计细化每个用例的技术实现方案，确定该用例涉及哪些类、调用顺序和错误处理策略，通常用序列图详细描述序列图子系统设计定义子系统内部结构和对外接口，确保子系统高内聚（内部功能紧密相关）且低耦合（子系统间依赖最小化）高内聚低耦合ORM映射策略数据库映射：保持领域语义的清晰性实体类是业务逻辑的载体而非数据库表结构的复刻。应保持类型安全和领域表达的准确性，映射注解只是技术适配手段。状态字段用枚举将t_order_status映射为OrderStatus枚举，保证类型安全且业务含义一目了然Enum金额用BigDecimal避免浮点精度丢失，DECIMAL类型与BigDecimal精确对应，杜绝财务计算错误BigDecimal时间用Instant利用类型系统自动处理时区和格式化，TIMESTAMP与Instant语义匹配Instant业务语义优先Order类的方法如pay()、ship()反映业务行为，不应因数据库结构而省略或变形领域驱动ORM注解为适配层@Column等注解