程序代碼進化的一些思考：從面向對象到設計模式，到函數式編程
最初面向對象是為了保持狀態的針對性:
</blockquote>Class P { 狀態a, 狀態b，狀態c, 狀態d，狀態e，狀態f, ... }P 的方法:
fun1{操作 a b}
fun2{操作 a b c}
fun3{操作d}
fun4{操作 e f}
...
</blockquote>在面向對象使用久了之后，開發者們必定為龐大的狀態數量和方法數量而嚇退，
從而懷疑起面向對象的可用性。
于是， 設計模式，在反復的推導實踐中，被提煉出來用于簡化問題:
Class P { 狀態a, 狀態b，狀態 c }
Class M { 狀態 d }
Class N { 狀態e，狀態 f }
</blockquote>P 的方法:fun1{操作 a b}
fun2{操作 a b c}
fun3{通過M操作d}
fun4{通過N操作 e f}
</blockquote>P 的狀態和方法被委托到與 d e f 聯系更緊密的 M N 對象中操作。
開發者關心的是 P M N 的通信， 而不是P的一大堆方法的邏輯。
無論是對描述，還是思考設計，都是一種質的提升。
在函數式鼓吹現代化改革中，辯證的思考函數式所提倡的“狀態不可變”，
可以在面向對象中加入新的設計方式:
Class P { 狀態 a }
Class M { }
Class N { }
</blockquote>P 的方法:fun1{操作 a b}
fun2{操作 a b c}
fun3{通過M獲得d}
fun4{通過N獲得 e f}
fun5{獲得b}
fun6{獲得c}
</blockquote>
再一次簡化“狀態”，函數式的字面表示更趨向于“return”，而不是“=”賦值。所以，對于不是特別重要的狀態，對內存影響不重大的狀態，
可以放入函數的 return 中。
而把特別重要的狀態，經常變動并需要“緩存”“記憶”的狀態保留。
再一次的減少維護狀態的數量。
附注: 函數式另外的一種價值
Class P { fun1(m實例) {使用m的方法 fun11；} }
可以寫為 Class P { fun1(fun11) {使用 fun11；} }
</blockquote>
這種方式對于“中介者”/控制器的動態能力，具有顯著提升。來自: www.jianshu.com<span id="shareA4" class="fl"> </span>本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！