很多东西都可以和平共处。巧克力和花生就是这样一个很好的例子，如果您相信Reece的产品的话。但是，我们都知道油和水就不相容。在我们用心创建复杂的大型应用程序时，开发人员必须非常努力才能够找到那些能够在一起和谐工作的东西，避免不兼容的情况出现。随着开发小组变得越来越大，让每个开发人员的想法都保持一致，把精力放在相同的设计方法上变得越来越难。但是，没有必要这么做。

下面的例子说明了为什么设计方法会不兼容，以及如何建立一个通用的设计方法。

继承还是不继承，这是一个问题

面向对象的开发有一个基本的设计方法，那就是继承。这也就是说，我可以说想要一个基类的所有属性和行为，但是我想对它进行扩展，以支持我自己的思路。并不是每一个应用程序框架都支持面向对象的继承。有的时候是因为底层组件不支持集成，而其他的时候是因为对集成方案进行测试是一项难以完成的挑战。

当然这不像它第一眼看上去的那么难处理。只需要用一个封装方法把它与API集成到一起就行了。利用封装思路，具备各种功能的对象就被作为一个成员变量包装在一个新的类里，它的属性和方法通过您的新类一个接一个地公开。虽然这很乏味，而且不允许基类的新特性通过，但是这是使用不支持继承的API的一种有效的思路。

反过来，有的API要求您创建的类必须是原有类的子类。这是因为基类的基础结构要被用在解决方案的基础结构代码里。所获得的类必须能够让基础结构来管理您的新类。这种设计方法从根本上与面向对象的基础是一致的。

上面这些思路都是正确的。但是这些方法的一致性都不足，对一个类使用一种API对另外一种API造成灾难性的后果。

关系型数据和多值字段

关系型数据库以极其高效的方式将相关的信息放到多个表格里。每个表格都有一系列行，每一行里都有一系列的字段。关系型数据库引擎所使用的索引机制会利用某个字段里的值快速地寻找到指定的记录或者一组记录。

关系型数据库会处理很多情况，比如可能会有零个或者很多个完整的信息行与第一行建立关系，方法是把它放在一个单独的表格里，并通过在第一个和第二个表格之间设置一个键值来建立联系。例如，一个数据表格可以代表人员，第二个表格可以包括汽车。每个人可能拥有一辆以上的汽车。在这种情况下，汽车表格里的行可以有一个指明所有人的字段。

这种关系能够很好地用于多种类型的问题，例如指定的人有多少辆车，某一个人拥有的汽车最多是多少辆，以及谁有车等等。

将人的身份与汽车表格里的汽车进行关联的另外一种思路是在人表格里加入一个字段，其中含有与汽车记录对应的人的身份列表。这个字段叫做多值字段，因为它可以包含多个值，所以这就有可能维持一个纯粹的汽车记录，而不用对人员记录进行参考，但是这样做的代价太高，让一个简单的问题变复杂了。

关于指定的汽车属于谁的问题变困难了，因为在汽车和人之间没有明显的能够用于查询的连接键。从技术上让关系型数据库的引擎对人员表格的汽车字段进行模式匹配是有可能的。但是，这样做肯定会造成需要对表格进行扫描——这一操作就无法利用索引的优势，从资源利用的角度上讲开销也过大。

关系型数据库本身在设计上并不擅长处理多值字段。所以试图在一个数据库里使用多值字段会有很大的困难。关系型数据库和多值字段是不兼容的设计思路。如果想要使用多值字段，那么另外一种类型的数据库可能要比传统的关系型数据库更加合适。

工厂和枚举

另外一种比较复杂的设计情形是抽象工厂模型的实现——这种模型允许根据配置创建任何对象。这完全就是一种十分灵活的模型，在创建具有可扩展性的解决方案时这是一种强大的武器。

创建工厂时的一个常见错误是使用枚举来控制工厂实际创建什么样的对象。这是一个错误，因为它使用了一种非常灵活的解决方案，因此能够被轻易地修改以支持新的功能，并将它集成到一个要求重新编译代码的方式。其结果是工厂本来具有的可扩展性被枚举绑住了手脚。一种更好的思路是使用一种基于标识符的配置，以明确创建什么样的内容。通过在运行期间的配置而不是编译期间的枚举来查看对象类型，您可以很好地保留工厂设计模式的灵活性。

基本的设计思想是不兼容的。工厂是自由灵活、可扩展的。而枚举则是对值的半刚性定义。

编程就像建立理论

因“Backus-NaurForm”语言句法概念而闻名的PeterNaur在1985年写了一篇题为《编程就像建立理论（ProgrammingasTheoryBuilding）》的文章。这篇文章的一个基本思想就是大多数人都相信编程更像是在建立一种理论。换句话说，编程是对系统应该如何工作的思维模型的发展。不同开发人员的理论基础越一致，编出来的应用程序的一致性就越高，应用程序的总成本就越低。

如果Peter的思想从根本上讲是正确的，那么在同一个应用程序里存在不兼容或者完全对立的设计会让这个程序的开发很难进行。如果您必须按照一种理论开发某个子系统的操作，然后又必须在另一个子系统上应用完全不同的理论，那么这显然会极大地增加系统的复杂性。

您的目标应该是尽可能地去除设计中不兼容的地方，如果没有办法完全消除不一致，至少应该清楚地标示出来并进行文档说明，这样才能让人知道这些地方需要更改理论。

寻找一致性

解决设计思想中不兼容的问题没有很容易的办法。但是，如果想要开发可维护的系统，这是绝对需要解决的问题。一般来说，您必须进行一些重要的工作来解决兼容性的问题。然而，虽然您需要付出努力，但是这些解决办法一般也不是那么困难找到的。有的时候，这只不过意味着将一种设计思想与另外一种设计思想靠近，以达到兼容的目的。

例如，如果您有一些密封类，它们无法从其他的地方衍生出来，在解决方案里还有其他一些类，它们又必须从其他的地方衍生出来——您可以花点时间和精力来确保密封类可以通过继承获得（也就是说非密封的）。

更加复杂一点的（解决方案）是增加一些必要的代码把多值字段转换成一个查询或者跨引用的表格。这也就是说要再创建一个表格，并更新应用程序里任何相关的代码以便能够处理它，但是，通过属性来模拟对多值字段的操作也是可能的，这样整个系统就不必再更改那些需要通过跨表格才能够完成的地方。

类似的，您可以把枚举的内部表示替换成为一个整数（枚举的基础类型），然后在您必须知道如何实例化特定类的时候把枚举交给整数。实现一致性并不总是一帆风顺的。但是，它会创造一个从存在设计冲突的模式转到一个更加兼容的模式的机会，这样开发人员就能够理解和适应那些原本他们令手足无措、困惑万分、相互矛盾的模式了。(Builder.com.cn)