OOA、OOD 和 OOP 是面向对象方法学中的三个核心阶段/概念,它们共同构成了一个完整的软件开发过程。
OOA (Object-Oriented Analysis – 面向对象分析)
- 目标: 理解问题域,识别系统中的核心概念、实体及其关系,建立现实世界的模型。
- 焦点: 做什么? (What?) – 系统需要完成什么功能?系统涉及哪些“东西”?这些“东西”有什么特性?它们之间如何互动?
- 主要活动:
- 识别对象 (Objects): 找出问题域中存在的关键实体或概念(如:顾客、订单、商品、账户)。
- 识别类 (Classes): 将具有相同属性和行为的对象抽象成类(如:所有顾客都属于Customer类)。
- 定义属性 (Attributes): 描述对象或类的状态或特征(如:Customer类有name, address, phoneNumber等属性)。
- 定义行为/操作 (Operations/Methods): 描述对象能做什么(如:Customer类可以有placeOrder(), updateProfile()等方法)。
- 识别关系 (Relationships): 确定类/对象之间的联系,主要包括:
- 关联 (Association): 对象之间的一般性联系(如:Customer 拥有 Order)。
- 聚合 (Aggregation): “整体-部分”关系,部分可以独立于整体存在(如:Order 包含 OrderItem)。
- 组合 (Composition): 更强的“整体-部分”关系,部分的生命周期依赖于整体(如:Window 由 Frame和Pane组成,关闭窗口则框架和窗格也不存在)。
- 泛化/继承 (Generalization/Inheritance): “is-a” 关系(如:SavingsAccount 是一种 Account)。
- 依赖 (Dependency): 一个类的改变可能影响另一个类(如:Order 使用 PaymentProcessor)。
- 建立用例模型 (Use Case Modeling): 描述系统与外部参与者(用户或其他系统)的交互,定义系统的功能需求。
- 产出物: 分析模型(通常用UML图表示,如类图、用例图、活动图、状态图等)。这是一个高度抽象、独立于技术实现的模型。
OOD (Object-Oriented Design – 面向对象设计)
- 目标: 在OOA模型的基础上,将其转化为一个可行的、高效的、可实现的解决方案蓝图。关注如何构建系统以满足需求和非功能性需求(性能、可维护性、可扩展性等)。
- 焦点: 怎么做? (How?) – 如何组织类和对象?如何实现它们的行为?如何满足约束(如数据库、用户界面、网络)?
- 主要活动:
- 精化分析模型: 将OOA中的概念类细化为设计类,添加实现细节(如具体的数据类型、方法签名、访问权限public/private)。
- 定义软件体系结构: 确定系统的主要子系统、组件及其交互方式(如分层架构 MVC)。
- 设计关键机制: 设计对象如何协作完成特定任务(如对象如何创建、持久化、通信、处理错误)。
- 接口设计: 明确定义类与类之间、模块与模块之间的接口(契约)。
- 数据库设计: 设计如何将对象持久化到数据库(对象-关系映射 ORM)。
- 用户界面设计: 设计用户如何与系统交互(可能涉及专门的UI设计)。
- 应用设计原则:
- 高内聚低耦合: 类内部功能紧密相关,类之间依赖最小化。
- 开闭原则: 对扩展开放,对修改关闭。
- 单一职责原则: 一个类只负责一项功能。
- 依赖倒置原则: 依赖于抽象,而非具体实现。
- 接口隔离原则: 使用多个专门的接口,而非一个臃肿的总接口。
- 里氏替换原则: 子类必须能够替换其父类。
- 产出物: 设计模型(更详细的UML图,如精化的类图、序列图、组件图、部署图等)。这是一个技术解决方案模型,为编码提供蓝图。
OOP (Object-Oriented Programming – 面向对象编程)
- 目标: 使用支持面向对象范式的编程语言(如Java, C++, Python, C#),将OOD阶段产生的设计模型转化为实际可运行的软件代码。
- 焦点: 具体实现 – 用代码表达类、对象、关系和行为。
- 核心概念在代码中的体现:
- 类 (Class): 用class关键字定义,是创建对象的蓝图。
- 对象 (Object): 类的实例,通过new关键字创建。
- 封装 (Encapsulation): 将数据(属性/字段)和操作数据的方法绑定在一起,并通过访问修饰符(private, protected, public)控制对内部数据的访问。
- 继承 (Inheritance): 使用extends(Java, C#)或:(C++)等关键字,子类继承父类的属性和方法,并可以添加或覆盖(@Override)特定行为。
- 多态 (Polymorphism):
- 编译时多态 (方法重载): 同一个类中方法名相同,参数列表不同。
- 运行时多态 (方法重写 + 向上转型/接口): 父类引用指向子类对象,调用被重写的方法时,实际执行的是子类的方法。这是OOP最强大的特性之一。
- 抽象 (Abstraction): 通过抽象类(abstract class)和接口(interface)定义行为契约,隐藏具体实现细节。
- 主要活动: 编写类定义、实现方法逻辑、创建对象、管理对象间的协作和生命周期。
总结与关系:
- OOA 理解问题世界,建立概念模型 (What?)。
- OOD 基于OOA,设计技术解决方案 (How?)。
- OOP 基于OOD,用代码实现解决方案。
简单类比:
- OOA: 就像建筑师和客户沟通,了解客户想要什么样的房子(需求),画出房屋的功能布局草图(概念模型)。
- OOD: 就像建筑师根据草图,设计详细的建筑图纸、结构图、水电图(技术蓝图),考虑用什么材料、如何承重、如何布线。
- OOP: 就像施工队根据详细的建筑图纸,使用砖头、水泥、木材等材料(编程语言),按照图纸一步步把房子建造出来(编写代码)。
例子 (简化版 – 点餐系统):
- OOA:
- 识别对象:顾客(Customer)、订单(Order)、菜品(MenuItem)、服务员(Waiter)。
- 属性:Customer有name, tableNumber;MenuItem有name, price。
- 行为:Customer有placeOrder();Waiter有takeOrder(), serveOrder()。
- 关系:一个Customer可以下多个Order (关联);一个Order包含多个MenuItem (聚合);Waiter处理Order (关联)。
- 用例:顾客点餐。
- OOD:
- 精化类:Order类需要orderId, orderDate, status属性;placeOrder()方法需要参数指定菜品列表。
- 设计数据库表:Customers, Orders, MenuItems, Order_Items (关联表)。
- 设计接口:定义IPaymentProcessor接口来处理支付,不同支付方式实现该接口(符合开闭原则)。
- 设计通信:订单创建后如何通知厨房?可能使用消息队列或事件。
- OOP:
- 用Java/C#/Python等语言编写Customer, Order, MenuItem, Waiter类的代码。
- 实现placeOrder()方法:创建Order对象,添加MenuItem对象,设置状态为“已下单”,可能调用Waiter.takeOrder()或发送通知。
- 实现CashPaymentProcessor和CreditCardPaymentProcessor类来实现IPaymentProcessor接口(多态)。
评论前必须登录!
注册