静态类型面向对象语言组件集成问题与解决思路

# 静态类型面向对象语言组件集成问题与解决思路 ## 1. 工厂对象集成问题 在某些场景下，工厂对象的使用会引发集成问题。例如在高库（High library）中存在冲突，导致其返回 `HighSubA` 对象。这就产生了一系列问题，比如新的 `makeSubA` 条目该如何定义。高库期望的是 `HighSubA` 对象，但我们需要 `NewSubA` 对象，这样这些对象才能拥有 `Printable` 接口。然而，我们可能并不知晓 `HighSubA` 类型，因为它可能是高库不想暴露的私有类型，即便知道也可能无法使用，因为它可能会给我们的类型层次结构引入冲突，比如它可能定义了一个签名不兼容的 `print` 方法。 总体而言，使用多个替换低库（Low's factory）工厂对象的组件会很困难，因为可能不存在能同时满足所有组件“替换类型”需求的工厂对象。而且，对工厂对象的更改顺序必须仔细协调，以免某个组件覆盖了其他组件之前所做的更改。也就是说，虽然工厂对象能解决一些简单问题，但扩展性不佳。 ## 2. 多方法（Multimethods）的应用与局限 多方法（也称为泛型方法）在静态类型语言中相对较新。使用多方法时，消息查找可能涉及所有参数，而不只是接收者。由于多方法基于多个参数进行调度，它们并不“包含”在单个类中，因此在某种程度上独立于类或类型层次结构。我们可以利用这种独立性在不改变组件本身的情况下修改组件。例如，通过为 `BaseB` 类型的参数定义专门的 `print` 方法，我们实际上为 `BaseB` 添加了一个 `print` 方法。再为 `BaseC` 参数定义一个额外的 `print` 方法，就可以为所有组件对象实现一个多方法 `print`，从而在不引入新的 `Printable` 类型的情况下解决问题。 然而，为了避免引入 `Printable` 类型，我们需要付出很大代价。因为各种组件对象仍然没有共同的超类型，对于每个在概念上接受 `Printable` 类型参数的方法，我们需要编写三个版本——一个针对 `BaseA` 对象，一个针对 `BaseB`，一个针对 `BaseC`。也就是说，原本只需编写一个方法，现在却要编写三个。更糟糕的是，如果要编写一个接受两个 `Printable` 类型参数的方法，我们必须实现九个方法，即可能的实际参数类型的笛卡尔积中的每一对都需要一个方法。除了代码重复问题，使用多方法的解决方案的可读性也不如我们期望的那样好，因为 `Printable` 抽象在程序中没有被具体化，这使得理解生成的代码变得更加困难。 如果能够创建并命名由其他类型或类组成的集合类型，并针对类型（而非类）专门化多方法，就可以避免多方法的组合爆炸问题。例如，我们可以将 `Printable` 类型创建为包含 `BaseA`、`BaseB` 和 `BaseC` 的集合，并针对该类型专门化 `print` 多方法。但目前我们尚未发现有语言允许基于类型调度多方法。 此外，如果底层语言允许密封类型，多方法也无法解决我们的问题。密封类不能被子类化，密封类型也不能进一步专门化。密封会阻止程序员为密封类或类型创建新的泛型方法。密封主要是出于实现原因而提出的，以允许编译器生成更好的代码，同时也是一种软件工程机制，用于防止“内部”类被子类化。 ## 3. 传统重用机制的不足 研究发现，即使是非常简单的示例也会产生集成问题，而当前静态类型面向对象语言中的语言机制难以轻易解决这些问题。传统的重用机制，如组合和子类型化，在这种场景下表现不佳。 ### 3.1 组合（包装器方法） 组合（包装器方法）需要大量额外的代码，并且可能导致潜在的严重性能问题。 ### 3.2 子类型化 子类型化，无论是隐式还是显式的，都只能提供部分解决方案。 ### 3.3 多方法 多方法会引入代码重复问题。 综上所述，当前静态类型面向对象语言似乎不太支持独立开发组件的重用。 ## 4. 对结果的不同解读 这个研究结果可能会有以下几种（错误）解读： ### 4.1 组件标准化才能实现广泛重用 有人认为“只有当所有组件都标准化，不出现集成问题时，广泛重用才有可能”。但这种结论相当于认为广泛重用是不可能的。在不久的将来，将数千个组件完全集成到一个连贯的框架中似乎不太现实。软件组件的标准化有时会与建筑行业的组件标准化或高保真组件之间的标准化接口相比较，但这种类比是有缺陷的，因为这些接口简单、自包含且“扁平”，而软件接口则更加复杂、相互关联且“深入”。例如，一个软件组件即使提供了正确的“扁平”接口，但如果嵌入到“错误”的类型层次结构中，也可能无法使用。当然，这并不意味着标准化尝试是徒劳或不可取的，但这些尝试可能会很耗时，并且只能消除部分（而非全部）集成问题。如果要实现软件的广泛重用，我们必须