构件级设计

理解构件设计

体系设计——建筑平面图、结构、房间和外部环境之间的连接机制

构件级设计——每个房间的内部细节设计

什么是构件？

构件是计算机软件中的一个模块化的构造块

系统中模块化的、可配置的和可替换的部件，该部分封装了实现并暴露了一组接口。

构件可能包含了一个相互协作的类的集合

OO component

构件设计的四个关键问题

1. 每个构件应该由哪些类组成
2. 类之间的关系是什么，是否需要优化
3. 构建提供的外部接口是什么
4. 每个类具体应该由哪些属性和成员方法

Component Design

目的

使系统发生变更时更灵活适并且减少副作用的传播

设计原则

1. 开闭原则（OCP）

   对扩展开放，对修改关闭原则。

   思想：

   需求变化时，不是通过修改类本身来完成，而是通过定义抽象类的新实现完成。
   通过抽象类及其接口，定义类的外部行为特征，相对稳定，不需要经常修改，因此可以满足“对修改关闭”。
   从抽象类导出的具体类可以改变系统行为，从而满足对“扩展开放”。

2. LSP

   liskov substitution principle

   思想：

   在任何父类出现的地方都可以用它的子类来替换，而不影响功能。

   能够保证系统具有良好的拓展性，同时基于类的多态性，能够减少代码冗余，避免运行期的类型判别。

3. 依赖倒置原则

   思想：

   依赖于抽象。

   高层模块不依赖于底层具体模块，二者都依赖于抽象。

   当两个模块之间存在紧密的耦合关系时，最好的方法就是分离接口和实现：在依赖之间定义一个抽象的接口使得高层模块调用接口，而底层模块实现接口的定义。

4. SRP

   single responsibility principle

   系统中的每一个类都应该只有一个职责（不是一个方法），如果多个职责耦合在一起，会影响复用性。

   单一职责原则体现了“高内聚，低耦合”

OO component level Design

步骤1：

标识出所有与问题领域相对应的设计类

设计类不是分析类的简单映射，一定结构更加优化，且更接近与实现

步骤2：

标识出所有与基础设施领域相对应的设计类

如界面类、线程调度类，安全控制类，操作系统服务类等。

如定时任务服务，获取本机用户名和域服务。

步骤3：

识别每个设计类的属性

描述类成员方法中的处理逻辑

步骤4：

描述持久的数据类型和管理他的类

步骤5：

详细描述开发视图以提供附加的实现细节

Designing Conventional Component

加工逻辑的设计是受算法设计和结构化程序的 管理的

Algorithm Design

the closest design activity to coding

Algorithm Design Model

• 流程图
• NS图
• PAD图
• pseudocode（伪代码）