Java 中包私有类的优缺点?

我很少看到包私有类的使用.这是否有原因，例如，它有严重的缺点，它是多余的，或者只是我读得不够?是否有强有力的论据支持/反对其使用?

I seldom see the use of package-private class. Is there a reason for this, e.g., it has serious drawbacks, it is redundant, or simply I am not reading enough? Are there strong arguments for/against its usage?

如果在大多数情况下它真的没有用，为什么会默认它?

If it is really not useful in most cases, why would it be the default?

在现实世界中我们应该在什么情况下使用package-private?也就是说，它什么时候会变得不可替代?

In what situation should we use package-private in the real world? I.e., when would it become irreplaceable?

换句话说，默认 package-private 修饰符的主要优点和缺点是什么?

In other words, what are the major pros and cons of the default package-private modifier?

简短的回答是 - 这是一种稍微宽泛的私有形式.

The short answer is - it's a slightly wider form of private.

我假设您熟悉 public 和 private 之间的区别，以及为什么通常将方法和变量设为 private 如果它们仅在相关类的内部使用.

I'll assume that you're familiar with the distinction between public and private, and why it's generally good practice to make methods and variables private if they're going to be used solely internally to the class in question.

嗯，作为扩展 - 如果您正在考虑以模块化方式创建您的软件，您可能会考虑到您的模块的公共接口，其中将包含多个类他们之间的合作.在这种情况下，如果消费者要调用方法，则将方法设为 public 是非常有意义的；private 如果它们是类内部的；和 package private 如果它们用于在此模块中的类之间调用，即它是模块的实现细节(如公共调用者所见)但跨越多个类.

Well, as an extension to that - if you're thinking about creating your software in a modular way, you might think about a public interface to your module, which will have multiple classes inside it collaborating between themselves. In this context it makes perfect sense to make methods public if they're going to be called by consumers; private if they're internal to a class; and package private if they're used to call between classes in this module, i.e. it's an implementation detail of your module (as seen by public callers) but spans several classes.

这在实践中很少使用，因为包系统对这类事情不是那么有用.您必须将给定模块的所有类转储到完全相同的包中，这对于任何非平凡的事情都会变得有点笨拙.所以这个想法很棒——让一个方法只能被少数附近"的类访问，作为一个稍微宽一点的private——但是你如何定义这组类的限制意味着它很少使用/有用.

This is seldom used in practice, because the package system turns out to not be so useful for this sort of thing. You'd have to dump all of the classes for a given module into exactly the same package, which for anything non-trivial is going to get a bit unwieldy. So the idea is great - make a method accessible to just a handful of "nearby" classes, as a slightly wider private - but the restrictions on how you define that set of classes means it's rarely used/useful.