论文部分内容阅读
摘要：面向对象设计就是用面向对象观点建立求解空间模型的过程。通过面向对象分析得出的问题域模型为建立求解空间模型奠定了坚实基础，分析与设计本质上是_个多次反复迭代的过程，面向对象分析和面向对象设计的界限尤其模糊。文章主要介绍了为获得优秀设计结果应该遵循的基本准则和通过经验得出的几条有助于提高设计质量的启发式规则。有助于读者更加清楚的了解面向对象设计的优势。
关键词：面向对象设计；准则；启发式规则
0 引言
所谓优秀设计，就是权衡了各种因素，从而使得系统在其整个生命周期中的总开销最小的设计。指导软件设计的基本原理在进行面向对象设计时仍然成立，但是增加了一些与面向对象方法密切相关的新特点，从而具体化为下列面向对象设计准则。
1 面向对象设计准则
1.1 模块化
面向对象软件开发模式，很自然地支持了把系统分解成模块的设计原理：对象就是模块。它是把数据结构和操作这些数据的方法紧密的结合在一起所构成的模块。
1.2 抽象
面向对象方法不仅支持过程抽象，而且支持数据抽象。类实际上是一种抽象数据类型，它对外开放的公共接口构成了类的规格说明，这种接口规定了外界可以使用的合法操作符，利用这些操作符可以对类实例中包含的数据进行操作。使用者无须知道这些操作符的实现算法和类中数据元素的具体表示方法，就可以通过这些操作符使用类中定义的数据。通常这类抽象称为规格说明抽象。
某些面向对象的程序设计语言还支持参数化抽象。所谓参数化抽象，是指当描述类的规格说明时不具体制定所要操作的数据类型，而是把数据类型作为参数。这使类的抽象程度更高，应用范围更广，可重用性更高。
1.3 信息隐藏
在面向对象方法中，信息隐藏通过对象的封装性实现：类结构分离了接口和实现，从而支持了信息隐藏。对于类的用户来说，属性的表示方法和操作的实现算法都应该是隐藏的。
1.4 弱耦合
耦合是指一个软件结构内不同模块之间互连的紧密程度。在面向对象方法中，对象是最基本的模块，耦合主要指不同对象之间互相关联的紧密程度。弱耦合是优秀设计的一个重要标准，因为这有助于使得系统中某一部分的变化对其他部分的影响降到最低程度。
如果一类对象过多依赖其他类对象完成自己的工作，不仅给理解、测试或修改这个类带来很大困难，而且还将大大降低该类的可重用性和可移植性。类之间的这种相互依赖关系是紧耦合。对象不可能是完全孤立的，当两个对象必须相互联系相互依赖时，应该通过类的协议实现耦合，不应该依赖于类的具体实现细节。
1.4.1 交互耦合
如果对象之间的耦合通过消息连接来实现，这种耦合叫交互耦合。为使交互耦合尽可能松散，应遵循下述准则：
（1）尽量降低消息连接的复杂程度。应该尽量减少消息中包含的参数个数，降低参数的复杂程度。
（2）减少对象发送的消息数。
1.4.2 继承耦合
与交互耦合相反，应该提高继承耦合程度。继承是一般化类与特殊类之间耦合的一种形式。从本质上看，通过继承关系结合起来的基类和派生类，构成了系统中粒度更大的模块。因此它们彼此之间应该结合的越紧密越好。
为获得紧密的继承耦合，特殊类应该确实是对它的一般化类的一种具体化。如果一个派生类摈弃了它基类的许多属性，他们之间是松耦合。
1.5 强内聚
内聚衡量一个模块内各个元素彼此结合的紧密程度。也可以把内聚定义为：设计中使用的一个构件内的各个元素，对完成一个定义明确的目的所作出的贡献程度。在设计时应该力求做到高内聚。在面向对象设计中存在3种内聚：
（1）服务内聚。一个服务应该完成一个且仅完成一个功能。
（2）类内聚。设计类的原则是，一个类应该只有一个用途，它的属性和服务应该是高内聚的，类的属性和服务应该全都是完成该类对象的任务所必需的，其中不包括无用的属性或服务。如果某个类有多个用途，通常应该把它分解成多个专用的类。
（3）一般特殊内聚。设计出的一般特殊结构，应该符合多数人的概念，这种结构应该是对相应的领域知识的正确抽取。
紧密的继承耦合与高度的一般特殊内聚是一致的。
1.6 可重用性
软件重用是提高软件开发生产率和目标系统质量的重要途径。重用基本上从设计阶段开始。重用有两方面的含义：尽量使用已有的类；如果确实需要创建新类，则在设计这些新类的协议时，应该考虑将来的可重复使用性。
2 启发规则
人们使用面向对象方法学开发软件历史虽然不长，但也积累了一些经验。总结这些经验得出了几条启发规则，它们往往能帮助软件开发人员提高面向对象设计的质量。
2.1 设计结果应该清晰易懂
使设计结构清晰、易读、易懂，是提高软件可维护性和可重用性的重要措施。保证设计结果清晰易懂的主要因素如下：
（1）用词一致。名字与它所代表的事物一致，应该尽量使用人们习惯的名字。
（2）使用已有的协议。如果开发同一软件的其他设计人员已经建立了类的协议，应该使用这些已有的协议。
（3）减少消息模式数目。如果已有标准的消息协议，设计人员应该遵循这些协议。如果确需自己建立消息协议，应该尽量减少消息模式的数目，只要可能，就使消息具有一致的模式。
（4）避免模糊的定义。一个类的用途应该是有限的，而且应该从类名可以较容易的推想它的用途。
2.2 一般一特殊结构的深度应适当
应该使类等级中包含的层次数适当。在一个中等规模的系统中，类等级层次数应保持为7-2到7+2范围内。不应该仅仅从方便编码的角度出发随意创建派生类，应该使一般特殊结构与领域知识或常识保持一致。 2.3 设计简单的类
尽量设计小而简单的类，以便于开发和管理。当类很大的时候，要记住它的所有服务是非常困难的。如果一个类的定义不超过一页纸，则使用这个类是比较容易的。为使类保持简单，应该注意以下几点。
（1）避免包含过多的属性。属性过多通常表明这个类过分复杂，它所完成的功能可能太多了。
（2）有明确的定义。为了使类的定义明确，分配给每个类的任务应该简单，最好能用一两个简单语句描述它的任务。
（3）尽量简化对象之间的合作关系。如果需要多个对象协同配合才能做好一件事，则破坏了类的简明性和清晰性。
（4）不要提供太多服务。一个类提供的服务过多，表明这个类过分复杂，一个类提供的服务不要超过7个。
在开发大型软件系统时，遵循上述启发规则也会带来另一个问题：设计出大量较小的类，这同样会带来一定复杂性。解决这个问题的办法，是把系统中的类按逻辑分组，也就是划分“主题”。
2.4 使用简单的协议
消息中的参数不要超过3个。经验表明，通过复杂消息相互关联的对象是紧耦合的，对一个对象的修改往往导致其他对象的修改。
2.5 使用简单的服务
面向对象设计出来的类中的服务通常都很小，一般只有3-5行源程序语句，可以用仅含一个动词和一个宾语的简单句子描述它的功能。如果一个服务中包含了过多的源程序语句，或语句嵌套层次太多，或使用了复杂的CASE语句，应该仔细检查这个服务，设法分解或简化它。应该尽量避免使用复杂的服务。如果需要在服务中使用CASE语句，通常应该考虑用一般特殊结构代替这个类的可能性。
2.6 把设计变动减至最小
设计的质量越高，设计结果保持不变的时间也越长。即使出现必须修改设计的情况，也应该使修改的范围尽可能小。在设计的早期阶段，变动较大，随着时间推移，设计方案日趋成熟，改动也越小。
3 结语
分析是提取和整理用户需求，建立问题域精确模型的过程。设计则是把分析得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。系统设计确定实现系统的策略和目标系统的高层结构，对象设计确定解空间中的类、关联、接口形式以及实现服务的算法。面向对象设计就是用面向对象观点建立求解域模型的过程。许多分析结果可以直接映射成设计结果，在设计过程中又会加深和补充对系统需求的理解，从而进一步完善分析结果。
关键词：面向对象设计；准则；启发式规则
0 引言
所谓优秀设计，就是权衡了各种因素，从而使得系统在其整个生命周期中的总开销最小的设计。指导软件设计的基本原理在进行面向对象设计时仍然成立，但是增加了一些与面向对象方法密切相关的新特点，从而具体化为下列面向对象设计准则。
1 面向对象设计准则
1.1 模块化
面向对象软件开发模式，很自然地支持了把系统分解成模块的设计原理：对象就是模块。它是把数据结构和操作这些数据的方法紧密的结合在一起所构成的模块。
1.2 抽象
面向对象方法不仅支持过程抽象，而且支持数据抽象。类实际上是一种抽象数据类型，它对外开放的公共接口构成了类的规格说明，这种接口规定了外界可以使用的合法操作符，利用这些操作符可以对类实例中包含的数据进行操作。使用者无须知道这些操作符的实现算法和类中数据元素的具体表示方法，就可以通过这些操作符使用类中定义的数据。通常这类抽象称为规格说明抽象。
某些面向对象的程序设计语言还支持参数化抽象。所谓参数化抽象，是指当描述类的规格说明时不具体制定所要操作的数据类型，而是把数据类型作为参数。这使类的抽象程度更高，应用范围更广，可重用性更高。
1.3 信息隐藏
在面向对象方法中，信息隐藏通过对象的封装性实现：类结构分离了接口和实现，从而支持了信息隐藏。对于类的用户来说，属性的表示方法和操作的实现算法都应该是隐藏的。
1.4 弱耦合
耦合是指一个软件结构内不同模块之间互连的紧密程度。在面向对象方法中，对象是最基本的模块，耦合主要指不同对象之间互相关联的紧密程度。弱耦合是优秀设计的一个重要标准，因为这有助于使得系统中某一部分的变化对其他部分的影响降到最低程度。
如果一类对象过多依赖其他类对象完成自己的工作，不仅给理解、测试或修改这个类带来很大困难，而且还将大大降低该类的可重用性和可移植性。类之间的这种相互依赖关系是紧耦合。对象不可能是完全孤立的，当两个对象必须相互联系相互依赖时，应该通过类的协议实现耦合，不应该依赖于类的具体实现细节。
1.4.1 交互耦合
如果对象之间的耦合通过消息连接来实现，这种耦合叫交互耦合。为使交互耦合尽可能松散，应遵循下述准则：
（1）尽量降低消息连接的复杂程度。应该尽量减少消息中包含的参数个数，降低参数的复杂程度。
（2）减少对象发送的消息数。
1.4.2 继承耦合
与交互耦合相反，应该提高继承耦合程度。继承是一般化类与特殊类之间耦合的一种形式。从本质上看，通过继承关系结合起来的基类和派生类，构成了系统中粒度更大的模块。因此它们彼此之间应该结合的越紧密越好。
为获得紧密的继承耦合，特殊类应该确实是对它的一般化类的一种具体化。如果一个派生类摈弃了它基类的许多属性，他们之间是松耦合。
1.5 强内聚
内聚衡量一个模块内各个元素彼此结合的紧密程度。也可以把内聚定义为：设计中使用的一个构件内的各个元素，对完成一个定义明确的目的所作出的贡献程度。在设计时应该力求做到高内聚。在面向对象设计中存在3种内聚：
（1）服务内聚。一个服务应该完成一个且仅完成一个功能。
（2）类内聚。设计类的原则是，一个类应该只有一个用途，它的属性和服务应该是高内聚的，类的属性和服务应该全都是完成该类对象的任务所必需的，其中不包括无用的属性或服务。如果某个类有多个用途，通常应该把它分解成多个专用的类。
（3）一般特殊内聚。设计出的一般特殊结构，应该符合多数人的概念，这种结构应该是对相应的领域知识的正确抽取。
紧密的继承耦合与高度的一般特殊内聚是一致的。
1.6 可重用性
软件重用是提高软件开发生产率和目标系统质量的重要途径。重用基本上从设计阶段开始。重用有两方面的含义：尽量使用已有的类；如果确实需要创建新类，则在设计这些新类的协议时，应该考虑将来的可重复使用性。
2 启发规则
人们使用面向对象方法学开发软件历史虽然不长，但也积累了一些经验。总结这些经验得出了几条启发规则，它们往往能帮助软件开发人员提高面向对象设计的质量。
2.1 设计结果应该清晰易懂
使设计结构清晰、易读、易懂，是提高软件可维护性和可重用性的重要措施。保证设计结果清晰易懂的主要因素如下：
（1）用词一致。名字与它所代表的事物一致，应该尽量使用人们习惯的名字。
（2）使用已有的协议。如果开发同一软件的其他设计人员已经建立了类的协议，应该使用这些已有的协议。
（3）减少消息模式数目。如果已有标准的消息协议，设计人员应该遵循这些协议。如果确需自己建立消息协议，应该尽量减少消息模式的数目，只要可能，就使消息具有一致的模式。
（4）避免模糊的定义。一个类的用途应该是有限的，而且应该从类名可以较容易的推想它的用途。
2.2 一般一特殊结构的深度应适当
应该使类等级中包含的层次数适当。在一个中等规模的系统中，类等级层次数应保持为7-2到7+2范围内。不应该仅仅从方便编码的角度出发随意创建派生类，应该使一般特殊结构与领域知识或常识保持一致。 2.3 设计简单的类
尽量设计小而简单的类，以便于开发和管理。当类很大的时候，要记住它的所有服务是非常困难的。如果一个类的定义不超过一页纸，则使用这个类是比较容易的。为使类保持简单，应该注意以下几点。
（1）避免包含过多的属性。属性过多通常表明这个类过分复杂，它所完成的功能可能太多了。
（2）有明确的定义。为了使类的定义明确，分配给每个类的任务应该简单，最好能用一两个简单语句描述它的任务。
（3）尽量简化对象之间的合作关系。如果需要多个对象协同配合才能做好一件事，则破坏了类的简明性和清晰性。
（4）不要提供太多服务。一个类提供的服务过多，表明这个类过分复杂，一个类提供的服务不要超过7个。
在开发大型软件系统时，遵循上述启发规则也会带来另一个问题：设计出大量较小的类，这同样会带来一定复杂性。解决这个问题的办法，是把系统中的类按逻辑分组，也就是划分“主题”。
2.4 使用简单的协议
消息中的参数不要超过3个。经验表明，通过复杂消息相互关联的对象是紧耦合的，对一个对象的修改往往导致其他对象的修改。
2.5 使用简单的服务
面向对象设计出来的类中的服务通常都很小，一般只有3-5行源程序语句，可以用仅含一个动词和一个宾语的简单句子描述它的功能。如果一个服务中包含了过多的源程序语句，或语句嵌套层次太多，或使用了复杂的CASE语句，应该仔细检查这个服务，设法分解或简化它。应该尽量避免使用复杂的服务。如果需要在服务中使用CASE语句，通常应该考虑用一般特殊结构代替这个类的可能性。
2.6 把设计变动减至最小
设计的质量越高，设计结果保持不变的时间也越长。即使出现必须修改设计的情况，也应该使修改的范围尽可能小。在设计的早期阶段，变动较大，随着时间推移，设计方案日趋成熟，改动也越小。
3 结语
分析是提取和整理用户需求，建立问题域精确模型的过程。设计则是把分析得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。系统设计确定实现系统的策略和目标系统的高层结构，对象设计确定解空间中的类、关联、接口形式以及实现服务的算法。面向对象设计就是用面向对象观点建立求解域模型的过程。许多分析结果可以直接映射成设计结果，在设计过程中又会加深和补充对系统需求的理解，从而进一步完善分析结果。