为什么要隐藏类实现？

Question

我被这个概念困住了。

这是我在一个站点上看到的解释的一部分：

隐藏实现

我是这样想象的：

public void print(String message)
{
     System.out.println(message);
}

库客户机是否知道这个实现有什么区别？

Answer 1

实现并不是真的隐藏在视野之外。尤其是因为您将要使用的大多数库都是开源的。在本例中，“hidden”指的是不属于公共API的任何内容。库的公共API由库公开的公共方法和字段组成。一旦库发布了一个版本，它应该继续支持未来版本上的公共API。任何其他东西都被认为是隐藏的，并且该库的用户不能依赖该库的未来版本中存在的“隐藏代码”。

编辑：

但是，例如，如果代码不是隐藏的，客户机怎么可能依赖它呢？

public void doSomething(CharSequence x);

这是经常出现的，有很多方法可以绕过它。例如，当log4j升级到第2版时，它们的变化非常剧烈，以至于它们的API不得不中断，因此创建了一个称为log4j2的全新库。因此它是一个完全不同的库,包名不同。它不是旧图书馆的新版本，它是一个名称相似的新图书馆。

与此形成对比的是，看看Java SE的hashtable类。这是不应该再使用的旧类。但是Java有一个严格的规则，新版本中必须仍然支持以前版本的旧公共API。因此Java无法做到log4j所做的事情。

再比如Spring。Spring尝试遵循Java所做的方法，您只需要更新版本，旧代码就可以工作了。但Spring确实不推荐使用它的部分公共API。它将删除旧的类和方法，这些类和方法是公共的，但它真的不希望人们再使用它们。在这种情况下，我作为Spring的用户可能会发现很难从版本1升级到版本4。主要是因为某些公共API可能已被弃用。

因此，这里我给出了三种不同的图书馆作者解决这种情况的方法。

1）Side steps旧版本并创建一个全新的库。例如log4j。2）严格并始终支持旧的公共AIP。例如Java。
3)缓慢地不推荐旧的公共APIhtml" target="_blank">方法或类。例如Spring。

作为这些库的用户，我希望旧的公共API得到支持。这三个例子我都用过。我不得不在遗留代码上使用旧的hashtable类，我正在升级到Java8，很高兴它仍然受到支持。我已经感受到了从log4j1升级到log4j2的痛苦。我还在一个复杂的项目上升级了Spring，并产生了需要排除故障的不利影响。我可以告诉您，严格遵守旧的公共API对于所述库的用户来说是最容易的。