程序员应知必会的思维模型之 16 隐式接口定律 (Hyrum‘s Law or The Law of Implicit Interfaces)

隐式接口定律 (Hyrum’s Law or The Law of Implicit Interfaces)

当 API 有足够多的用户时，你在合约中的承诺已不重要：你系统的所有可观察行为都将被某些人所依赖。–海伦·赖特 (Hyrum Wright)

隐式接口定律表明，当你的 API 有足够多的用户时，API 的所有行为（包括那些未囊括在公共说明中的一部分）最终都会被其他人所依赖。 一个简单的例子是 API 的响应时间这种非功能性因素，还有一个更微妙的例子是：用户使用正则表达式判断错误信息的类型时，即使 API 的公共说明没有说明消息的内容，来指示用户错误的类型，一些用户也可能会使用并更改该消息，而这实际上会破坏 API 的使用。

---

历史

在过去几年中，在地球上最复杂的软件系统之一中进行低级基础结构迁移时，我们对接口及其实现之间的差异进行了一些观察。我们通常将接口视为与系统（如汽车中的方向盘和踏板）进行交互的抽象，而将实现方式视为系统完成其工作的方式（车轮和引擎）。出于多种原因，这很有用，其中最重要的原因是，最有用的系统迅速变得过于复杂，以至于单个人或团体无法完全理解，而抽象对于管理这种复杂性至关重要。

定义正确的抽象级别是一个完全独立的讨论（请参见“神话人月”），但是我们希望认为一旦定义了抽象，它就是具体的。换句话说，从理论上说，接口应该在系统的使用者与其实现者之间提供清晰的分隔。在实践中，随着系统使用量的增加，这种理论被打破，其用户开始依赖通过接口有意公开的实现细节，或者他们通过常规使用而变得神圣。Spolsky的“泄漏抽象法”体现了消费者对内部实现细节的依赖。

从逻辑上讲，这导致以下观察，俗称“隐式接口法则”：如果有足够的使用，就没有私有实现之类的东西。也就是说，如果一个接口有足够的使用者，那么它们将有意或无意地共同依赖于实现的各个方面。此效果用于约束对实现的更改，该更改现在必须既符合显式记录的接口，也必须符合用法捕获的隐式接口。我们通常将这种现象称为“ bug兼容bug”。

隐式接口的创建通常是逐渐进行的，并且接口使用方通常不会意识到这种情况的发生。例如，接口可能无法保证性能，但是消费者通常会期望其实现能够带来一定程度的性能。这些期望成为系统隐式接口的一部分，并且对系统的更改必须保持这些性能特征，才能继续为其使用者发挥作用。

并非所有使用者都依赖于相同的隐式接口，但是如果给定了足够的使用者，则隐式接口最终将与实现完全匹配。此时，接口已消失：实现已成为接口，对其所做的任何更改都将违反消费者的期望。幸运的是，广泛，全面和自动化的测试可以检测到这些新期望，但并不能改善它们。

隐式接口是大型系统的有机增长所致，尽管我们希望这个问题不存在，但设计人员和工程师在构建和维护复杂系统时应明智地考虑它。因此，请注意隐式接口是如何限制系统设计和发展的，并知道对于任何合理流行的系统，该接口的作用远比您想象的要深。

---

谁是Hyrum？

Hyrum是Google的一名软件工程师，致力于大型代码更改工具和基础架构。在此之前，Hyrum花了五年时间改进Google的核心C ++库。当即使是最简单的库更改也导致某些遥远的系统发生故障时，上述观察都是出于Hyrum经验。

尽管Hyrum可能已经观察到了，但值得称赞的是泰特斯·温特斯（Titus Winters），他实际上将其命名为“希律（Hyrum）定律”，并更广泛地推广了该概念。

---

观点

• Hyrum定律-我们的痛苦现在有了名字！

• 有时会感觉到所有变化都在打破变化

• Hyrum定律 是它的一种表述。有一个原因，即使-release返回void，通过-[NSObject release]的某些路径也会使返回寄存器归零。

• 主要是在我的博客上工作。使用带有Markdown的真正简单的GatsbyJS设置进行输入，并将其部署到github页面。没什么复杂的。从Google的《软件工程》一书中了解了Hyrum定律。

---

加入我们共同进步

群名称：程序员思维模型
群 号：144079203
​​​教程网站：www.swiftuigit.com