在基本的面向對象編程中，你只能直接調用一個類的方法，而這些方法是由這個類的作者定義的，這對于面向用戶設計的類來說是沒有問題的。此外，在 20 - 30 年前，在大型標準庫和開源庫被大量復用之前，大部分代碼通常是跟自己的代碼中的類來一起工作的 —— 也就是你自己的團隊或公司維護的代碼。然而，在現代代碼世界中，我們經常會使用其他人編寫的類。

業務邏輯通常大量使用包括字符串和集合等標準庫功能、以及第三方庫中的一些類，我們受到這些類提供的操作的限制。例如，當我們需要用破折號替換字符串中的空格時，我們會這樣編寫代碼：

string.replace('?',?'-')

但是當我們需要將左邊的字符串對齊到指定的長度時，我們可能沒有現成的方法可用，在這些舊的語言（如 Objective-C、C++、Java 或 JS）中，你需要強制寫成這種形式：

leftPad(string, ' ', length)

這個 leftPad 可能來自一個單獨的庫1，也可能來自第三方的工具函數集合（比如 Apache Commons），或者在你自己的項目中自行編寫。總之，它的調用看起來和字符串類上的內置方法是非常不同的。

為什么會有這樣的問題呢？我引用 Java 的作者之一 Guy Steele，他在 1998 年的《成長的語言》論文2中的一段話。

在大多數語言中，用戶至少可以定義一些新語法來代表另外一段代碼，然后可以很方便地調用這些代碼，這種方式可以讓新語法看起來像原生調用一樣。通過這種方式，用戶可以構建一個更大的語言來滿足他的需求。

Guy Steele, Growing a Language

他是在批評 APL 缺乏這樣的設施，但同樣的批評也適用于現代環境下的舊的面向對象語言。你被困在一個類的操作詞匯表上，而這個詞匯表是原始庫的設計者們所設想的，它不能由你來擴展。此外，它也沒法被廣泛使用的庫的維護者隨意地擴展，再次引用同一篇論文中的內容作為原因。

編程詞匯的一部分適合所有程序員使用，但其他部分僅適合少數幾個人。?程序員需要了解學習其所有詞匯用法，這并不公平。

現代語言（如 C#、Scala、Rust、Kotlin 和 Swift）通過支持擴展方法解決了這個問題。你可以在不是你控制的類中添加特定領域的擴展方法，這樣，你自己的函數可以用類似于內置方法來調用，而你的代碼仍然可以像散文一樣，流暢的按從左到右的順序閱讀。

string.padLeft(' ',?length)

這個 padLeft 擴展可以在任何地方定義，它是一個很好的編程語言進化的故事。但是，它的意義還不止于此。

一旦一種編程語言支持擴展函數，它就改變了經典面向對象的 API 設計方法。這對于一個從 Java 這樣的舊語言，切換到 Kotlin 這樣的現代語言的程序員來說，是一個不小的啟示，因為擴展函數通常只是作為方便的語法糖3呈現出來。我們還是先看一個帶有一堆屬性（或 getter 方法）的接口。

interface Obscure {val foo: Intval bar: Intval sum: Intval max: Intval min: Int }

它和你在一個典型的商業應用程序中找到的接口或類并無大的區別 —— 有一堆屬性和方法。

你能快速掌握這個接口代表了一個什么樣的實體嗎？它的狀態空間是由哪些屬性構成的？如果沒有額外的文檔，要弄清楚這一點并不容易。但是，讓我們把這個接口重構成一個核心實體和方便的擴展函數。

interface NotObscure {val foo: Intval bar: Int }val NotObscure.sum: Int val NotObscure.max: Int val NotObscure.min: Int

現在，很明顯，這個接口的核心功能是由兩個整數屬性 foo 和 bar 組成的，而其余的 sum、max 和 min 屬性只是為了方便起見而提供的，并在這些核心屬性的基礎上進行計算。不需要再明確地寫文檔描述這種區別了 —— 從代碼的結構中就可以直接看出。

這種面向擴展的設計在 Kotlin 標準庫和第三方庫中得到了廣泛的應用。它是一種強大的設計技術，使用它會有非常好的效果。

這種設計方法有一個副作用。你可能會注意到，Kotlin 代碼通常會使用通配符 import，比如 import com.examplease.*。這在 Kotlin 中很方便，因為在 Kotlin 中僅導入一個類是非常少見的。所有有用的、方便的、實用的函數通常都定義在同一個包中，但在類外作為擴展函數定義。

?

文中鏈接：

https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript, Chris Williams, 2016?

https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf Growing a Language, Guy Steele, 1998

https://kotlinlang.org/docs/reference/extensions.html?Extensions in Kotlin Programming Language

?

英文原文：

https://medium.com/@elizarov/extension-oriented-design-13f4f27deaee

總結

以上是生活随笔為你收集整理的用代码来说明，为什么需要面向扩展的设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。