|
面向對象的話題本來是個老話題了。只是看到還有不少人對這個問題有所困惑，我也就不吝淺薄，談談自己對面向對象的理解。還請大家在讀過之后，能夠不計鄙人的淺薄，多提寶貴意見。不斷地爭論和討論是前進的根本動力。 面向對象的整套方法本來可以分為面向對象分析、面向對象設計、面向對象編程等。但是在這點上，我是贊同XP的開發(fā)思想的：代碼就是所有的設計。因此，我更愿意把面向對象看作一個整體：一切最終落實到體現了面向對象思想的代碼?；诖朔N考慮，在這里我也不區(qū)分OOA/OOD/OOP，而是泛指在面向對象思想指導下的軟件開發(fā)及實現全過程。需要注意的是：“體現了面向對象思想的代碼”和“面向對象的代碼”是不同的概念, C#,java的語言特點決定了無論有沒有面向對象的靈魂，其編碼的“肉體”都是面向對象的。 關于OO的應用場合，還有很多人在爭論。前些天看到還有人說三層結構/多層結構不適用于網站開發(fā)。從根本上講，這和OO是不是適用于網站開基本上是同一個問題。因為，很顯然，OO和N-Tier常常是一件事情的兩個不同方面，使用OO卻不使用多層結構是難以想象的，使用N-Tier卻不使用OO那我就更加不知其可了?？傊谖铱磥?，這兩件事情是緊密相連的。退一步講，將二者緊密聯系在一起，如果不是必然的話，至少也應被看作是開發(fā)過程中的一個Best Practice。 下面談談我對OO + N-Tier的幾個基本觀點： 我以前看到一些同道在進行OO開發(fā)的時候，對象常常只在數據加載和保存中的出現。對象更像是一個盒子，在需要數據時，我們建立數據庫連接，獲取結果集或者DataReader/ResultReader，將從數據庫獲得的數據“填充”到對象中，然后再將對象返回給上層應用使用；在需要保存數據時，過程基本是對稱的：我們把對象中的數據，一個字段一個字段讀出來，生成參數化的或者直接字符串拼接的查詢語句，建立數據庫連接，提交更新到數據庫。如果OO的主要內容就是這些的話，OO如果不能說是完全沒有意義的話，起碼意義也不大。我們在付出了編寫了大量對象代碼并且在存儲加載時多一道手續(xù)的代碼和性能代價之后，得到的好處只是使上層應用操作數據的代碼可讀性更好并且能夠進行一定的類型強制和檢查。這常常是很多開發(fā)人員對OO很困惑的原因：OO看起來很美，但是做了那么多事情，難道就是為了看起來很美嗎？這同時也成為一些編程老手把OO看作華而不實代名詞的原因：美是美了一點，但是代碼多了，性能差了，讓書呆子們去用吧。之所以出現這種局面，其根本原因在于“內存對象世界”沒有提供太多的附加值。 大家應該注意到“內存對象世界”這一說法。在我看來，對象至少有兩個世界，一個是“持久化對象世界”，一個是“內存對象世界”，這是由當今計算機的結構特點決定的：如果數據要長期保存，數據就必須被保存到可持久化的媒介中；如果要進行運算，數據就必須被加載到可運算尋址的媒介中。前者就是DB Server等管理的硬盤、磁帶機...，后者就是內存。在DB Server為中心的開發(fā)中，大家傾向于把所有邏輯直接放置在最接近“持久化對象世界”的DB Server中，并主要以存儲過程的形式存在。但是這樣就一定是最合理的嗎？尤其是對于網站應用？如果這樣確實是合理的話，OO還有什么意義呢？是不是OO真的如某些人所說，只適合于圖形繪制等特定領域？要回答這些問題，我們還是要看看哪些情況下，“內存對象世界”能夠相對獨立于“持久化對象世界”發(fā)揮其作用，這樣“內存對象世界”就具備了獨立于“持久化對象世界”之外的獨立意義。 網站應用的特點是：看數據的人多，創(chuàng)建數據的人少。眾所周知，恰恰就是這一點決定了緩存對于網站系統的重要性。對于主要以靜態(tài)內容為主的小型簡易網站，我們在這里就沒有討論的必要了。真正有人氣的網站一定是具有動態(tài)增長的準靜態(tài)內容（如新聞類網站，內容不斷增加，但是本身很少修改）或者大量動態(tài)內容（如交易型的電子商務網站）的。對于前一種情況，通常有兩種方式來加速其訪問，一種是生成靜態(tài)頁面，一種是在內存中緩存頁面內容。生成靜態(tài)頁面在性能上未必總是最好的選擇。只有當數據多到內存中根本緩存不下，而這些數據又都有很大可能被用戶訪問時，生成靜態(tài)頁面才是較佳選擇。在數據較多，但是并發(fā)并不多時，或者并發(fā)雖多，但關注的內容并不多時（如近兩日新增信息或者近幾日修改信息），頁面緩存就是更好的選擇。原因很簡單，因為頁面緩存的訪問速度要明顯快于靜態(tài)頁面。當然，有時候二者可以結合起來，這里就不多講了。對于后一種情況——真正的較大型電子商務性網站，我們面對的是另一個問題：一些信息被以網頁形式緩存，但這些信息本身的數據信息（如商品信息中的剩余數量，賣家Id等）常常需要被用到進行相關處理，如果只是進行了網頁緩存，而沒有進行對象緩存的話，緩存的意義就不打。在這種情況下，對象緩存就成為最好的選擇。其實，在前一種情況下，頁面緩存也可以以對象緩存的形式單獨或者分級混合并存。 回到我前面提出的觀點：“脫離了大量緩存和基于對象的業(yè)務邏輯的OO是沒有意義的”。其道理是顯而易見的，只有使用了大量緩存和基于對象的業(yè)務邏輯，建立一個OO結構的收益才遠大于我們付出的代價，OO本身所在的“內存對象世界”也才具備了脫離“持久化對象世界”而存在的根本意義。如果我們能把大量適合放在內存中的業(yè)務邏輯搬移到應用內存中（而不是DB Server）的話，那效果就更好。當然也有一些操作不適合放在應用邏輯中，如針對特別大量數據的非個性化的成批更新操作。至于什么叫大量，這取決于性能的考慮和實證。將很多業(yè)務邏輯從數據庫搬移到應用內存中是可行的，尤其是對于在執(zhí)行前要根據很有限的數據條目進行大量判斷來決定是否實質性產生某種數據改變的邏輯更是如此。代價是速度可能較存儲過程差一點點，但是卻避免了因為大量不符合規(guī)則從而根本不會產生實質數據改變的無效調用而導致的應用服務器到數據服務器的網絡往復，二者相比，無謂的往復往往代價要高得多。對于現實的電子商務網站，這一點是非常有價值的。
2）OO并不是低性能的代名詞，設計合理的OO會帶來意想不到的高性能。 OO并不是低性能的代名詞。恰恰相反，很多時候我都把OO當作我提升網站性能的基本武器：通過結構合理而算法高效的對象緩存技術以及與對象結合并在同一地址空間中執(zhí)行的業(yè)務邏輯，我們往往能夠輕易地提升系統的性能。當然，一切的前提在于正確的設計，這不斷適用于OO，也適用于世間一切，沒有什么東西脫離了其實現的細節(jié)而萬歲千古！ 以我們最近完成的一個較大型電子商務網站為例（目前日均訂單〉12000，成交訂單筆數在3000左右，而且最近增長勢頭很好），在運行近三個月后，該網站在Alexa的速度統計已經從早先的very slow（平均一個頁面6~7妙），經過slow（Alexa的數據是累計的，所以不是立即跳變），上升到average（平均一個頁面2.0s）。與此同時，DB Server的CPU Usage從原來的平均80%急劇的下降到平均10%！在現有系統中，基本上除了一些大批量數據移動和數據庫服務器段數據分頁查詢之外，所有業(yè)務邏輯均存在于我們的應用邏輯中。這大概是違法很多朋友的開發(fā)直覺的。我經常聽到的是：用存儲過程吧，為了性能...我不是在一切場合都反對使用存儲過程。但是我們必須清楚，每一種方法的優(yōu)點是什么？缺點是什么？條件是什么？什么場合適用？什么場合不會適用，什么場合二者應該在更細微的場景/場合下分別或者混合使用。這有點象物理中的定理：誰見過沒有適用條件的定理？
3）如果你關注Scale out的能力，你就更應該考慮OO。 現實世界的網站應用系統，都必須考慮Scalability問題，除非業(yè)務永不增長。只要業(yè)務會增長，使用人數不斷增多，服務器就一定會很快達到性能和并發(fā)極限。解決這個問題，通常只有兩個辦法：Scale up——買更好的服務器，而這往往因其代價過于高昂而不現實；Scale out——買更多的服務器，這往往是最終的實際選擇。但是Scale out始終面臨著數據集中（就算是拆分過的數據仍然各自相對集中，能做到無限隨意拆分嗎）的問題。如果大量的邏輯放在數據庫服務器一端，我相信很快數據庫服務器就會使得系統失去Scale out的能力和可能。因此，要保證Scale out的能力就必須保證數據庫（當然，必要的拆分策略也很重要，但那屬于另一個話題）只處理實質性的數據提交和不可避免的數據查詢，對于能夠避免的數據查詢和非實質性數據提交都應該想辦法予以避免。這其實和我們上面所說的“脫離了大量緩存和基于對象的業(yè)務邏輯的OO是沒有意義的”剛好結合起來，成為一舉奪得的美事。
4）OO + N-Tier的基本思想乃至軟件開發(fā)方法的所有其他動力是對邏輯聚合和復用地不斷追求。 大家都知道，軟件開發(fā)的分析設計方法一直在不端演化，新的概念不斷涌現。軟件開發(fā)也從最早的直線條的機器語言，到面向過程的匯編語言，再到面向對象的對象化分析設計及編程（繼承、接口、多態(tài)），以及后來的DP（設計模式）、AOP(面向方面的編程)...。一系列的演化，確實讓人有眼花繚亂之惑何從入手之惑。那么在這一演化過程中，一以貫之的是什么？始終不變的又是什么呢？ 在回答這個問題前，我們先來看一看MVC。MVC是現在大家都很熟悉的設計模式。那么到底什么是MVC呢？下面是Wikipedia關于MVC的解釋：Model-View-Controller (MVC) is a software architecture that separates an application‘s data model, user interface, and control logic into three distinct components so that modifications to the view component can be made with minimal impact to the data model component. 翻譯過來就是：MVC是一種將應用的數據模型、用戶界面（視圖）以及控制邏輯分解到不同組件中的軟件構架。這種分解可以使得視圖組件的細修改對數據模型只會產生很小的影響或者根本不產生影響， 在思考問題的時候，我喜歡跳出問題來看問題，在跨越時間甚至跨越領域的大跨度類比中不斷完成思想的升級及重構?；氐角懊娴膯栴}。在軟件開發(fā)分析設計方法上，一以貫之的其實就是一種類似于MVC的思想：對問題域不斷進行重構，使得一種數據（不要狹隘的看待數據，信息、規(guī)則、動作，一切都可以被看作是數據）、該數據的管控邏輯、以及該數據的使用者（ 不一定是UI，UI只是特例）能夠被區(qū)分開來。從這個角度來看待軟件開發(fā)領域的一切，你就會發(fā)現，一切都在改變，一切也都沒有改變。我們只是為我們一以貫之的方法找到了的應用發(fā)領域。如此而已。再簡化一點，實質上，一切軟件設計方法的突破都是在于指明新的邏輯聚合方向,建立了新的邏輯聚合方法。OO如此，AOP如此，設計模式如此，一切都是如此。
5）只有一些很特定的情況不適用OO + N-Tier。 當然不是所有場合都必須或者適用OO + Np-Tier，因為二者的引入無疑會在某些方面增加成本，因此我們必須考慮我們付出的時候會得到什么，我們得到的時候又會失去什么？權衡——這實際上也是我們做一切事情的最基本思路，而不只是針對軟件開發(fā)。 大家可以自己權衡何時使用OO + N-Tier。下面是我認為不適合的一些場合： |
|
|
