我的意思是，如果我在 Java 中声明任何访问修饰符，则可以绕过该修饰符（包私有和受保护 - 包注入；任何 - 反射）。我知道声明这些东西有助于理解和组织代码，但除此之外，是否有任何技术原因或固有的 Java 功能？
感谢你们的精彩回复。我很遗憾我只能将一个答案标记为已接受。
【问题讨论】：
标签： java access-modifiers
是的，它们可以被规避。您指出的依赖注入示例实际上是一个有用的规避案例。注入私有成员不会污染接口，也不容易在运行时混淆。但是，要了解核心优势，请将其想象为您是一名软件架构师，领导着一个非常懒惰或缺乏经验的团队。
请记住，良好分解的对象应该具有高内聚性和松散耦合。高内聚意味着一个对象处理它在语义上要处理的关注点，不多也不少。松散耦合意味着对象依赖于接口而不是特定的实现。请记住，这样做的好处是它使您的代码更易于阅读、理解、测试和更改。这降低了成本，并且总体上使利益相关者感到高兴。作为一名建筑师，这就是你所关心的。假设的懒惰/缺乏经验的团队只关心立即完成队列中的任何任务，即使以牺牲质量和未来生产力为代价。
访问修饰符显示了为对象定义的接口背后的一些意图。通常，如果您正在编写结构良好的代码，您几乎总是只需要 public 和 private 修饰符。在极少数情况下，关注点无法轻松/清晰地分离为单个内聚对象，还有“受保护”关键字，允许从逻辑上共享相关关注点的对象进行有限的外部访问。
design by contract 是一种更好但可以说更麻烦的表达接口意图的方式，它使用一组更强大的接口注释来允许预处理工具强制执行接口规则。
访问修饰符的编译器执行非常棒。编译器为那些很乐意减少内聚和增加代码库耦合的人设置了一个很好的不便障碍，以便更快地完成他们的直接任务。
【讨论】：
我会说是的，因为它们可以防止无意的误用。你真的必须竭尽全力绕过限制，你不能盲目这样做。
此外，它们表明了内部与外部/API 的意图。如果您作为用户无视这一点，那么您承认您对未来的问题持开放态度。
【讨论】：
一个重要的原因（也是我认为最重要的一个）是它使您能够更好地推理您的代码。
作为一个类的作者，你必须假设你的访问修饰符不会被绕过。这使您可以在调用方法之前对对象的状态做出更好的假设。您知道从哪里调用private 方法以及对象处于什么状态。您不能对public 方法做出相同的假设。
一个例子可能是 private 方法可以访问多线程上下文中的某些共享状态，并且知道它是从另一个持有共享状态锁的方法调用的，而 public 方法在访问共享资源之前可能需要获取锁。
【讨论】：
该修饰符可以被规避（包私有和受保护 - 包注入；任何 - 反射）。
如果您使用安全管理器和已签名的 JAR 运行，那么这些都不可能。因此，访问修饰符实际上可以用作受控环境中的安全机制。
但是，在绝大多数情况下，它们的目的确实是代码组织（我不认为可读性是正确的词）。
【讨论】：
作为一个不同的答案，我认为它们在编写 API 时很重要，因为它们定义了您与 API 消费者之间的公共合同。你可以绕过它们，是的，但它清楚地表明了实际支持的内容。
【讨论】：
私有/受保护有助于使代码更安全并防止紧密耦合，从而促进重用，降低维护成本。我可以坚持一整天！
【讨论】：