系统集成项目管理工程师(第3版):软件工程--面向对象设计

面向对象设计（Object-Oriented Design，OOD）是OOA 方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。在OOD中，数据结构和在数据结构上定义的操作算法封装在一个对象之中。由于现实世界中的事物都可以抽象出对象的集合，所以OOD 方法是一种更接近现实世界、更自然的软件设计方法。

OOD的主要任务是对类和对象进行设计，这是O0D 中最重要的组成部分，也是最复杂和最耗时的部分。其主要包括类的属性、方法，以及类与类之间的关系。OOD的结果就是设计模型。对于OOD而言，在支持可维护性的同时，提高软件的可复用性是一个至关重要的问题，如何同时提高软件的可维护性和可复用性，是OOD 需要解决的核心问题之一。在OOD中，可维护性的复用是以设计原则为基础的。

常用的OOD 原则包括：

单职原则：一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

开闭原则：对扩展开放，对修改封闭。当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

里氏替换原则：子类可以替换父类，即子类可以扩展父类的功能，但不能改变父类原有的功能。

依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程。

接口隔离原则：使用多个专门的接口比使用单一的总接口要好。

组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。

迪米特原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解。其目的是降低类之间的耦合度，提高模块的相对独立性。

在OOD 中，类可以分为3种类型：实体类、控制类和边界类。

1.实体类

实体类映射需求中的每个实体，是指实体类保存需要存储在永久存储体中的信息。例如，在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。实体类对用户来说是最有意义的类，通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型的转换中，一个参与者一般对应于实体类。通常可以从SRS 中的那些与数据库表（需要持久存储）对应的名词着手来找寻实体类。通常情况下，实体类一定有属性，但不一定有操作。

2.控制类

控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化来的名词。例如，用例“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象（控制类的实例）通常控制其他对象，因此，它们的行为具有协调性。控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在其对应的用例执行完毕后消亡。通常情况下，控制类没有属性，但一定有方法。

3.边界类

边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。要寻找和定义边界类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。

边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更（例如，与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类可以既有属性也有方法。

整理不易动动你发财的小手点个“在看”哦！

您的支持是我坚持的动力，谢谢