插入墙：与外界的接口

需要明确的是，本文并不涉及与硬件的接口，尽管它确实适用于一点。

你以前听过

实际上，您可能已经听了很多：对接口进行编程，而不是对实现进行编程。 但是，您做起来的可能性远没有您想像的要好。

在项目中使用库时，是否将其接口用作接口？ 还是你设计自己的界面，与图书馆工作， 你要使用它的方法吗？ 如果没有，您将无法切换到功能更好的新库。 如果不是这样，您可能会被一大堆代码困扰，使代码库与逻辑代码混合在一起。

您的代码和所使用的框架之间是否存在抽象层？ 如果没有，您将需要很多工作才能更改为其他框架。 甚至直接与框架连接都是应该抽象化的实现细节。

这就是MVC最初的想法。 它将接口放置在三层中的每一层之间，以便于交换视图和模型变得容易（从技术上讲，您也可以交换控制器，但该控制器通常是介体并始终存在）。

在“ 清洁代码”中有两个地方提出了这个基本思想，“ 清洁代码”通常被认为是良好代码的权威。 最令人难忘的是下一部分的第一个案例研究。

实例探究

API尚不存在

在“干净代码”的第8章中，有一个部分称为“使用尚不存在的代码”。 Bob叔叔在其中描述了一个场景，其中他和他的同事正在为无线电通信系统编写软件。 在系统中，有一个尚未定义的子系统Transmitter，并且这些开发人员不想只是为了等待被定义而停止工作。

他们做了什么？ 他们解决了这个问题。 每当他们遇到了代码，将需要使用的发射机，他们只是以为他们是如何认为它应该被使用。 过了一会儿，他们找到了一个想要使用的好接口，并制造出了使用该接口的假发射机。

真正的发送器API进入后，他们只需将其用适配器（在Adapter Pattern中的 ss）包装到自己的接口即可，因此，旧代码中唯一需要更改的就是创建伪造的发送器并替换的代码。它带有使适配器成为真实事物的代码。

Fitnesse MVC

鲍勃·马丁（Bob Martin）也曾就如何使用MVC模式为各层之间的交互提供接口进行过一次演讲，并举例说明了团队何时进行Fitnesse开发。

他们最初说自己需要MySQL数据库，但有人开始说他们还不需要做出数据库决定。 所以他们没有。 相反，他们创建了模型接口，只是简单地将其最初保留在内存中。 他们在构建运行时不需要在运行之间保持持久性。

后来，他们确实开始需要它才能真正持久。 再一次，当有人说他们应该做平面文件来推迟数据库决策的时间时，他们几乎做出了数据库决策。 因此，他们编写了一个模型版本，该模型将自身存储在文件中而不是数据库中，同时保留了以前的接口。

实际上，当他们完成其他所有工作后，他们决定甚至不需要数据库支持，因此在没有数据库支持的情况下就将其交付。 他们最终添加它的唯一原因是Fitnessit的客户端需要使用MySQL数据库。 因此，他们可以快速轻松地添加支持。

我该怎么办？

每当您使用无法控制的代码时，都应通过为其制作适配器或Facade将其与实际代码分开。 该接口应使用的方式进行定义。

MVC框架提出了一个有趣的挑战。 我为您提供的一大建议是，不要将其控制器用作您的控制器，尤其是当其控制器使用注释和/或特定于框架的类型时。 这些控制器仅应充当您自己的控制器的视图适配器，因此它们的用途是将框架提供的内容转换为可以委派给您的控制器的内容。

您也应该为使用的库制作适配器和外观。 即使库具有您真正喜欢的接口，也应该创建自己的接口，即使它是完全相同的（您也可以删除从未使用过的API的一部分！）。 然后，如果最终换出了库，或者库进行了重大更新，则可以通过更新或制作新包装器将新库与旧接口一起使用。

好处

定义自己的边界接口的第一个好处是它们在您的控制之下。 这意味着您可以根据需要更改它们，以使使用它们的代码更清洁和/或更有效。

它还为您使用某些库的辅助方法提供了一个很好的实用场所。 您可以将功能放入包装器中，而不是编写充满静态方法的帮助器类，无论是接口的一部分是显式帮助器，还是由特定包装器私下实现的隐式帮助器。 无论哪种方式，它都不需要一个几乎没有帮助的帮助程序类，并将功能放在更有用的地方。

使用自己的界面还使您在开始使用组件时无法准备就绪。 这可能是由于等待实现准备就绪，或是由于您推迟决定使用哪个组件的决定。

它使用户代码更整洁（假设您使用的是干净的界面），您可以随意清理和重构该代码，因为您可以控制它所调用的接口。

它为更改提供了一个单一的地方。 需要我多说？

例外情况

大多数规则都有例外，该规则也不例外。 测试规则是该规则的一个例外，尽管不是必须的。 有机会的话，你会改变你的测试框架，但你可能不会。 如果您希望的话，请尝试从所有框架中提取要调用的通用名称，并将其放在单独的位置。 然后拥有实际遵循提取的代码的框架调用的代码。

如果您的公司一直使用某个框架或工具，那么您应该可以安全地假定它不会被关闭。 但是请记住，为了编写更简洁的代码而创建自己的界面的好处。 这仍然是创建自己的理由。

我们不是例外

如果您是使用某个框架或库设计应用程序的，而您突然需要切换到其他应用程序，或者该框架或库进行了重大更新（但是您需要此更新随附的新功能），则第一步应该是重构代码以使用新的界面（如果您制作一个看起来像该工具界面的界面，它将使转换更加容易！），以防止再次发生。 通常，这不仅会在以后保护您，而且实际上会使当前向新软件的过渡更加容易。

坦白的时间

我必须承认，我几乎没有做任何事情。 我已经听说过几次，但是在我有机会应用它之前，它已经从我的脑海中溜走了。 我正在制定一项决议，开始做更多事情，也许有一天我会告诉大家有关它对我的影响。 我希望它可以在许多地方编写一些更好的代码，但是要进行设置和启动将是繁琐的工作。

翻译自: https://www.javacodegeeks.com/2015/02/plug-wall-interfaces-outside-world.html