全部隐藏！

在较早的文章中，我写了以下几句话： 在面向对象的代码库中，该工具包应尽可能离散。 使用开发套件的次数越多，您的代码实际面向对象的次数就越少，或者您的抽象并不是最好的。 。

我认为有必要详细说明这一点，因为它很强，并且该文章并没有充分说明这一点。

我承认，这个想法很简单，尽管可能是理想主义的：在查看您的代码库时，我应该能够通过查看对象的实例化，观察它们如何构成和装饰每个实例来理解应用程序的功能和业务逻辑。其他。就像我在另一篇文章中所说的那样，您应该将业务逻辑隐藏在清晰的视野中。

基本上，这意味着我不需要为了了解您的程序应该在何时执行什么操作而去查看任何算法，Collection处理，任何类型的数据操作或对实用程序方法的调用。所有这些细节都应分解为最小的部分，并隐藏在接口实现的背后。换句话说，您的代码应尽可能具有声明性-请记住，命名是最重要的方面之一。

不用说，这种方法需要大量的设计工作，尤其是在架构师方面：我相信架构师应该做的第一件事就是设计对象的接口。理想情况下，他/她应该交付一个仅包含Java接口的框架项目，并附带详细的JavaDocs来解释最终对象应如何协同工作，以及可能的一些替代实现想法。然后，开发人员的工作就是提供实现并将所有内容放在一起，就像一个难题一样-我什至不提每个测试对象都应该完全覆盖每个对象。

缺点当然是，错误可能会花费更多的精力，可能花费在重新设计内容上。另一方面，这样的应用程序将小得多，并且永远不会变成庞然大物。只需简单地了解哪种方法适合哪里，您就不必问自己“我应该在哪里放置这种方法？” 或“我们是否应该在此服务中再添加一种方法？它已经很大了。” 新的东西应该无缝地或完全不适合，在这种情况下，您可以考虑编写新的应用程序（是的，为什么不呢？）。

此外，添加功能应该意味着只需实现一个接口，并且只有在该接口之后，您才可以考虑使用开发工具–也许还没有，这取决于抽象的深度。换一种说法，删除功能或逻辑应该意味着仅从某个位置删除对象的实例化或修饰，并且要注意，这不应在项目中留下任何未调用的方法。最坏的情况是，您应该有一个未使用的类！

综上所述，以上所有内容听起来可能很奇怪，但是您应该这样想：您始终确保从业务逻辑中抽象出View和Persistence层；为什么不更进一步，将JDK隐藏起来呢？我知道，您永远不必更改它，但是很明显，在没有完全抽象和封装的情况下使用它会将代码变成半OOP事物，这种事物只会继续增长并变形。最后，是的，让我们假设JDK（实际上更准确地说是Java SE）将消失：您构造的对象和测试将保持不变，您只需要使用手头的新工具包提供新的实现即可；这就是OOP的全部意义！