java - 为什么要隐藏类实现？

Question

我一直坚持这个概念。

这是我在网站上看到的解释的一部分:

Hiding the Implementation

A primary consideration in object-oriented design is separating the things that change from the things that stay the same.This is particularly important for libraries. Users (client programmers) of that library must be able to rely on the part they use, and know that they won't need to rewrite code if a new version of the library comes out. On the flip side, the library creator must have the freedom to make modifications and improvements with the certainty that the client code won't be affected by those changes.This can be achieved through convention. For example, the library programmer must agree to not remove existing methods when modifying a class in the library, since that would break the client programmer's code. The reverse situation is thornier, however. In the case of a field, how can the library creator know which fields have been accessed by client programmers? This is also true with methods that are only part of the implementation of a class, and not meant to be used directly by the client programmer. But what if the library creator wants to rip out an old implementation and put in a new one? Changing any of those members might break a client programmer's code. Thus the library creator is in a strait jacket and can't change anything.

但我无法想象这种情况会发生的真实情况。

有人可以向我展示现实生活中的实际例子吗？

这就是我的想象:

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

如果库客户端知道或不知道这个实现，会有什么区别？

Answer 1

该实现并没有真正隐藏在 View 之外。特别是因为您将使用的大多数库都是开源的。在这种情况下，“隐藏”指的是不属于公共(public) API 的任何内容。库的公共(public) API 由库公开的公共(public)方法和字段组成。一旦库发布了一个版本，它应该在未来的版本中继续支持公共(public) API。其他任何内容都被视为隐藏的，该库的用户不能依赖该库的 future 版本中存在的“隐藏代码”。

编辑:

But how could the client rely on code if it was not hidden, for example?

所以假设一个库提供了一个如下所示的方法

public void doSomething(CharSequence x);

这被认为不是隐藏的，因为它是公开的。作为该方法的用户，我希望它存在于该库的 future 版本中。所以我期望该方法的输入是 CharSequence 。如果该库的作者想将其更改为 String那么那就错了。他们不应该改变这一点CharSequence到 String因为之前版本的用户期待CharSequence并将其切换为 String当库的先前用户升级到新版本时，可能会产生负面后果。在这种情况下，代码可能无法编译。

所以基本上，如果它不是隐藏的(也称为公共(public) API 的一部分)，那么作者不应该对公共(public) API 进行任何可能导致该库的早期版本无法工作的更改。

这种情况经常出现，并且有很多方法可以解决它。例如，当 log4j升级到版本 2 后，他们的变化如此巨大，以至于他们的 API 不得不中断，因此创建了一个名为 log4j 2 的全新库。 。所以它是一个完全不同的库，具有不同的包名称。它不是旧库的新版本，而是具有相似名称的新库。

作为对比，请看一下 Java SE 的 HashTable类(class)。这是旧类，不应再使用。但Java有一个严格的规定，即新版本中仍必须支持以前版本的旧公共(public)API。那么Java不能做什么log4j做到了。

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

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

1) 绕过旧版本并创建一个全新的库。例如。 Log4j。2) 严格并始终支持旧的公共(public) AIP。例如。 Java。
3) 慢慢弃用旧的公共(public) API 方法或类。例如。 Spring 。

作为这些库的用户，我更希望支持旧的公共(public) API。我已经使用了所有这三个例子。我不得不与旧的HashTable一起工作我正在升级到 Java 8，很高兴它仍然受到支持。我从log4j感受到了升级的痛苦1 至 log4j 2 。我还在一个复杂的项目上升级了 Spring，并且产生了需要解决的不良影响。我可以告诉您，对于该库的用户来说，严格遵守旧的公共(public) API 是最容易的。