可以先看看代碼對比： 基於類的方式改寫： http://git.oschina.net/web3d/DeCMF/commit/58f915b9d24ab5ffe40adf4ad4ed769fdb6ebe6e 原來的函數形式： http://git.oschina.net/web3d/DeCMF/co ...
可以先看看代碼對比：
基於類的方式改寫：
http://git.oschina.net/web3d/DeCMF/commit/58f915b9d24ab5ffe40adf4ad4ed769fdb6ebe6e
原來的函數形式：
http://git.oschina.net/web3d/DeCMF/commit/228983fb76b7bd6b69e6116d984ebfe7454d4b8d
這個項目是為了演示OOP編程實踐而建立的，基於OneThink CM框架。
上述代碼，將一個函數的代碼，拆分到兩個類中-父子類繼承，在後續整理的過程中，就發現了這樣的好處，函數庫中另一個類直接代碼重用了。
get_addon_list函數的改寫：
http://git.oschina.net/web3d/DeCMF/commit/9ae6a2fe9abe27789a1d1c0982d20f97950c1895
原本的一個get_list_field 函數58行，基於面向對象的方式初步改寫後，變成240多行，咋一看，代碼行數多了很多，不科學啊！
但仔細看後，除去註釋90行、語句換行大致20行，其他嵌套語句拆分10幾行，原本缺少的邏輯細化，並沒有真正增加幾行代碼。
其實，OOP代碼更多是個偽命題，我只是想以此為話題，回顧一下OOP！
面向對象好像對很多人不是個事，但其實只是大多數人沒有真正去在意什麼是OOP。
OOP的三大特性：
1.封裝
把過程和數據包圍起來，只讓可信的類或者對象操作，對不可信的進行信息隱藏。
2.繼承
通過過程抽象和數據抽象。理出一般與特殊的關係。代碼重用。
3.多態
不同類的對象對同一消息作出響應的過程不同。介面重用！
將所有邏輯塞到一個函數或者類方法中是沒有區別的，這不是面向對象，也不是面向對象的初衷，設計OOP的初衷是解決代碼的重用問題。現實中代碼的重用程度好像並沒有一個明確的標準，所以不同的人實踐後會有不同程度的接受度。
通過面向對象，我們要找到相關數據和功能邏輯的關係，並與外界相對隔離，專心專意的去解決一個問題，不會因為暴露出來的全局變數或者函數影響整體代碼的可讀性和可維護性；同時，考慮事物的多態性，分層去定義對象的屬性與功能。
在團隊項目中，一坨垃圾代碼我們要維護很久很久，直到受不了離開為止。或者是新團隊，從頭開始寫，用最牛掰的框架，最牛掰的架構，寫出一坨垃圾代碼，然後維護很久很久，直到受不了離開為止......
所以，能否戰勝垃圾代碼，其實才是真正檢驗程式員水平的標準。面試了很多人，也有一些新人加入團隊後不久就離開，標準理由都是，項目太複雜了，代碼太垃圾了，最好能從頭開始一個新系統、或者給我一年時間重構現在的系統！
我只能不屑的一笑：你們都是懦夫，真正的程式員敢於直面垃圾的代碼，敢於正視破碎的系統！
這是怎樣的哀痛者和幸福者？然而造化又常常為平庸的程式員設計，以時間的流逝，來洗滌舊邏輯，僅使留下蒼白的產品和微漠的悲哀。在這蒼白的產品和微漠的悲哀中，又給程式員暫得偷生，維持著這似是而非的系統。你不知道這樣的系統何時是一個盡頭！
但我知道！OOP是沒有盡頭的！
