BadRegExpMatcher要求MailBot将输入文本由字符数组转换为一个String对象，从而导致了不必要的对象创建。然而，滑稽的是为了更方便地使用输入文本，BadRegExpMatcher会立即将String对象转换为一个字符数组，这样不但会生成另一个对象，还意味着你在费了九牛二虎之力得到的结果，跟调用程序最初提供的数据没有什么二样，MailBot和BadRegExpMatcher都不要求使用String对象，String对象似乎仅仅是为也在组件之间交换文本数据而存在的。
在上面的BadRegExpMatcher例子中，String仅仅是一种供交换用的类型，无论是调用程序还是被调用程序都不需要使用供交换用的数据类型来表示数据，但它们可以很方便地把它与其他的数据类型进行转换。尽管在定义接口时采用供交换用的数据类型可以在保持灵活性的前提下降低复杂性，但有时会带来性能上的损失。
供交换用数据类型的一个最常见的例子是JDBC ResultSet接口，没有一种数据库的接口会用JDBC ResultSet表示返回的结果，但JDBC驱动程序可以很方便地把数据库返回的结果转换为JDBC ResultSet型数据。同样，也没有一种客户端软件用DBC ResultSet型数据表示数据记录，但你也可以不费什么劲儿就将ResultSet型数据转换为所需要的数据类型。在JDBC中我们可以接受这种"多此一举"，因为它具有标准性和跨数据库的可移植性等好处。无论如何，由供交换用数据类型所带来的性能损失都是一个值得注意的问题。
在RegExpMatcher中，在定义接口时使用String对象对减少复杂性或增加可移植性的帮助并不大，对性能却有着相当大的影响，这么做是得不偿失的。在设计接口时使用可互换类型往往很有吸引力，因为这样能够使接口看起来更"干净"一些，但你应该确信你为此所作的折衷是明智的。有时━━就象RegExpMatcher那样，调用程序可以使用多种输入、输出格式，应该考虑如何能够更方便地满足它们的需求。
值得指出的是，对使用可互换类型对性能的影响进行量化不是一件容易的事儿。如果对调用BadRegExpMatcher的代码进行分析，它将指派运行时间库创建输入用的String对象，这个String对象是为满足BadRegExpMatcher的需求而生成的。如果要衡量一个组件对性能的真正影响，不仅需要评估代码的资源利用情况，还需要评估建立调用的代码以及调用返回的代码的资源利用情况，要使用标准的分析工具完成这些分析工作是非常困难的。
