oo,來自實戰(zhàn)的深入思考

1、WhyOO多層結構多層結構來自實戰(zhàn)的深入思考來自實戰(zhàn)的深入思考面向對象的話題本來是個老話題了。只是看到還有不少人對這個問題有所困惑，我也就不吝淺薄，談談自己對面向對象的理解。還請大家在讀過之后，能夠不計鄙人的淺薄，多提寶貴意見。不斷地爭論和討論是前進的根本動力。面向對象的整套方法本來可以分為面向對象分析、面向對象設計、面向對象編程等。但是在這點上，我是贊同XP的開發(fā)思想的：代碼就是所有的設計。因此，我更愿意把面向對象看作一個整體：一切最

2、終落實到體現(xiàn)了面向對象思想的代碼?；诖朔N考慮，在這里我也不區(qū)分OOAOODOOP，而是泛指在面向對象思想指導下的軟件開發(fā)及實現(xiàn)全過程。需要注意的是：“體現(xiàn)了面向對象思想的代碼”和“面向對象的代碼”是不同的概念C#java的語言特點決定了無論有沒有面向對象的靈魂，其編碼的“肉體”都是面向對象的。關于OO的應用場合，還有很多人在爭論。前些天看到還有人說三層結構多層結構不適用于網站開發(fā)。從根本上講，這和OO是不是適用于網站開基本上是同一個問

3、題。因為，很顯然，OO和NTier常常是一件事情的兩個不同方面，使用OO卻不使用多層結構是難以想象的，使用NTier卻不使用OO那我就更加不知其可了。總之，在我看來，這兩件事情是緊密相連的。退一步講，將二者緊密聯(lián)系在一起，如果不是必然的話，至少也應被看作是開發(fā)過程中的一個BestPractice。下面談談我對OONTier的幾個基本觀點：1）脫離了大量緩存和基于對象的業(yè)務邏輯的OO是沒有意義的。我以前看到一些同道在進行OO開發(fā)的時候，對

4、象常常只在數據加載和保存中的出現(xiàn)。對象更像是一個盒子，在需要數據時，我們建立數據庫連接，獲取結果集或者DataReaderResultReader，將從數據庫獲得的數據“填充”到對象中，然后再將對象返回給上層應用使用；在需要保存數據時，過程基本是對稱的：我們把對象中的數據，一個字段一個字段讀出來，生成參數化的或者直接字符串拼接的查詢語句，建立數據庫連接，提交更新到數據庫。如果OO的主要內容就是這些的話，OO如果不能說是完全沒有意義的話，

5、起碼意義也不大。我們在付出了編寫了大量對象代碼并且在存儲加載時多一道手續(xù)的代碼和性能代價之后，得到的好處只是使上層應用操作數據的代碼可讀性更好并且能夠進行一定的類型強制和檢查。這常常是很多開發(fā)人員對OO很困惑的原因：OO看起來很美，但是做了那么多事情，難道就是為了看起來很美嗎？這同時也成為一些編程老手把OO看作華而不實代名詞的原因：美是美了一點，但是代碼多了，性能差了，讓書呆子們去用吧。之所以出現(xiàn)這種局面，其根本原因在于“內存對象世界”

6、沒有提供太多的附加值。大家應該注意到“內存對象世界”這一說法。在我看來，對象至少有兩個世界，一個是“持久化對象世界”，一個是“內存對象世界”，這是由當今計算機的結構特點決定的：如果數據要長期保存，數據就必須被保存到可持久化的媒介中；如果要進行運算，數據就必須被加載到可運算尋址的媒介中。前者就是DBServer等管理的硬盤、磁帶機...，后者就是內存。在DBServer為中心的開發(fā)中，大家傾向于把所有邏輯直接放置在最接近“持久化對象世界”

7、的DBServer中，并主要以存儲過程的形式存在。但是這樣就一定是最合理的嗎？尤其是對于網站應用？如果這樣確實是合理的話，OO還有什么意義呢？是不是OO真的如某些人所說，只適合于圖形繪制等特定領域？要回答這些問題，我們還是要看看哪些情況下，“內存對象世界”能夠相對獨立于“持久化對象世界”發(fā)揮其作用，這樣“內存對象世界”就具備了獨立于“持久化對象世界”之外的獨立意義。網站應用的特點是：看數據的人多，創(chuàng)建數據的人少。眾所周知，恰恰就是這一點

8、決定了緩存對于網站系統(tǒng)的重要性。對于主要以靜態(tài)內容為主的小型簡易網站，我們在這里就沒有討論的必要了。真正有人氣的網站一定是具有動態(tài)增長的準靜態(tài)內容（如新聞類網站，內容不斷增加，但是本身很少修改）或者大量動態(tài)內容（如交易型的電子商務網站）的。對于前一種情況，通常有兩種方式來加速其訪問，一種是生成靜態(tài)頁面，一種是在內存中緩存頁面內容。生成靜態(tài)頁面在性能上未必總是最好的選擇。只有當數據多到內存中根本緩存不下，而這些數據又都有很大可能被用戶訪問

9、時，生成靜態(tài)頁面才是較佳選擇。在數據較多，但是并發(fā)并不多時，或者并發(fā)雖多，但關注的內容并不避免。這其實和我們上面所說的“脫離了大量緩存和基于對象的業(yè)務邏輯的OO是沒有意義的”剛好結合起來，成為一舉奪得的美事。4）OONTier的基本思想乃至軟件開發(fā)方法的所有其他動力是對邏輯聚合和復用地不斷追求。大家都知道，軟件開發(fā)的分析設計方法一直在不端演化，新的概念不斷涌現(xiàn)。軟件開發(fā)也從最早的直線條的機器語言，到面向過程的匯編語言，再到面向對象的對象

10、化分析設計及編程（繼承、接口、多態(tài)），以及后來的DP（設計模式）、AOP(面向方面的編程)...。一系列的演化，確實讓人有眼花繚亂之惑何從入手之惑。那么在這一演化過程中，一以貫之的是什么？始終不變的又是什么呢？在回答這個問題前，我們先來看一看MVC。MVC是現(xiàn)在大家都很熟悉的設計模式。那么到底什么是MVC呢？下面是Wikipedia關于MVC的解釋：ModelViewController(MVC)isasoftwarearchitect

11、urethatseparatesanapplicationsdatamodeluserinterfacecontrollogicintothreedistinctcomponentssothatmodificationstotheviewcomponentcanbemadewithminimalimpacttothedatamodelcomponent.翻譯過來就是：MVC是一種將應用的數據模型、用戶界面（視圖）以及控制邏輯分解到不同組

12、件中的軟件構架。這種分解可以使得視圖組件的細修改對數據模型只會產生很小的影響或者根本不產生影響，在思考問題的時候，我喜歡跳出問題來看問題，在跨越時間甚至跨越領域的大跨度類比中不斷完成思想的升級及重構。回到前面的問題。在軟件開發(fā)分析設計方法上，一以貫之的其實就是一種類似于MVC的思想：對問題域不斷進行重構，使得一種數據（不要狹隘的看待數據，信息、規(guī)則、動作，一切都可以被看作是數據）、該數據的管控邏輯、以及該數據的使用者（不一定是UI，UI

13、只是特例）能夠被區(qū)分開來。從這個角度來看待軟件開發(fā)領域的一切，你就會發(fā)現(xiàn)，一切都在改變，一切也都沒有改變。我們只是為我們一以貫之的方法找到了的應用發(fā)領域。如此而已。再簡化一點，實質上，一切軟件設計方法的突破都是在于指明新的邏輯聚合方向建立了新的邏輯聚合方法。OO如此，AOP如此，設計模式如此，一切都是如此。5）只有一些很特定的情況不適用OONTier。當然不是所有場合都必須或者適用OONpTier，因為二者的引入無疑會在某些方面增加成本

14、，因此我們必須考慮我們付出的時候會得到什么，我們得到的時候又會失去什么？權衡——這實際上也是我們做一切事情的最基本思路，而不只是針對軟件開發(fā)。大家可以自己權衡何時使用OONTier。下面是我認為不適合的一些場合：a)太簡單的應用，寫起來沒幾句代碼，使用OONTier根本不值得b)已經有一套很接近目標系統(tǒng)的原型系統(tǒng)，暫時沒有必要使用OONTier，因為成本不合算c)開發(fā)人員完全不知道該怎么使用OONTier，教育成本不低，暫時不建議使用d