Question

阅读这篇java文本，作者建议考虑包org，只留下真正需要向世界其他地方公开的类。

我认为我认为有点暴露不需要的东西允许以后更改内容而不破坏客户端代码 - 但是，我不能想到一个例子 -

如果一个软件包说有几个实体或类，每个实体或类提供一组功能 - 那么面向公众的类是否必须协调与外部世界的所有通信？

任何示例或指导都将不胜感激!!!

Answer 1

除非您需要，否则基本上不会对客户端代码做出承诺。当你公开一个方法时，那么在某些情况下，至少你不承诺在没有与客户代码协调的情况下不改变它。

假设您将方法公开并且有人使用它。然后你意识到你需要改变方法。现在你有两个选择：

显然你想尽可能避免＃2。

对于小型系统，＃1可能不是什么大问题。但是，根据您的代码，您拥有更多客户端代码，＃1可能会成为问题。无论出于何种原因，某人可能还没准备好接受你的改变（时间表，业务原因，技术原因，等等）。

避免这种困境的一个好方法是避免做出承诺，除非有某些理由。即使在编程之外，这在生活中也很明智。但它也适用于编程：就可见性而言，这意味着更喜欢对公众可见度的有限可见性。

一个例子。说我正在编写电子商务订单管理库，我写了一个方法

public double computeTax(double price) { ... }

即使所有图书馆的税务计算都发生在图书馆内部。我只是把这个方法公之于众，因为我认为不与全世界分享我的税务计算器是一种耻辱。

许多人都同意这种方法很棒，并构建使用它的应用程序。

然后有人指出使用双打代表美元金额是完全错误的（浮点表示只是近似值，这对金钱没有好处）。我决定要完全摆脱旧的方法（不要让任何人使用根本错误的东西），并用

public Currency computeTax(Currency price) { ... }

但现在我要打破一堆使用原始方法的客户端代码。

如果我把我糟糕的税务计算器留给自己本来会更好，因为它不是图书馆真正提供的部分。现在我陷入了困境。

Answer 2

这是我遵循的原则。使类或方法甚至参数可见，以尽可能低的可见性。 Facade模式是暴露类的集合功能的好习惯。其他好的做法是使用object作为公共API的参数类型，然后将其内部转换为所需的类型，这样可以避免潜在的代码中断。