对API的足够数量的用户的软件工程观察，您在合同中承诺的许可证无关：您的系统所有可观察行为将被某人依赖。
在过去的几年中，在地球上最复杂的软件系统之一进行低级基础设施迁移，我对接口和实现之间的差异进行了一些观察。我们通常将界面视为与系统交互的抽象（如车辆中的方向盘和踏板），以及作为系统工作方式（轮子和发动机）的方式。这对于多种原因非常有用，最重要的是，最有用的系统对于单个个人或组来完全理解的最迅速变得过于复杂，并且抽象对于管理这种复杂性至关重要。
定义正确的抽象级别是一个完全独立的讨论（见神话月份），但我们希望考虑一旦定义抽象，它就是混凝土。换句话说，理论上，界面应该在系统及其实施者的消费者之间提供清晰的分离。在实践中，随着系统的使用增长和用户开始依赖于通过界面故意暴露的实施细节，或者通过定期使用它们的实施细节，这种理论突破。 Spolsky的“泄漏法则”体现了消费者对内部实施细节的依赖。
这导致其逻辑极端，这导致了以下观察，俗语称为“隐含接口的定律”：给予足够的使用，没有私人实施。也就是说，如果一个接口有足够的消费者，他们将统称，故意依赖于实现的各个方面。此效果用于将更改限制为实现，现在必须符合明确记录的界面，以及用用法捕获的隐式接口。我们经常将这种现象称为＆＃34;错误的错误兼容性。＆＃34;
隐式接口的创建通常逐渐发生，界面消费者通常不知道它正在发生。例如，接口可能无法对性能保证，但消费者通常会期望从其实现中实现一定程度的性能。这些期望成为系统隐式接口的一部分，对系统的更改必须维护这些性能特征以继续为其消费者运作。
并非所有消费者都依赖于相同的隐式接口，但给出足够的消费者，隐式接口最终将与实现完全相匹配。此时，界面已蒸发：实现已成为界面，并且对其的任何更改将违反消费者的预期。随着一些运气，广泛，全面，自动化测试可以检测这些新的期望，但不会改善它们。
隐式接口来自大型系统的有机生长，虽然我们可能希望问题不存在，但在构建和维护复杂系统时，设计人员和工程师将明智地考虑它。因此，请注意隐式接口如何限制您的系统设计和演进，并且知道对于任何合理的流行系统，界面达到比您想象的更深入。
我是谷歌的软件工程师，在大规模代码更改工具和基础架构上工作。 在此之前，我花了五年改善了谷歌＆＃39;核心C ++图书馆。 即使是最简单的库变化导致一些远离系统的故障，上述观察结果也会脱离经验。 虽然我可能已经取得了观察，但信用媒体冬天的冬天实际命名为＆＃34; hyrum＆＃39;法律＆＃34; 并更广泛地推广概念。 关注@hyrumwright在推特上做出轮