從物件導向到函數式編程的深入解析
16公開內容
這不是教你如何從物件導向到函數式編程的入門教程。我會深入探討物件導向與函數式編程的差異，並討論為什麼你應該使用函數式編程並徹底放棄物件導向。
全部內容
免費與付費
最新發佈優先
這個系列的文章主要專注於物件導向到函數式編程的差異與分析，並針對概念與機制上的不同進行比較。很多人說物件導向和函數式編程沒有哪個比較好的問題，只有哪個比較適合的問題，然而我並不這麼認為，我透過這一系列的文章從各個角度討論它們之間的優缺點就是為了闡述我的觀點。物件導向錯在沒有理論基礎，但它贏在熟悉性，
前一篇文章中所提的函數式的三個機制明確說明了它關注的規則與能力具體是什麼。然而這套對於函數式編程的定義主要基於特定的類型系統，作為一個編程範式來說過於狹隘（物件導向的定義也是這樣）。更廣義的，我認為函數式編程主要依循三個原則，它們可以應用於任何程式語言，就算沒有靜態類型系統的支援也可以。例如在不管類
前面談了那麽多函數式編程與物件導向的差異，但我們還沒定義函數式編程。就像物件導向，函數式編程沒有明確的定義，每個人對於什麼是函數式編程都有不同的看法。在這裡我會總結前面的討論，給出我對於函數式編程的觀點。
物件導向注重封裝與延展性，因此一般基於三個機制：繼承、多型、封裝，它們代表了物件導向所重
說到物件導向就必須提五個原則，統稱SOLID，它被認為是物件導向的重要概念。這五個原則並不只適用於物件導向，事實上它很像函數式編程的習慣。它的命名很奇怪且容易讓人混淆，所以我會用我自己的翻譯解釋。
Single Responsibility Principle 是「單一職責原則」，認為一個模組
讓我在這篇文章總結一下前面對物件導向設計的討論，我們討論了物件導向的四個特性：繼承、抽象、多型、封裝，分析了它們的問題，並跟函數式編程的思維做比較。我們引入了與之相對應的特性：泛型、特性系統、模組化，有些特性雖然跟那四個特性很像，但在一些細微的地方有不同的詮釋，使得整體思考方式很不一樣。
「繼
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相
上一篇文章提到有些介面不應被繼承，但物件導向的子類別只能繼承父類別的介面，因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制，這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承，更適合使用組合，根本不需要使用繼承疊加特性。
資料類型的定義往往跟怎麼建構模型相
類似於trait/typeclass的特性系統能提供程式「延展性」，它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像，然而特性系統的彈性比較大一點，而且概念上也有一些差別。為了探討討論這些差異，我們必須深入了解繼承機制到底是什麼。
繼承並不是建立子類關係的唯一方法。所謂的
所謂的多型是讓一個函式或是資料結構能擁有多個不同的類型，其中上一篇文章所談的就是參數多型(parametric polymorphism)，這篇文章將繼續討論特設多型(ad hoc polymorphism)。特設多型跟泛型的差別在於：泛型函式對於所有的類型只能有一種實作，而特設多型會根據類型有不同
前幾篇文章討論了類型系統的合理性，而這會影響我們對於變數與函式是什麼的理解。其中泛型是當中很重要的一個元素，很多討論都是基於泛型的使用。泛型會大大地增加類型系統的複雜度，因此有些語言選擇不提供泛型(go)，但缺少泛型又會使簡單的容器都無法用類型精確描述。泛型的強大必須結合有紀律的類型系統才能顯現，但
