程式程式碼進化的一些思考：從物件導向到設計模式，到函數語言程式設計

最初物件導向是為了保持狀態的針對性:

Class P { 狀態a, 狀態b，狀態c, 狀態d，狀態e，狀態f, ... }

P 的方法:

fun1{操作 a b}
fun2{操作 a b c}
fun3{操作d}
fun4{操作 e f}
...

在物件導向使用久了之後，開發者們必定為龐大的狀態數量和方法數量而嚇退，

從而懷疑起物件導向的可用性。

於是， 設計模式，在反覆的推導實踐中，被提煉出來用於簡化問題:

Class P { 狀態a, 狀態b，狀態 c }
Class M { 狀態 d }
Class N { 狀態e，狀態 f }

P 的方法:

fun1{操作 a b}
fun2{操作 a b c}
fun3{通過M操作d}
fun4{通過N操作 e f}

P 的狀態和方法被委託到與 d e f 聯絡更緊密的 M N 物件中操作。

開發者關心的是 P M N 的通訊， 而不是P的一大堆方法的邏輯。

無論是對描述，還是思考設計，都是一種質的提升。

在函式式鼓吹現代化改革中，辯證的思考函式式所提倡的“狀態不可變”，

可以在物件導向中加入新的設計方式:

Class P { 狀態 a }
Class M { }
Class N { }

P 的方法:

fun1{操作 a b}
fun2{操作 a b c}
fun3{通過M獲得d}
fun4{通過N獲得 e f}
fun5{獲得b}
fun6{獲得c}

再一次簡化“狀態”，函式式的字面表示更趨向於“return”，而不是“=”賦值。

所以，對於不是特別重要的狀態，對記憶體影響不重大的狀態，

可以放入函式的 return 中。

而把特別重要的狀態，經常變動並需要“快取”“記憶”的狀態保留。

再一次的減少維護狀態的數量。

附註: 函式式另外的一種價值

Class P { fun1(m例項) {使用m的方法 fun11；}  }
可以寫為 Class P { fun1(fun11) {使用 fun11；}  }

這種方式對於“中介者”/控制器的動態能力，具有顯著提升。