OOAD操作指南

发表于 分类于 ，

OOAD操作指南

一、OOAD是什么

OOAD（Object-Oriented Analysis and Design）是面向对象分析与设计的简称，分为两个阶段：

  • OOA（分析阶段）：理解业务，确定”做什么”
  • OOD（设计阶段）：设计实现方案，确定”怎么做”

二、OOAD要完成的任务

步骤 阶段 核心任务 产出物 与下一步的关系
1 需求分析 理解用户需求 需求文档、用例图 为领域建模提供业务对象线索
2 领域建模 识别业务对象和关系 领域模型、类图 为类设计提供对象定义
3 类设计 设计类的属性和方法 详细类定义 为架构设计提供基础单元
4 架构设计 确定系统层次和模块 架构图、分层设计 为详细设计提供结构框架
5 详细设计 设计对象交互流程 时序图、接口定义 指导编码实现

三、OOAD执行步骤

步骤1：需求分析

做什么：收集和理解用户需求

怎么做：

  1. 与用户沟通，收集功能需求
  2. 识别系统参与者和用例
  3. 编写用例描述

示例：电商系统需求

1
2
3
4
5
参与者：顾客、商家、管理员
用例：
  - 顾客：浏览商品、下订单、支付
  - 商家：上架商品、处理订单
  - 管理员：管理用户、查看报表

步骤2：领域建模

做什么：基于需求分析结果，找出业务中的关键对象和它们的关系

怎么做：

  1. 从需求文档中识别名词（候选对象）：关注需求描述中的业务实体
  2. 筛选核心领域对象：去除冗余，保留与业务密切相关的对象
  3. 确定对象属性：识别对象的关键特征
  4. 确定对象之间的关系：关联、聚合、组合、继承

示例：基于电商需求分析的领域模型

1
2
3
4
5
6
7
8
9
10
11
12
需求中的名词：用户、商品、订单、订单项、购物车、支付记录...

核心领域对象：
  - 用户(User)
  - 商品(Product)
  - 订单(Order)
  - 订单项(OrderItem)

对象关系：
  - 用户 --创建--> 订单（一对多）
  - 订单 --包含--> 订单项（组合关系，订单项不能独立存在）
  - 订单项 --关联--> 商品（多对一，订单项引用商品信息）

步骤3：类设计

做什么：将领域对象转化为程序类，为架构设计提供基础单元

怎么做：

  1. 根据领域模型，定义类名、属性、方法
  2. 确定类之间的关系（继承、关联、组合）
  3. 应用设计原则（SOLID）
  4. 为架构分层做准备：识别哪些类属于领域层，哪些属于应用层

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// 领域层类 - 包含核心业务逻辑
public class Order {
    private Long id;
    private User user;
    private List<OrderItem> items;
    private OrderStatus status;
    
    // 领域方法：业务规则在此实现
    public void addItem(Product product, int qty) {
        if (status != OrderStatus.CREATED) {
            throw new IllegalStateException("只能修改待支付订单");
        }
        items.add(new OrderItem(product, qty));
        recalculateTotal();
    }
    
    public void pay() {
        this.status = OrderStatus.PAID;
    }
}

步骤4：架构设计

做什么：确定系统的整体结构，将类组织到合适的层次和模块中

4.1 常见架构模式

模式 适用场景 核心思想
分层架构 大多数企业应用 按职责分层：表现层→应用层→领域层→基础设施层
MVC Web应用 分离Model、View、Controller
微服务 大型分布式系统 按业务拆分独立服务

4.2 架构选型建议

简单决策法：

  • 小型项目/团队 → 使用分层架构（推荐）
  • 复杂业务逻辑 → 在分层架构基础上增加领域层
  • 大型分布式系统 → 考虑微服务

4.3 分层架构设计（推荐）

四层结构：

1
2
3
4
5
6
7
8
9
┌─────────────────────────────────────┐
│  表现层 (Presentation)               │  ← Controller，处理HTTP请求
├─────────────────────────────────────┤
│  应用层 (Application)                │  ← Service，编排业务流程
├─────────────────────────────────────┤
│  领域层 (Domain)                     │  ← 实体类，核心业务逻辑
├─────────────────────────────────────┤
│  基础设施层 (Infrastructure)          │  ← Repository，数据访问
└─────────────────────────────────────┘

层间规则：

  • 上层可以调用下层，下层不能调用上层
  • 只能调用相邻层，不能跨层
  • 层间通过接口交互，使用DTO传递数据

模块划分示例：

1
2
3
4
5
src/
├── controller/     # 表现层：Controller类
├── service/        # 应用层：业务编排
├── domain/         # 领域层：Order、User等实体
└── repository/     # 基础设施层：数据访问

步骤5：详细设计

做什么：基于架构设计，设计对象之间的交互流程

怎么做：

  1. 绘制时序图：描述请求在各层之间的流转过程
  2. 设计接口参数：定义每层接口的输入输出
  3. 确定异常处理：每层如何捕获和转换异常

示例：基于分层架构的下订单流程

1
2
3
4
5
6
7
8
9
10
11
用户请求
    ↓
[表现层] OrderController.createOrder(request)
    ↓
[应用层] OrderService.createOrder(command)
    ↓
[领域层] Order.create() → 业务规则校验
    ↓
[基础设施层] OrderRepository.save(order)
    ↓
返回结果

设计要点：

  • 严格遵循架构设计的层次结构
  • 每层只处理本层职责（表现层做参数校验，领域层做业务规则）
  • 层间通过DTO传递数据，避免直接暴露领域对象

四、OOAD核心原则

原则 含义 实践建议
单一职责 一个类只做一件事 类功能要聚焦
开闭原则 对扩展开放，对修改关闭 使用接口和抽象类
依赖倒置 依赖抽象而非具体 通过接口交互
高内聚 内部元素紧密相关 相关功能放一起
低耦合 减少类之间的依赖 降低相互影响

五、简单示例：学生选课系统

需求

  • 学生可以选课、退课
  • 老师可以查看选课学生
  • 课程有人数限制

领域模型

1
2
3
学生(Student) --选修--> 课程(Course)
课程(Course) --由--> 老师(Teacher) 教授
选课(Enrollment) --记录--> 学生选课信息

类设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Student {
    private String id;
    private String name;
    
    public Enrollment enroll(Course course) {
        if (course.hasCapacity()) {
            return new Enrollment(this, course);
        }
        throw new RuntimeException("课程已满");
    }
}

public class Course {
    private String code;
    private String name;
    private int capacity;
    private int enrolledCount;
    private Teacher teacher;
    
    public boolean hasCapacity() {
        return enrolledCount < capacity;
    }
}

调用流程

1
学生请求选课 → 选课Service → 检查课程容量 → 创建选课记录 → 更新课程人数 → 返回结果

六、总结

OOAD的核心过程：

  1. 分析：理解需求，识别对象
  2. 设计：定义类结构，确定关系
  3. 实现：按设计编码，保持结构

关键记住：先分析清楚业务，再设计实现方案。