什么是海勒姆定律

本篇内容介绍了"什么是海勒姆定律"的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

01 海勒姆定律

在程序设计中，接口和实现是很重要的两部分。通常在一个系统里面，接口就是一个与系统交互的抽象，比如汽车的方向盘和油门，刹车这些(我们通过这些来控制汽车，与汽车交互)，而实现则是这个系统工作的一种方式，比如汽车的轮子和引擎(汽车实际是通过这些来工作的)。区分接口和实现的好处是非常明显的，当一个系统快速迭代，变得越来越复杂和难以理解的时候，抽象能非常好的帮助我们管理这些复杂性。

可见，一个接口在理论上需要清晰的将系统的使用者和该系统的实现隔离开。汽车系统是如此，其他系统也是如此。虽然设计者很努力，但现实往往是残酷的，当这个系统开始逐渐膨胀，一些用户开始依赖一些通过接口暴露出的内部的实现细节，「内卷」开始。。。

几年前，Google 的一名工程师，Hyrum(海勒姆)观察指出：

当 API 有足够多的用户时，你在合同中的承诺已不重要：你系统的所有可观察行为都将被某些人所依赖。

这也叫做「隐式接口定律」。

也就是说，当你的 API 有足够多的用户时，API 的所有行为(包括那些未囊括在公共说明中的一部分)最终都会被其他人所依赖。一个简单的例子是 API 的响应时间这种非功能性因素;还有一个更微妙的例子是：用户使用正则表达式匹配错误提示来判断 API 的错误类型，即使 API 文档中没有任何关于错误提示的内容，而是指导用户应该使用相应的错误代码。一些用户依然会使用错误提示内容(而非错误代码)，这种情况下变更 API 错误提示信息，实际上会破坏 API 的使用。

俗称：不按套路出牌。

02 该定律在 Go 中的体现

随着使用 Go 的人越来越多，大家超越 Go 规范，不满足于 Go 公开的 API，「卷入」其内部实现了。你会写 Go 代码，写过大型项目可能都不够，你必须得符合「海勒姆定律」，挖挖 GMP、GC 等 runtime 很多实现细节。

虽然 Go 官方一直在避免大家陷入实现细节，依赖实现细节，但还是挡不住「爱学习」的人们。比如 Go 中的 map 是无序的，但某个版本的实现，用户测试输出，咦，发现是有序的。。。然后依赖它。Go 官方「一怒之下」，故意打乱顺序。

再比如一个包中多个文件的初始化顺序，规范并没有进行约定。但目前官方的实现是按照文件名顺序初始化的，于是很可能就有面试题，并且多半答案就说是文件名顺序，因为现在是这么实现的，源码在那摆着呢。。。

再比如，Go 中 slice 的扩容，太多太多文章解释，扩容的规则是怎么样的，1.5 倍?2 倍?规范并没有对此做约定。而且 Go 不同版本的实现还经常变。用好 slice 貌似基本不能满足要求，你必须得知道它怎么扩容的，每次扩容增加多少?这跟开车需要知道发动机原理似乎没啥区别~

还有很多很多例子，欢迎留言!

03 对我们有何启发

在实际工作中，我们一方面要尽量设计好接口，将接口和实现隔离，但同时也要留意隐式接口问题。特别是对外提供服务(包括公司的基础部门，对其他部门提供服务)，要求我们在构建和维护复杂系统的时候思考的更全面一点。我们需要意识到，隐示接口会限制我们系统的设计和发展。虽然隐式接口理论上不是你的锅，但使用者不会这么认为。

所以，「卷」有了理论依据。谷歌很多年前就用理论证明了「卷」的普遍存在，卷的有理有据，你还能不倦吗???

"什么是海勒姆定律"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！