作为软件系统架构的核心范式,面向对象方法贯穿软件开发生命周期。OOA、OOD 和 OOP 分别代表分析、设计和实现三个关键阶段,共同构成一个连贯的工程体系。
一、OOA (Object-Oriented Analysis,面向对象分析)
目标:理解问题域,建立业务概念模型,独立于技术实现。
核心任务与产出
-
领域建模
- 识别核心业务对象(如
Customer
、Order
、Product
)及其属性(customerId
,orderDate
)。 - 定义对象间关系:关联(
Customer
placesOrder
)、聚合(Order
containsOrderItem
)、泛化(User
←Admin
)。 - 产出:领域类图(Domain Class Diagram)。
- 识别核心业务对象(如
-
行为分析
- 通过用例图(Use Case Diagram)捕获系统功能(如
Place Order
、Process Payment
)。 - 用活动图(Activity Diagram)或状态图(State Diagram)描述业务流程(如订单状态机:
Created
→Paid
→Shipped
)。
- 通过用例图(Use Case Diagram)捕获系统功能(如
-
规则提取
- 定义业务约束(如“订单金额 ≥ 0”)和操作规则(如“支付前订单必须验证库存”)。
关键挑战
- 抽象准确性:避免过度技术化设计,聚焦业务本质。
- 需求完整性:确保所有业务场景被覆盖(通过用户故事或事件风暴验证)。
二、OOD (Object-Oriented Design,面向对象设计)
目标:将分析模型转化为可实现的技术蓝图,解决架构级问题。
设计层次与策略
-
架构设计
- 系统分层:展示层(MVC)、业务层(Domain Service)、数据层(Repository)。
- 组件划分:微服务边界设计(如
OrderService
vsPaymentService
)。 - 模式应用:
- 分层架构:隔离关注点
- 发布/订阅:解耦事件处理(如订单创建触发库存更新)
-
详细设计
- 类精化:
- 补充方法签名:
Order.calculateTotal() : BigDecimal
- 应用设计模式:
- 策略模式:支付方式(
CreditCardStrategy
、PayPalStrategy
) - 工厂模式:创建复杂对象(
OrderFactory.createInternationalOrder()
)
- 策略模式:支付方式(
- 补充方法签名:
- 数据库映射:
- ORM 设计(JPA 注解:
@OneToMany
映射Order
-OrderItem
) - 解决阻抗失衡:值对象(
Address
)嵌入 vs 实体独立表
- ORM 设计(JPA 注解:
- 接口契约:
- 定义服务接口(如
PaymentGateway.process(paymentRequest)
)
- 定义服务接口(如
- 类精化:
核心产出
- UML 设计图:类图(含方法)、序列图(交互流程)、包图(模块依赖)
- API 规范:REST端点、消息队列协议(如 Kafka Topic Schema)
三、OOP (Object-Oriented Programming,面向对象编程)
目标:基于设计模型,用编程语言实现可维护、可扩展的代码。
核心原则落地
-
封装(Encapsulation)
public class BankAccount {private double balance; // 状态隐藏public void deposit(double amount) { if (amount > 0) balance += amount; // 行为与规则绑定} }
-
继承(Inheritance)与多态(Polymorphism)
public abstract class PaymentMethod {public abstract void authorize(); // 抽象行为 } public class CreditCard extends PaymentMethod {@Overridepublic void authorize() { /* 调用银行API */ } // 多态实现 }
-
组合优于继承
class Engine { /* 功能实现 */ } class Car {private Engine engine; // 通过组合复用public void start() { engine.ignite(); } }
工程化实践
- SOLID 原则:
- 单一职责:
OrderValidator
只做校验,OrderPersister
只负责存储 - 开闭原则:通过新增
PaymentMethod
实现类扩展支付方式,而非修改现有代码
- 单一职责:
- 测试驱动:对
Order
业务逻辑编写单元测试(JUnit/Mockito) - 重构:识别代码坏味(如过大类)并应用重构模式(提取方法/引入策略)
三阶段协同关系
- 迭代性:现代敏捷开发中三阶段常循环演进(如DDD中的模型风暴)。
- 工具链支撑:
- OOA:Enterprise Architect, Lucidchart
- OOD:PlantUML, Structurizr
- OOP:IntelliJ IDEA(重构工具), SonarQube(质量检测)
关键成功因素
- 无缝传递:确保OOD类与OOA领域对象严格对应(避免“贫血模型”)。
- 模式适度:在OOD中避免过度设计,权衡模式引入的复杂度。
- 技术选型对齐:OOP阶段语言特性(如Java接口 vs Go接口)需匹配OOD抽象。
架构师视角:OOA/OOD/OOP构成从问题空间到解空间的完整链路。架构师的核心价值在于把控各阶段的关键决策点——在OOA中捕获本质业务约束,在OOD中平衡灵活性与性能,在OOP中通过代码结构守护系统演进能力。