昨天在微博上看到InfoQ提供了一本新書《完美軟件開發：方法與邏輯》的PDF迷你版，這本書的介紹吸引了我：
這書是培養帥才的書。如果想成為一方悍將（比如：C++高手，Android高手），那這書是不太適合的；但如果想鳥瞰全局，運籌帷幄，帶領團隊攻城略地，那這書是很有參考價值的。
我重點看了它的第7章“完美設計和編碼之解構”，應該說這是一本好書，但是對我來說總體上沒有什么新的收獲，作者對軟件設計的理解和我兩三年前比較類似，而最近兩年我對軟件設計的理解發生了很大的變化。從書的內容看得出，作者受OO方法影響很大，我也經歷過這個階段，所以，今天想通過這篇博文談談我對OO方法的看法。
我喜歡從道、術、靈3個角度看技術。道是事物的本質，是事物的共同性，修道最簡單，一點就通，只需要悟性；術是具體技術和應用，修術比較難，需要長期積累和實踐；靈是創造性，並由此產生事物的差異性，修靈最難，無規律可言，但它是道和術到達一定程度的自然產物。這里只討論道的范疇，即主要探討設計的本質和共同性。
所謂本質就是“變化中的不變”，所謂抽象也就是找到這個“不變”。我用提取公因子來比喻，假設你只有6、9兩個數，你提取的公因子可能是3，並把3當成本質，但是其實1是更本質的，這時被你忽略了；當你有2、6、9三個數的時候，你突然發現3還不夠本質，原來1更本質。這是個比喻，我不追求准確，目的在於比喻視野和廣度的重要性。你的視野越寬涉獵范圍越廣越容易找到更深層次的本質。反過來，要檢驗你找到的本質是不是足夠深，也要放到盡量寬的范圍去。
兩三年以前，我主要從企業級軟件開發，也認真學習和研究過OO方法，包括OOP基礎理論、GoF設計模式、S.O.L.I.D設計原則、契約式設計、IoC原理等等，應該說對於OO方法的理解也代表我當時的階段性水平。近兩三年，我涉獵范圍更加廣泛，現在我系統底層、中間件、服務器、桌面/移動應用、Web什么都做。現在讓我再回頭看OO，就像找最大公約數的例子，它顯然不是那個我要找的1，我已經基本上沒有興趣再談OO了，就像我兩三年前沒興趣談“指針使用”這樣的非設計的本質問題。現在如果讓我來談設計之道，OO的影子幾乎都找不到；相反，如果我看到別人在談設計之道時還在大量地圍繞OO相關的話題來討論，即使某些思路和傳統方法不同，我還是感覺作者的視野和深度有進一步提高的空間。
Brooks講的“根本任務是指打造構成抽象軟件實體的復雜概念結構”沒錯，但是不論是面向過程還是OO方法都不是這一思想的最好體現。許多人也認識到軟件設計是一個多維度、多層次的抽象過程，但是問題不在於這一認識本身，而在於面對一個具體問題時如何定義這些維度和層次。基本上，我所了解的熟悉OO方法的人都很難脫離OO帶來的思維局限，比如，不少人熟背“設計首先要抽象”，但是當他具體做設計的時候，一上來就定義了幾個接口，幾個基類，永遠跳不出這個圈子，這就是各種OO設計模式和設計原則的副作用，它讓人們潛意識里面把真正意義的抽象建模和OO的抽象建模混在一起。
有人用切蛋糕比喻軟件開發，要把蛋糕切成8份，在1維空間需要切7刀，2維空間需要4刀，3維空間只需要3刀。所以，關鍵的問題在於如何選取下刀的維度。在我看來，OO方法基本上都屬於這個比喻中的2維，好像比最笨的方法高明一點，但是其實遠遠不夠。OO作為一種范式它本身代表了一定的抽象維度，在切蛋糕的比喻中就是下刀的位置。這種方法恰好碰對了問題的時候也是有的，比如，如果問題是讓你切成4塊，這種方法就完美了。但是，OO的根本性問題在於它不是從問題本質出發，而是強行地把實體、實體間關系、繼承、子類型等概念往問題上加。
我們在評價一個方法是不是好方法的時候一定要堅持價值判斷，即這種方法帶來的軟件“開發量、可讀性、可維護性、可擴展性、可測試性”和其他方法比怎么樣？我對OO以及相關各種方法的評價是：有一定價值，但遠遠不夠。