很多东西都可以和平共处。巧克力和花生就是这样一个很好的例子，如果您相信Reece的产品的话。但是，我们都知道油和水就不相容。在我们用心创建复杂的大型应用程序时，开发人员必须非常努力才能够找到那些能够在一起和谐工作的东西，避免不兼容的情况出现。随着开发小组变得越来越大，让每个开发人员的想法都保持一致，把精力放在相同的设计方法上变得越来越难。但是，没有必要这么做。
下面的例子说明了为什么设计方法会不兼容，以及如何建立一个通用的设计方法。
继承还是不继承，这是一个问题
面向对象的开发有一个基本的设计方法，那就是继承。这也就是说，我可以说想要一个基类的所有属性和行为，但是我想对它进行扩展，以支持我自己的思路。并不是每一个应用程序框架都支持面向对象的继承。有的时候是因为底层组件不支持集成，而其他的时候是因为对集成方案进行测试是一项难以完成的挑战。
当然这不像它第一眼看上去的那么难处理。只需要用一个封装方法把它与API集成到一起就行了。利用封装思路，具备各种功能的对象就被作为一个成员变量包装在一个新的类里，它的属性和方法通过您的新类一个接一个地公开。虽然这很乏味，而且不允许基类的新特性通过，但是这是使用不支持继承的API的一种有效的思路。
反过来，有的API要求您创建的类必须是原有类的子类。这是因为基类的基础结构要被用在解决方案的基础结构代码里。所获得的类必须能够让基础结构来管理您的新类。这种设计方法从根本上与面向对象的基础是一致的。
上面这些思路都是正确的。但是这些方法的一致性都不足，对一个类使用一种API对另外一种API造成灾难性的后果。
关系型数据和多值字段
关系型数据库以极其高效的方式将相关的信息放到多个表格里。每个表格都有一系列行，每一行里都有一系列的字段。关系型数据库引擎所使用的索引机制会利用某个字段里的值快速地寻找到指定的记录或者一组记录。
关系型数据库会处理很多情况，比如可能会有零个或者很多个完整的信息行与第一行建立关系，方法是把它放在一个单独的表格里，并通过在第一个和第二个表格之间设置一个键值来建立联系。例如，一个数据表格可以代表人员，第二个表格可以包括汽车。每个人可能拥有一辆以上的汽车。在这种情况下，汽车表格里的行可以有一个指明所有人的字段。
这种关系能够很好地用于多种类型的问题，例如指定的人有多少辆车，某一个人拥有的汽车最多是多少辆，以及谁有车等等。
将人的身份与汽车表格里的汽车进行关联的另外一种思路是在人表格里加入一个字段，其中含有与汽车记录对应的人的身份列表。这个字段叫做多值字段，因为它可以包含多个值，所以这就有可能维持一个纯粹的汽车记录，而不用对人员记录进行参考，但是这样做的代价太高，让一个简单的问题变复杂了。
关于指定的汽车属于谁的问题变困难了，因为在汽车和人之间没有明显的能够用于查询的连接键。从技术上让关系型数据库的引擎对人员表格的汽车字段进行模式匹配是有可能的。但是，这样做肯定会造成需要对表格进行扫描——这一操作就无法利用索引的优势，从资源利用的角度上讲开销也过大。
关系型数据库本身在设计上并不擅长处理多值字段。所以试图在一个数据库里使用多值字段会有很大的困难。关系型数据库和多值字段是不兼容的设计思路。如果想要使用多值字段，那么另外一种类型的数据库可能要比传统的关系型数据库更加合适。
