逻辑设计问题 -- 构建一个组件

本文主要是介绍逻辑设计问题 -- 构建一个组件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

构建一个组件
- 抽象和组件
- 组件的接口设计
- 封装程度
- 辅助实现类
- 小结

构建一个组件

抽象和组件

抽象是完成一个共同目的的一组对象和相关行为的抽象规范

一个类是一个ADT（抽象数据类型）的具体规范，一个组件是一个抽象的具体规范

组件的接口设计

设计良好的组件接口在质量上包括几个方面。最低要求是，接口必须足以使预期的客户能有效利用设计该组件来支持的抽象。考虑一个实现集合抽象的组件。以下能力：

确定集合中的成员关系
在集合成员上进行迭代
从集合中删除一个指定的成员

对任意客户而言可能使必要的也可能不是必要的。然而，如果没有像集合增加成员的附加能力，那么这个组件对任何人几乎都是无用的

私有接口应该是充分的
公共接口应该是完整的
类的接口应该是基本的
组件接口应该是最小化的和便于使用的

在任何可行的地方，延缓不必要的功能的实现可以降低开发和维护成本，并且可以避免过早地进行精确的接口和行为设计

如果有效实现定义在一个对象上的操作意味着可以直接访问该对象的私有部分，那么该操作使基本的

让功能保持在一个可行的最小范围内可以增强可用性和可重用性

在一个组件接口中尽可能少地使用外部定义类型，可以促进在更多情况下的重用

封装程度

对封装进行的好的测试，是要看一个给定的接口是否不需要做任何改变即可同时支持两种显著不同的实现策略

一个完全封装的接口可能会为给定的实现带来很大的性能负担

传递进一个过去构造对象的地址以赋给返回值，能在保持整体封装性的同时提高性能。

接受不太完全的封装有时是正确的

辅助实现类

通常一个组件会在其实现中使用一个或者多个小的辅助类，他们在组件中定义的接口中是不能编程访问的。辅助类有两个区别于其他类的特征：

设计辅助类是为了实现一个组件的单一目的，并且不让它在该组件外直接使用
辅助类很小，并且可能不必直接测试

小结

组件在逻辑设计和物理设计中都是有效的单元。一个抽象是与对象和运算符函数紧密相关的一种抽象规范：一个组件（接口和实现）是相应的具体实现。

当为一个组件建立高层次规范的时候，要考虑几个相互矛盾的方面。对于被设计为特定子系统的一部分的组件，我们要求其接口对于所预期的客户来说是充分的就可以了。对于在整个大系统中会用于各种目的的组件来说，我们希望接口是完备的。充分性指的是，该接口对于解决某个领域的问题的特定实例来说是合适的。完备性是指，该接口对于解决某个领域的任意一个维妮塔。通过将所有组件接口都保持最小，可以加强可用性和可维护性。

被定义为单个对象的成员的操作应该是基本的。如果一个操作的有效实现需要直接访问那个类的私有细节，那么这个操作是基本的。有用的但不是基本的操作应该根据基本函数在对象之外实现，并且不应该授予友元状态。

在一个组件的接口中使用的用户自定义类型，隐含了对该类型的强逻辑依赖。与物理耦合一样，逻辑耦合最好也要最小化。例如，为了避免不必要的逻辑耦合，应经常选择是哟个一个const char * 参数而不是使用某个特殊的string类，尤其是当接口将在许多不同的上下文中被客户使用的时候。

封装是一个对象的特性，它使得对象的实现被修改时候不会影响其逻辑接口。有时完全封装的代价是相当昂贵的。但是，与绝缘一样，为了使之有用，封装也不需要i绝对化。我们经常可以做出合理的假设：允许我们达到性能目标，并且仍然保留足够的封装以允许我们在合理的限制内继续修改实现。如果要求完全封装，那么通过传递进一个前构造好的对象作为可写参数以装载结果，而不是通过返回值来返回结果，有时候可以取得相当大的性能收益。对于管理内部动态内存的重量级对象来说，通过参数返回比通过值返回所获得的性能收益要显著得多。

当实现一个组件时，经常有必要创建一个或者多个辅助类。这些类通过定义在组件中的主对象的接口是不可访问的。这些类是组件的实现细节，并且它们都足够简单，可能不需要独立测试。下列策略已经被确定可以用于实现辅助类：