Preserving Prefix Integrity

前缀（prefix）的目的是给组件或者全局逻辑结构（global logical construct）的定义的物理位置（physical location）提供一个分层的标识（hierarchical identification）。设计良好、功能内聚的包的包前缀提供了语义和物理信息。不应该仅仅关注前缀标识的语义属性，前缀更主要的目标是强迫拥有相似前缀逻辑上内聚的功能被打包到同一个库中。

理想情况下，一个包前缀不仅表示了定义组件和类的物理库， 还暗含着内聚的逻辑特征和组织特征。

有时候我们很想把逻辑上相关的单元分布到多个物理库中，并给这些逻辑单元使用共同的包前缀。举个例子，有一个包（pub）提供一组底层，可重用的容器类型。这个包中的每一个组件和每一个类型都以前缀pub_开头。现在假设我们开发我们自己的应用程序包（xr2e），并且发现我们需要一个新的类型，Btree，碰巧这个新类型和pub包中的类型的特征相似（底层，容器，可重用）。我们该怎么办？

我们可能会给这个组件取名pub_btree并且把它放到我们自己的库以表明它和pub包的逻辑关系。这种做法不好。给定一个包前缀的所有组件处于同一个物理库中，对于理解和管理大型系统来说非常宝贵，一定不能牺牲掉。

我们还有两个可行的替代方案，都有各自的优点：

1. 取名叫xr2e_Btree并放到我们自己的包中。
2. 取名叫pub_Btree并放到pub包中。

可能给这个类取名为xr2e_Btree，并把它定义为我们自己的包中的一个组件是最简单的。局部的实现这个对象减少了重用的可能性，这是好事也是坏事。把Btree定义在同一个包中，我们保留了所有权，因此不用操心它的变化或者加强（这如果能满足我们的需求的话）。

可重用性并不总是从一开始就那么明显。我们觉得其他人并不需要Btree类型，所以我们就自己写自己用。如果其他人也是这种想法，而btree事实上却是是可重用的，我们可能会突然发现在我们的系统中出现了若干个Btree的冗余版本。如果我们看到三个或者更多的btree组件的相似版本出现在我们的系统中，那这个组件就是一个重用的候选者。此时，我们应该评估一下，通过把一个单一的，统一的版本的Btree移到公用的pub包中（并把前缀改为pub_），能对巩固我们的系统带来多大的好处。

经常我们觉得一个组件是可重用的，而最后却发现其他人并不需要这个组件。把这样一个重负放到高度可重用的包中比推迟把可重用组件放到pub包更糟糕。让更多的功能公共化比让更少的功能公共化更简单。如果有疑问，最好是推迟把一个组件加入到一个广泛使用的包中，除非有证据证明这个组件的重用性。