公共接口与发布接口

　　比尔：你在书中提到，曾经碰到过一个团队，所有成员都将自己的接口发布给其他成员，结果大家常常是苦不堪言。

　　马丁：是的。

　　比尔：我的直觉是，作为一个从头开发大型系统且人数众多的团队的管理者，首要任务是将系统分成几个主要的子系统，然后定义这些子系统的接口。这些接口在某种程度上就是对外发布的接口。

　　接口并不是不能被改变。相反，最初要经常改变接口，随着时间的推移，需要改动的地方越来越少。原因很简单，接口随着时间的推移而成熟。除 此以外，随着时间的推移，越来越多的代码绑定在这些接口上，并且开发者对接口越来越熟悉。当到达某个点的时候，你就会说，“好吧，这就是接口。我们往下走 吧。”

　　马丁：哦，你是这样做的吗？我认为你没必要这样做。

　　比尔：如果你要想发布一个接口的话，那么最终还是要把它定下来。

　　马丁：那么让我来问你，假如你有一个团队，为什么要在团队内部发布接口呢？我在 IEEE 的另一篇文章中谈到了公共接口和发布接口的区别：发布接口的调用代码不能被更改。对于某个公共方法来说，我可能会觉得它的名称没有很好的描述其完成的任 务，也就是说更换一个名字或许能更清楚的表达它的功能。假如我能找到所有调用该方法的代码，那我就可以也应当改变这个方法的名称，即使它是一个公共方法。 但对于发布的接口来说，我不能这么做。在那篇文章中，我举了一个三人团队的例子。而这个三人团队的问题就在于他们在不需要发布接口的时候发布了接口。

　　Sun 必须把他们的 API 发布出来。Sun 不可能去认定 List 是不是一个好名字，是否应该用 VariableArray 来取代。这不是他们想做就能做的。外面到处都是采用 List 这个名字的代码，而 Sun 无法改变这些。但是在另一方面，在一个开发团队中——哪怕团队的规模有20到30人——改变一个未作慎重选择的名字不应该是件困难的事情。你应该可以很容 易的改变这些名称，特别是借助于类似 InteriJ 或者Eclipse 这样的重构工具，你只需要轻点鼠标就能改变所有的调用代码。这根本就不是什么难事。

　　强代码所有权和弱代码所有权

　　比尔：在书中，你同时还提到了另外一件事：“你在公司中看到的这些都属于一种强代码所有权”。代码所有权是什么意思，强代码所有权有什么缺点？

　　马丁：我把代码所有权分为三类。在极限编程中用到的代码所有权有时称为集体代码所有权，有时也可以说“无代码所有权”。在这种所有权中，团队中任何人都不具有对代码的所有权。也就是说，任何成员可以在任意时间内改动系统中的任何代码。这就是极限编程采取的方式。

　　和这种所有权相对立的是强代码所有权。在强代码所有权中，严格区分我的代码和你的代码，我不能改动你的代码。当我想改动我的某个方法的名 字时，如果这个方法被你的代码所调用，那么我就必须先通知你，让你先把所有调用代码改过来，然后我才可以改动这个方法的名字。另一种办法就是，我得将这个 方法“过期化”（deprecation），然后完成后面一系列的步骤。实际上，在这种情况下，因为我绝对不能碰你的代码，因而你所用过的我的任何接口都 是发布的。

　　弱代码所有权则介于两者之间。弱代码所有权中，还是会区分代码的所有者，不同的是它允许开发者改动其他人的代码。开发者对自己的代码质量 仍然负有责任。如果我想要改变我的代码中某个方法的名称，改就好了。不过，假如我想将某个类的功能转赋到另一个类上，而这些代码的所有权属于你，那么至少 在这么做之前我应该让你知道。这一点是和集体代码所有权不同的。

　　不论是在弱代码所有权下，还是集体代码所有权下，都可以进行代码的重构。但是在强代码所有权下进行重构是个问题，因为你想做的许多重构根本就无法进行，比如，你不能去改动别人的调用代码。这就是强代码所有权下不适合做重构而弱代码所有权下可以做重构的原因。

　　比尔：所以问题不在于团队成员定义了各自的子系统的接口，而在于他们把这些接口看成是发布的接口。

　　马丁：就是这个问题——他们在团队内部发布接口。假如他们采用弱代码所有权的话，就不会有任何问题。