我已经在线阅读了一系列JUnit和Java的最佳实践，人们喜欢指出的一个重要方面是字段和方法应该是私有的，除非你真的需要让用户访问它们。类变量应该与getter和setter私有，并且应该公开的唯一方法应该是用户将直接调用的方法。
我的问题：当您拥有不具备任何用户的独立应用之类的东西时，这些规则有多严格必要？我目前正在开发一种可以在服务器上运行的东西，可能每月一次。应用程序使用的配置文件可以修改，但一旦运行，就没有真正的用户交互。我大多数都遵循最佳实践，但遇到了单元测试的问题。很多时候，我觉得我只是通过我的单元测试让事情变得恰到好处，而且如果方法或其他什么是公开的，甚至是保护的话，那就更容易了。
我知道封装将使得在幕后进行更改变得更加容易，而无需全部更改代码，但没有用户影响，这看起来有点脆弱。我只是让我现在的工作变得更加困难，这将为我节省时间。我也看到过这个网站上的所有答案都说如果你需要对一个私有方法进行单元测试，那么你做错了什么。但这取决于这些方法应该始终是私有的，这就是我所质疑的。
如果我知道没有人会使用该应用程序（从jar或API或其他任何方面调用它的方法）是否有任何保护措施的问题？甚至公开？如何保持私有领域，但每个方法都公开？ ＆＃34;正确＆＃34;之间的平衡在哪里？代码片段的可访问性和易用性？
答案 0 :(得分：2)
这不是必要的＆＃34;，但即使在＆＃34;小＆＃34;中也应用了良好设计和编码原则的标准。从长远来看，项目将对您有所帮助。
是的，编写好的软件需要纪律。语言是帮助您实现目标的工具。像任何工具一样，它们可能被滥用，并且在被滥用时可能是危险的。电动工具，如台锯，如果误用会非常危险，所以如果你关心自己的安全，你总是遵循正确的程序，即使它可能感觉有点不方便（或者你最终绰号＆＃34;粗短＆＃34 ）。
我认为它是关于小项目的，你想要偷工减料而且只需编写代码＆＃34;，坚持最佳实践是最重要的。你正在训练自己正确使用你的工具，所以当它真正重要时你会自动做正确的事。
还要考虑那些开始的项目＆＃34; small＆＃34;随着时间的推移，随着您不断添加增强功能和新功能，它会变得非常大。这是敏捷软件开发的本质。如果您从一开始就遵循最佳实践，那么随着项目的发展，您将更容易适应。
另一个因素是使用OOP原则是一种驯服复杂性的方法。如果你有一个定义良好的API，例如，只使用getter和setter，你可以根据自己的想法从实现中分离API。编写课程A后，在编写A的客户端时，说B，您只能考虑API。之后，当您需要增强A时，您可以轻松地告诉A的哪些部分会影响API，哪些部分纯粹是内部的。如果您没有使用封装，则必须扫描整个代码库，以查看对{{1}}的更改是否会破坏其他内容。
我是否将此应用于我写的所有内容？不，当然不。我不会在动态语言（Perl，AWK等）中使用简短的一次性脚本来做到这一点，但在编写Java时，我总是要写出好的＆＃34;代码，如果只是为了保持我的技能尖锐。
答案 1 :(得分：1)
只要您的代码编译并正确运行，通常就没有必要遵循任何规则。
然而，当项目开发/成熟时，代码风格“最佳实践”已被证明可以提高代码质量，尤其是随着时间的推移。将字段设为私有使您的代码对以后的更改更具弹性;如果你直接省略getters / setters和access字段，那么对字段的任何更改都会直接影响相关代码。虽然首先在getter / setter 中似乎没有任何优势，但优势在于未来：getter通过单一控制点强制任何使用该属性的代码，如果是与该字段相关的任何更改都有助于屏蔽字段的具体表示/位置和/或在需要时允许多态，而无需更改/检查所有现有的调用者。
最后，一个类暴露给其他类（用户）的表面（可访问的方法/字段）越少，您需要维护的越少。将公开的API减少到绝对最小值可以减少类之间的耦合，这在需要更改某些内容时也是一个优势。努力尽可能地隐藏每个对象的内部运作本身并不是一个目标，而是由它作为目标的优势。
答案 2 :(得分：0)
与往常一样，始终需要良好的平衡。但是如果有疑问，最好是在“源代码质量”实践方面进行错误/倾斜;而不是采取太多的捷径;因为你的“简单”问题中有许多不同的方面需要考虑：
// used for unit testing放在他们上面。我没有看到这种非正式做法出现的问题。请注意：这些方法只应用于测试用例。没有其他生产类可以称之为。