什么是海勒姆定律

本篇內容介紹了“什么是海勒姆定律”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

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 對我們有何啟發

在實際工作中，我們一方面要盡量設計好接口，將接口和實現隔離，但同時也要留意隱式接口問題。特別是對外提供服務(包括公司的基礎部門，對其他部門提供服務)，要求我們在構建和維護復雜系統的時候思考的更全面一點。我們需要意識到，隱示接口會限制我們系統的設計和發展。雖然隱式接口理論上不是你的鍋，但使用者不會這么認為。

所以，「卷」有了理論依據。谷歌很多年前就用理論證明了「卷」的普遍存在，卷的有理有據，你還能不倦嗎???

“什么是海勒姆定律”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！