The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
对象通过它们的方法相互交流。在主流编程语言中，比如Java或C#，一个对象可以有一组独特的方法，还有一些它被强制拥有的方法，因为它实现了某些类型，也被称为接口。我与许多程序员的交流经验告诉我，我们大多数人对实现了太多接口方法的对象感到害怕。我们不想处理它们，因为它们是多态的，因此不可靠。这是一个合理的担忧。让我们试着分析它的来由。
像往常一样，让我们从一个简单的Java示例开始。这是我要通过PayPal API发送给用户的一笔金额。
现在我在这里，发送钱的方法是：
这两段代码是松耦合的，也就是说，send() 方法不知道提供的是哪个类，以及 cents() 方法是如何实现的。也许它是一个简单的一美元的常量对象。
或者它可能是一个更复杂的实体，首先建立网络连接，以获取当前美元对欧元的汇率，更新数据库，然后返回某些计算的结果。
方法 send() 并不知道它的第一个参数具体是什么。它能做的只是希望方法 cents() 能正确地完成工作。如果不能呢？
如果我是 send() 方法的开发者，并且我已经做好为方法产生的错误负责的准备，我确实想知道我的合作伙伴是谁。而且我希望确保他们的工作是完全可靠的。不仅仅是工作，而是按照我期望的方式工作。最好是我自己来编写它们。理想情况下，我希望在我实现它们之后没人碰它们。你明白我在讽刺什么了吧？
这听起来可能像个笑话，但我听过很多次这种论调。他们说：“与其依赖该死的多态性，然后花几个小时调试我没写的东西，不如完全确保两个部分能够完全配合。” 你知道吗，他们是对的。多态性——当一个看似原始的 Money 类型的对象可以做任何它想做的事情，包括进行 HTTP 请求和 SQL UPDATE 查询——这并没有为整个应用程序增加可靠性，对吗？
显然，多态使得开发者们在处理这种类型Money及其”祖先”时更加简单，因为他们不必过多考虑用户。他们只需要关心在调用cents()时如何返回double。他们不需要担心速度、潜在异常、内存使用等等许多其他事情，因为接口并不要求这些。接口只告诉他们返回double，然后就可以了。让别人去担心其他一切。很简单，对吧？但你可能会说，这是一种幼稚和自私的思维方式！
However…
您肯定听说过快速失败的理念，简而言之，它声称为了使应用程序健壮稳定，我们必须确保其组件尽可能脆弱，以及在面对任何潜在的异常情况时尽可能脆弱。它们必须在可能的情况下崩溃，并让用户处理故障。根据这样的理念，没有任何对象会对其对等对象有好感，并且始终会试图将问题升级到更高的层次，最终会影响到最终用户，他们会将问题反馈给团队。团队将修复所有问题，整个产品将稳定。
如果理念相反，每个对象都试图在其个体微观层面上处理问题，那么大多数异常情况将对用户、测试人员、架构师和程序员不可见，而这些人应该处理这些问题并找到解决方案。由于个体对象的“小心”心态，整个应用程序的稳定性和健壮性将受到影响。
我们可以将相同的逻辑应用于“松耦合的担忧”。
当我们担心Money.cents()如何工作并希望控制其行为时，我们对自己和整个项目造成了很大的伤害。从长远来看，我们破坏了产品的稳定性，而不是使其更加稳定。有些人甚至希望通过以下方式声明方法send()来禁止多态性：
在这里，我们限制了代码可能出现的错误数量，因为我们了解Bobby，我们看过他的代码，知道它是如何工作的，以及可以预期的异常情况。我们是安全的。是的，我们是。目前是这样。但是从战略角度来看，如果我们不允许软件在所有不寻常的情况下发生所有可能的错误并抛出所有可能的异常，我们会严重限制其进行适当测试的能力，这就是为什么它会变得不稳定。
正如我之前提到的，提高软件质量的唯一途径就是找出并修复其中的错误。我们修复的错误越多，剩下的隐藏错误和尚未修复的错误就越少。对错误的恐惧和我们预防错误的意图只会给我们带来麻烦。
相反，我们应该让每个人，不仅仅是Bobby，实现Money并将这些实现传递给send()。是的，其中一些可能会带来麻烦，甚至可能导致用户界面可见的故障。但是，如果我们的管理层正确理解软件质量的概念，他们不会因为错误而责怪我们。相反，他们会鼓励我们尽可能多地发现错误，使用自动化测试进行复现，修复并重新部署。
因此，对解耦的恐惧只不过是一种故障安全机制。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-18 at 05:29
