?開發健壯的企業級應用的研究
???? Research on Develop Hale Enterprise Applications
????????????????????????? 1.03版
????????????????????????? 作者：???? shendl_s@hotmail.com

?

[注：???這篇文章，是我的原創。我同時也在其他網站發布了這篇文章。不要誤會我掠人之美哦^-^???? ?]
????

?

?

?

?

?

?

?

????????????????????? 寫在前面的話
?這是2006年，我參加華中科技大學碩士論文答辯寫的一篇論文。但是，這篇論文寫的太過Blog化，被導師否決了。我打算重寫一篇學位論文，所以，這里把這篇過氣的論文公布出來。
?我是華中科技大學電子信息工程系電子信息工程碩士研究生。 大家可以給我寫E-Mail來聯系我。
??? 我主要使用的語言是Java。Java社區非常活躍，至少現在是如此，可以說是現在最先進的一門編程語言。當然，未來，一切還未注定！
??? 動態面向對象語言，比如Smalltalk,Ruby,Python等這些語言，也非常有魅力。我相信，動態面向對象的機制，在未來應該得到發展和應用。Java1.3引入的動態代理，已經為我們展現了強大的威力。
?Smalltalk僅僅只有幾個關鍵詞，就構成了一門強大的面向對象語言。動態面向對象語言，不需要類型聲明，如果實際類型一致，直接調用好了！當然，也許這并不是靜態面向對象編程語言的缺點，畢竟，編譯器差錯能夠幫助我們減少錯誤。不過，如果能夠在編寫代碼時，模擬運行，也許也能夠在編寫代碼時為我們找出這些錯誤。
?6月6日，我參加了Martin Fowler在上海交大的敏捷開發座談會。會上，Martin Fowler做了關于Ruby的演講。其中，將Ruby和DSL(特定領域語言)聯系到了一起。他認為，Ruby簡潔的語法，是DSL語言的理想表達工具。
?前些天，我看到Intellj的作者的一篇文章，也提出了發展DSL的設想，他正在致力于將Intellj制作成開發DSL的IDE工具。
?Martin Fowler認為目前xml形式的DSL表達方式過于復雜，應該使用普通英語直接表達。目前,我還是認為XML格式的DSL比較好。我們可以自己用Java等語言編寫解釋程序，解釋自定義的xml形式的文本----DSL。XML格式的DSL的優點是便于驗證。
?總之，DSL目前尚未發展成熟，但是未來的前景還是非常樂觀的。不過，現在跟進，可能還太早。
??? 將來，AOP也會有很大的發展。AOP的混入機制，是AOP最強大的機制，未來如果有合適的場合，應該會成為程序員手中又一個殺手锏。
??? 我想，未來可能會出現這樣一種語言：她集中了靜態面向對象編程語言和動態面向對象編程語言的機制于一身，還直接支持AOP這樣的編程范式。
??? 盡管ASpectJ已經擴展了Java。但是，由于并不是標準的Java，所以，大家使用起來仍然有困難。當然，現在Java不把AspcetJ引入Java標準，可能也因為現在AOP還沒有成熟，眾多的產品和理念還沒有決出勝負。
??? 未來這樣的一種語言，也許是未來的Java，也可能是一種全新創造的語言，或者是一門動態面向對象編程語言的擴展。不過，沒關系，還是Java的理念。到時候，Java社區的程序員也是可以毫不費力的轉到新的社區的！
??? 在本文的最后，有一節是講“源代碼就是設計”。這里講到了，寫源代碼和寫文章很類似。不過，本人雖然博學，但是對怎樣寫文章，這樣一門學問，確實沒什么研究。我希望，未來有這方面背景的程序員，能夠將文章學引入到程序員的世界來，這也是一件造福人類的事情！
??? 文學系的朋友們，你們論文的題目有了啊^-^

???????? 好了，廢話不說了，請看在下得拙著吧！
????????????????????????????????2006-06-23 于上海家中

??????????????? 目 錄
摘要…………………………………………………………………………………….I
ABSTRACT…………………………………………………………………………..II
1 什么是企業級應用?4
2 為什么我們需要開發健壯的企業級應用?6
3 什么是健壯的企業級應用?7
3.1 什么是健壯的企業級應用?7
3.2 企業級應用的一般結構?7
3.3 健壯的企業級應用的一般結構?8
4 怎樣開發健壯的企業級應用?11
5 面向對象編程技術?12
5.1 依賴于抽象，而不要依賴于具體實現?12
5.2 使用委派而不是繼承?13
5.3 “客戶—服務器”關系中，應該是“瘦”客戶類，“胖”服務器類?15
5.4 類存在的意義是提供的服務，而非保存的數據?15
5.5 單一功能的方法?17
5.6 單一職責的接口?18
5.7 用接口來隔離實現類?18
5.8 直接使用編程語言的概念進行設計?19
5.9 盡量使用模式來解決問題?19
6 面向方面編程技術?20
6.1 AOP的重要概念?22
6.2 實現AOP的主要技術策略?25
6.3 Spring AOP框架?27
6.4 如何更好的使用AOP?28
7 面向關注軟件開發?29
8 敏捷開發方法的代表作—XP?30
8.1 XP的前提?30
8.2 為什么需要XP?31
9 融合XP的軟件開發過程?32
9.1 獲取需求?32
9.2 測試驅動開發和驗收測試級重構?33
9.3 單元測試驅動開發和單元測試級重構?35
9.4 小結?36
10 使用Java開發企業級應用的參考架構?36
10.1 JavaEE?36
10.2 “經典”的JavaEE架構?36
10.3? Java開源軟件?38
10.4 不用EJB的簡單Java EE架構?38
10.5 使用“輕量級容器”的Java EE架構?42
11 總結?45
11.1 “源代碼就是設計”?45
11.2 總結?45
??????????????? 致? 謝?46
?????????????? 參 考 文 獻?46

什么是企業級應用
?企業級應用（Enterprise Applications），顧名思義，就是企業經營中需要使用的應用程序。又叫作企業信息系統（Enterprise Information System）或者管理信息系統（Management Information Systems）。其主要任務是最大限度的利用現代計算機及網絡通訊技術加強企業的信息管理，通過對企業擁有的人力、物力、財力、設備、技術等資源的調查了解，建立正確的數據，加工處理并編制成各種信息資料及時提供給管理人員，以便進行正確的決策，不斷提高企業的管理水平和經濟效益。可以說，它的涵蓋面是非常廣的，很難給它下一個確切的定義，但是我可以羅列一些個人的理解。[1]
?先舉幾個例子。企業級應用包括工資單、患者記錄、發貨跟蹤、成本分析、信譽評估、保險、供應鏈、記賬、客戶服務以及外幣交易等。企業級應用不包括車輛加油、文字處理、電梯控制、化工廠控制器、電話交換機、操作系統、編譯器以及電子游戲等。
?企業級應用一般都涉及到持久化數據。數據必須持久化是因為程序的多次運行都需要用到它們—實際上，有些數據必須持久化若干年。在此期間，操作這些數據的程序往往會有很多變化。這些數據的生命周期往往比最初生成它們的那些硬件、操作系統和編譯器還要長。在此期間，數據本身的結構一般也會被擴展，使得它在不影響已有信息的基礎上，還能表示更多的新信息。即使是有根本性的變化發生，或公司安裝了一套全新的軟件，這些數據也必須被“遷移”到這些全新的應用程序上。
?企業級應用一般都涉及到大量數據—一個中等規模的系統往往都包含1GB以上的數據，這些數據是以數百萬條記錄的方式存在的。巨大的數據量導致數據的管理成為系統的主要工作和挑戰！早期的系統使用的是索引文件系統，如IBM的VSAM和ISAM。現代的系統往往采用數據庫。數據庫有層次數據庫、網狀數據庫、關系數據庫和對象數據庫，還有對象—關系數據庫。現在最成熟，應用也最多的是關系數據庫。數據庫的設計和演化已使其本身成為新的技術領域。
?數據庫在企業級應用中處于重要的地位。選擇性能優良的數據庫和有效的使用數據庫，是開發企業級應用的一項核心工作！
?最近興起的使用XML文件存儲少量數據這一技術。實際上，XML文件格式，就是早期的層次數據庫。它具有豐富的表達能力和簡單的優點，但是數據庫發展的歷史已經表明，XML文件不可能取代現在的關系數據庫和對象—關系數據庫。
?企業級應用一般還同時涉及到很多人同時訪問數據。對于很多系統來說，人數可能在100人以下，但是對于一些基于Web的系統，人數則會呈指數級增長。要確保這些人都能夠正確地訪問數據，就一定會存在這樣或那樣的問題。即使人數沒有這么多，要確保兩個人在同時操作同一數據項時不出現錯誤，也是存在問題的。事務管理工具可以處理這個問題，但是最為程序員，我們仍然要正確地使用它們，這同樣不容易做到。
?企業級應用還涉及到大量操作數據的用戶界面。有幾百個用戶界面是不足為奇的。用戶使用頻率的差異很大，他們也經常沒什么技術背景。因此，為了不同的使用目的，數據需要很多種表現形式。
?企業級應用也很少單獨存在，通常需要與企業的合作伙伴的企業級應用集成。這些各式各樣的系統是在不同時期，采用不同的技術開發的。甚至連通訊機制都不相同：基于Socket的系統、CORBA系統、COM系統、Java的RMI、EJB和消息系統，以及最新的Web Service等。企業經常希望能夠用一種同一的通信技術來集成所有的系統。然而，每次這樣的集成工作都很難真正實現，留下來的就是一個個風格各異的集成環境。
?即使是某個企業統一了集成技術，他們還是會遇到業務過程中的差異，以及數據庫中數據概念的不一致性。不同部門、不同系統，甚至不同時期，都會對業務數據有不同的定義和理解。
?隨著企業級應用的發展和集成，整個企業的企業級應用程序就成了一個不同技術、不同數據混雜在一起組成的復雜系統。不斷的修改和添加新功能，也使系統的Bug越來越多，修改和添加新功能變得越來越困難。
?對于一些人來說，“企業級應用”這個詞指的是大型系統。但是要注意，并不是所有的企業級應用都是大型的，盡管它們可能都在為企業提供巨大的價值。

為什么我們需要開發健壯的企業級應用
?開發企業級應用程序并不是一件簡單的事情，開發出一個能令客戶滿意的企業級應用程序更非易事。這需要考慮太多的事情、克服太多的難關—技術上、商業上、人際關系上的。
?事實上，企業級應用的主要成本和困難并不在開發軟件這個時期，而是在軟件的維護階段。企業級應用在其交付使用后，其維護階段在軟件生命周期或生存期中占較大比重，有的可達軟件生命周期總成本(TCO)的50-70%。因為，企業的業務環境一直處于不斷的變化之中，這就要求企業級應用也要能夠適應企業的變化。而這些可能的變化，對于開發者來說，是很難預見的。如果開發的企業級應用，其架構沒有很強的適應能力、不夠健壯的話，那么在維護階段修改軟件，或者增加新功能將是極其困難的，甚至是不能做到，必須推倒重來！
?業務需求的變化，才是企業級應用最大的風險和難點！而且，這種變化，基本上每個項目都會出現，這是企業級應用開發的“常態”。甚至，一般在軟件開發的過程中，就會出現業務需求的變化。
?現在，市面上有很多套裝的企業級應用，如ERP,CRM,財務軟件等。很多企業花了大價錢買了回來，但是應用下來，失敗的案例很多。不僅造成了軟件購置費用的浪費，更嚴重的是擾亂了企業正常的業務活動，造成了嚴重的損失。也使不少企業對信息化望而卻步。
?企業，作為市場經濟的主體，其面臨的內外部環境是在不斷變化的，企業本身也會針對這種變化，經常性的調整其組織結構和業務流程。并不存在適用于所有企業的一套一成不變的組織結構和處理流程。
?使用套裝軟件，就好比是“削足適履”，為了適應軟件的需要，改變企業原來運轉正常的組織結構和業務流程，實在是不智之舉。企業級應用程序，是為企業服務的，應當服從企業的需要，而不是相反，企業成了軟件的奴隸！
?IBM的廣告詞“隨需應變的軟件”，就是企業級應用軟件業者理想中的軟件。可是，依靠IBM，就能夠開發出“隨需應變的軟件”嗎？當然不可能，一切只能夠靠我們程序員自己才能做到！

什么是健壯的企業級應用
什么是健壯的企業級應用
?“隨需應變的軟件”，就好像是塑膠泥，我們可以任意拿捏，變化出不同的形狀。“隨需應變的軟件”，必然是健壯的軟件，不論怎樣折騰，都能夠應對自如。
?什么是“健壯的企業級應用”，對此我無法給出一個精確的定義，我只能夠羅列一些我的理解。
?“健壯的企業級應用”，其各個部分應該是低耦合、高內聚的。其內部的各個模塊之間的關系最低，且可以互相替換，從而可以方便地拆卸、替換和修改各個模塊。
?其核心思想，就是“接口”。各個部分之間通過接口，并且只通過接口互相銜接，一起合作。只要接口相同，那么這些模塊就可以互相替換。對于其他模塊來說，其合作部分的具體實現是不重要的。
?這樣，我們在需要“隨需應變”的改變軟件時，只要簡單的提供在原有系統上接插上不同的實現模塊即可。
?這實際上，就是面向對象（OO）思想的一種體現。更深入的說，就是“抽象”的思想。把具體的源代碼通過接口屏蔽、抽象起來。這樣，只要接口不變，那么無論源代碼怎樣變化，都不會影響整個軟件的正常運行。
?當然，不僅企業級應用需要“健壯”，任何軟件都應該是健壯的。但是，在企業級應用程序的開發和維護過程中，由于其需求的多變性，就更需要是“健壯”的。
企業級應用的一般結構
?現在，讓我們再來看一看企業級應用的結構。企業級應用在結構上，一般可以分為三大模塊：表現模塊，業務模塊，領域模塊。這里，我將它們稱作“模塊”，而不是“層”。很多人喜歡劃分“層次”，但我覺得劃分“模塊”更合適。因為，“層”有上下之分，只能是上層調用下層；而“模塊”就沒有上下之分，可以根據實際情況任意調用。這里，我不想分清什么是上層，什么是下層，用模塊來表示應該更加合適。
?一、表現模塊
?表現模塊，又叫作客戶端。用于向客戶提供使用軟件系統的途徑。一般有圖形用戶界面GUI，命令行界面，文本文件等等。這個模塊，僅僅是用來接收用戶請求，再將這個請求委派給業務模塊提供的方法（這就是業務模塊提供的服務），從而實現軟件的功能。一個軟件的好壞與否，與之無直接的關系。
?二、業務模塊
?業務模塊，封裝了為特定的業務需求提供服務的方法。表現模塊就是通過它提供的方法來實現業務需求的。所以，業務模塊是直接對應于系統的業務需求的，是系統的關鍵和最重要的部分。
?三、領域模塊
?也許你會問：既然業務模塊已經提供了客戶所需的功能，那么還要這個領域模塊干什么呢？其實，這個領域模塊就是為業務模塊服務的更底層的功能。
?在整個軟件系統中，存在一些實體。這些實體包含了一些數據和責任，它們的交互協作，就可以實現軟件系統的業務功能。
?實現一個個業務需求的業務模塊，可能需要這些實體中的一個或者多個的功能和數據。
?這些實體的集合，就是領域模塊。由此可見，領域模塊實際上才是整個系統的核心和靈魂。業務模塊也只有委托它們才能提供系統所需的業務功能。
健壯的企業級應用的一般結構
?健壯的企業級應用，在結構上又應該是怎樣的呢？
?一、表現模塊
?表現模塊僅僅是一個界面，用于向用戶提供使用系統的途徑而已。所以，盡可能“薄”的表現模塊，就是理想的表現模塊。“薄”的表現模塊，就可以在用戶想要改變用戶界面時，輕松的加以改變。改變用戶界面，是系統變化最多的需求。
?使用MVC模式設計的表現模塊，可以分為3個組成部分：M(Model)模型，V(View)視圖，C（Control）控制器。
?其中，模型，是一些類，它們封裝了視圖所要呈現給用戶的數據，也用來將用戶操作信息傳遞給后臺的控制器模塊。
?視圖，就是用戶界面，是用戶看到的那部分。它能夠接受用戶的請求，并將請求信息發送給控制器，再在控制器完成操作之后，從模型類中獲得數據，展現給用戶。
?控制器，它接收到用戶請求之后，就委托業務模塊的業務服務對象提供的服務，完成業務功能。如果有數據需要返回給用戶，就將數據存放到Model模型類中，以備視圖取用。控制器，雖然是表現層的一部分。但是，它實際上是“業務代表模式”的一種應用。所謂業務代表，是指在客戶端和業務服務層之間，增設一個“代表層”，所有客戶端到服務器的調用，都“委托”該層完成。[9]業務代表雖然身處表現模塊內，但實際上執行的是調用業務服務模塊功能的任務，完成的是業務功能。因此，不少人都將業務代表劃分在業務模塊內。我也認同這種劃分方法。至少，我們可以認為，它是橫跨表現模塊和業務模塊的一個部分。
?表現模塊中，模型和視圖兩部分通常都很小，而且它們是表現模塊固有的，不能夠省略，就算夠“厚”（比如，富客戶端技術），也沒辦法變小。
?實際上，我們說企業級應用的表現模塊太“厚”，都是指太“厚”的控制器。理想的控制器，只應該根據接收到的界面上不同的請求，調用業務模塊的不同業務服務，完成這些請求，然后將得到的數據塞進Model模型類即可。
?我們常常犯的錯誤，就是在控制器中塞進了太多的應該放在業務模塊的業務服務類中的代碼。實際上，判斷控制器是不是太厚，有一個非常簡單的方法：假設我們使用另一種表現模塊技術，那么，這個新的表現模塊中的控制器類中有多少代碼和現有的控制器是重復的。如果存在重復代碼，就使用“重構”技術，先將它們提煉成方法，然后再移到業務模塊的業務服務類中。這樣，我們就能夠得到一個理想的“瘦”表現模塊！
?二、業務模塊
?業務模塊，包括2個部分：一個是表現模塊的控制器，它是“業務代理”，提供的也是與業務相關的服務。我認為，把它劃分在業務模塊也許比表現模塊更加合適。另一個是業務服務模塊，我用Service表示它，它封裝了為特定的業務需求提供服務的方法。它與控制器配合，共同完成用戶需要的業務功能。
?既然理想中的控制器是“瘦”的，而且所有的重復代碼都移到了業務服務模塊中。那么，理想的業務服務模塊必然是“胖”的。
?實際上，控制器和業務服務模塊，是典型的“客戶—服務器模式”。控制器作為客戶，需要調用作為服務器的業務服務模塊提供的服務，來完成用戶需要的功能。所以，服務器越胖，提供的服務越多，那么系統的重復代碼就越少，功能也越強大！
?三、領域模塊
?業務服務模塊和領域模塊，實際上也是典型的“客戶—服務器模式”。業務服務模塊雖然提供的服務功能強大，很“胖”。但是，它的“胖”也是有限度的！它的“胖”來自于控制器中理應屬于它管轄的重復代碼。實際上，在“控制器模塊—業務服務模塊”這對“客戶—服務器”關系中，是控制器模塊“瘦”，而業務服務模塊“胖”。
?而在“業務服務模塊—領域模塊”這對“客戶—服務器”關系中，則是作為“客戶”的業務服務模塊“瘦”，而作為“服務器”的領域模塊“胖”。
?領域模塊，主要就是領域模型（也叫作業務對象Bussiness Object）。領域模型，封裝了業務實體的數據，還提供一些處理這些數據的服務（“服務”在編程語言中就是由方法提供的）。一般，在企業級應用中，有一些領域模型需要持久化存儲，就是保存到數據庫（關系型數據庫或對象數據庫）、文本文件、XML文件、序列化文件等持久地存儲起來，已備下次再用。這時，需要持久化的業務對象就需要對應的提供數據訪問服務的類（也叫作DAO,Data Access Object數據訪問對象）。
?這樣，一般的企業級應用的領域模塊，主要有兩個模塊：領域模型（Domain Model）和數據訪問服務模塊（DAO）。
?在“業務服務模塊—領域模塊”這對“客戶—服務器”關系中，
應該把業務服務模塊中所有可以移到領域模塊的領域模型類和數據訪問服務類中的代碼都移到領域模型類和數據訪問服務類中去。
?因為，業務模塊的控制器和業務服務模塊，它們與領域模塊的領域模型和數據訪問服務模塊之間的關系是“多對多”的關系。一個業務模塊可以使用零個或者多個領域模塊；一個領域模塊也可以被零個或者多個業務模塊所調用！所以，領域模塊越“胖”，提供的服務越多，業務模塊就越少重復代碼，系統的功能就越強大！
?現在，很多程序員都接受了UML的用例驅動開發的思想。誠然，用例驅動開發的思想確實很好，但是很多程序員都由此犯了一個毛病：他們常常按照用例為系統的源代碼分包（就是Java中的Package，.Net中的namespace），錯誤的將領域模塊的領域模型、DAO數據訪問服務類和業務模塊的控制器、業務服務類劃分在一個包里。實際上，領域模塊和業務模塊完全不同，它們并不是從屬于某一個用例的，而是屬于整個系統的，可以被多個業務模塊共同使用的。
?如果把領域模塊放在首次用到它們的業務模塊之中。那么我們就很難在其他業務模塊調用它們時很好的使用它們。因為，其他業務模塊的使用，可能會要求領域模型類和DAO類增加新的字段和方法。而將它們放在另一個業務模塊所在的包里，我們就很難將這些新增的功能放到領域模型類和DAO類中，使它們更“胖”。而是會傾向于在控制器類和業務服務類中增加方法。這樣，就會導致各個業務模塊中出現重復代碼，引發邏輯重復。
?
怎樣開發健壯的企業級應用
?企業級應用程序，按照是否能夠“隨需應變”來劃分，可以分為兩類：健壯的和脆弱的。
?畫一根數軸，我把它叫作“軟件健壯度”圖。“健壯”在正方向，“脆弱”在負方向。有很多技術原理和開發方法，可以讓我們的應用程序更加健壯，而違反這些原理和方法，我們的應用程序就會變得更加脆弱，修改和擴充新功能也更加困難。
?要想開發出健壯的企業級應用，首先需要的就是開發人員扎實的編程技能和對編程原理的清楚認識和應用。沒有高水平的開發人員，而奢談“健壯的企業級應用”，是毫無意義的。
?
面向對象編程技術
?面向對象編程技術(OOP,object-oriented programming)是近幾十年來編程領域最偉大的成就。健壯的企業級應用程序，甚至任何健壯的軟件，必須首先是一個很好的實踐了OO思想的軟件。脫離了OO，就不用奢談什么合格的軟件了！
?面向對象編程技術，早已經從昔日的神壇上走了下來。今天，任何一門主流的編程語言都是支持面向對象編程的。現在，幾乎所有的程序員都自稱已經掌握了面向對象編程的技術。但是，真正掌握OO的程序員卻遠遠沒有這么多。而且,面向對象編程技術還在飛速發展的過程中，我們還遠沒有發掘出它的全部內涵。
?并不是說，你使用了面向對象的編程語言開發軟件，你就能夠開發出實踐了OO思想的軟件。
?要想開發出健壯的企業級應用，我們需要的是全面皈依OO!
?面向對象編程的幾個原理[2]：
依賴于抽象，而不要依賴于具體實現
?具體來說，就是依賴于接口（Interface），而不要依賴于接口的具體實現類。或者是，依賴于父類（最好是抽象的），而不是具體實現的子類。又或者是，依賴于父接口，而不是子接口。總之，只使用提供了所需方法的最基本的類型。這樣，當程序需要改變時，我們就可以僅僅提供另一個“服務器”實現類或者實現子類，然后在“客戶類”新建實例的地方更換成這個新實現類即可，無須更換“客戶類”的調用代碼。在使用IOC(反轉控制)容器，如Spring框架時，我們甚至可以不用改動“客戶類”的任何代碼，而只需更改元數據（在Spring 框架中，是簡單的Xml文件），將舊的實現類的類名換成新的即可。
?使用越是抽象的接口或者類，我們可以選用的實現類也就越多！
?我們知道，在Java語言中有這樣幾種作用域：Private私有，Protected保護，Package包，public公共。按照“依賴于接口Interface”這一原則，我們又有了一個新的作用域：Publish已發布。接口Interface中聲明的方法就是已發布的。既然我們現在是通過接口來使用實現類的方法，那么就是說，即使實現類還有其他的Public可見方法，我們也不會調用它們。
?比如說，A類實現了B和C接口。調用A類的客戶代碼中，B b=new A()；這樣調用，那么我們通過對象b就只能夠調用B接口發布（Publish）的代碼，這也就保證了不會因為程序員一時的疏忽而造成了代碼不必要的耦合。如果需要改變B接口的實現，假設D類實現了B接口，只需要在客戶代碼中改成這樣：B b=new D()；就可以了。
?當然，凡事總有例外的情況。對于特別簡單，而且不大會改變的類，我們也可以直接使用實現類，而不是接口。如：表現層MVC模式中的Model模型類，還有領域模型類，它們主要是提供數據，只有很少的方法（set/get方法不算），而且不經常變化，所以一般我們直接使用它們，而不使用接口。
使用委派而不是繼承
?要讓一個類實現一些功能，有三種方法：
?1，在類中直接寫上實現功能的代碼。
?2，使用繼承。讓類繼承另一個類，從而可以使用另一個類的所有公共的和受保護的方法。
?3，使用委派。在一個類中，通過定義對象類型的實例變量，可以調用那些對象的方法，來提供功能。
?另外還有一種特殊的使用委派的方式—“回調模式”。就是在類的方法中聲明對象類型的參數，然后調用這個參數的方法來提供功能。在使用時，客戶類需要提供對象的實例作為參數傳給這個類。
?這三種方法中，對于沒有現存代碼的特殊功能，我們可以使用在類中直接寫上實現功能的代碼這一方法來實現。而在已經存在擁有可以使用的方法的類時，我們可以使用繼承或者委派使用它們的方法。
?如果我們使用繼承這種方式來獲得功能，那么我們就會獲得可能我們并不需要的大量的父類字段和功能。這樣的冗余，就會造成邏輯上的混亂。而且，Java只能夠進行單繼承，即，一個類只能夠繼承一個父類。這樣，一旦繼承了一個類，就剝奪了它繼承的能力。
?也許你會問，為什么Java要取消多繼承呢？因為，多繼承提供的好處遠比它造成的問題更多。如果2個父類的字段、方法同名怎么辦?而且，在邏輯上也會造成極大的混亂。
?繼承能夠做到的事情，委派一樣都能夠做到。而且做得更好！
?我們可以把所需的任務委派給任意多個類（別忘了，應該盡量使用接口Interface，最好用上IOC容器），然后在提供服務的方法中，使用委派對象的方法來實現。這樣，在邏輯上，我們能夠借助于這些類實現所需要的功能，而沒有實現增加不需要的字段和方法。
?所以，我們應該牢記“使用委派而不是繼承”這一條原則。當然，也還是有場合可以使用“繼承”的。
?1，一個類和另一個類是純粹的擴展關系，邏輯上沒有半點不符合的地方。如，幾何類和方形類。當然，這種情況下，使用委派仍然是可以的，而且更加保險。因為，常常有很多看上去非常像父子關系的類，實際上并不是真正的父子關系。父類可能有幾個子類不可能有的方法，這會成為一顆定時炸彈，在我們需要給子類增加相關方法時引發問題。
?2，模板方法模式（Template Method）[3]適用的情況下。當知道如何實現一個工作流程，但不知道所有單個步驟被如何實現時，使用模板方法模式比較簡單。[4]在父類（通常是抽象類）中提供一個工作流方法，然后再提供幾個工作流方法需要用到的方法的抽象方法原型。子類只需要覆蓋這幾個抽象方法，就能夠提供不同的實現效果。這種用法也叫作“多態”。
?但是，即使是這種情況，委派仍然能夠勝任，而且比繼承提供的解決方案更加靈活，只是稍微要復雜一些。這就是Strategy策略模式[3]。策略模式將不變的行為集中到一個接口中。用接口的實現類來實現具體的功能。
?“依賴于抽象，而不要依賴于具體實現”和“使用委派而不是繼承”這兩條原則，其思想都是相同的：不要為類提供不需要的能力。只要正巧夠用就行。與其他類通訊時，也只使用正巧夠用的服務。只有這樣，才能夠保證所有符合接口的類能夠被自由的替換成其他實現類。
“客戶—服務器”關系中，應該是“瘦”客戶類，“胖”服務器類
?在使用委派的類中。委派的類就是“客戶”類，被委派的類，就是“服務器”類（也有人把它叫作“助手類”）。在這樣一對關系中，應該盡量給客戶類“減肥”，而給服務器類“增肥”。因為，“客戶—服務器”關系中，客戶和服務器類一般是“多對多”的關系。變胖的服務器類可以在未來給更多的客戶類提供更好的服務，而原本會在客戶類這邊重復的代碼就都消失了。
?這個原理，就是處理“委派關系”中兩個類之間關系的一個原則。
類存在的意義是提供的服務，而非保存的數據
?對于類，最重要的是什么，一向都有爭議：有的認為，類存在的意義就是封裝的數據，有的認為，類存在的意義就是提供的服務（也就是方法）。我贊同后者的觀點。類存在的意義就是通過方法提供服務。而類保存的數據也需要通過set/get方法暴露出來。
?我們都知道這樣一個經典的公式：數據+算法=程序。而類就是同時封裝了數據及其相關算法的模塊。或者說是算法及其使用的數據的模塊。
?方法，是很早就出現的一個概念，在面向過程編程時代就是一個核心的概念，是那時最重要的抽象機制，它的出現，使我們第一次擁有了將具體實現代碼屏蔽了起來的能力。
?方法，提供了一個程序執行的點。在面向方面編程（AOP）中，叫作“連接點(join point)”。我們可以在方法調用的前后進行攔截，增加其他代碼。這是AOP面向方面的編程思想，在下面會詳細講解。另外，客戶代碼調用方法時，只需要給出方法名和參數，并不需要了解方法的實現，這也就給了“客戶—服務器”之間解除耦合的一次機會。方法的內部實現可以任意改變，只要不改變方法簽名即可。
?在OOP中，我們還可以使用這個接口的另一個實現類提供的另一個方法實現版本，來提供不同的服務。
?我們知道類是封裝了數據和方法的集合。其實，從用例驅動開發的角度來看，是類封裝了服務，然后服務需要使用一些數據，就把這些數據也封裝在了類中。
?我編寫類的方式，是“客戶—服務器”的方式。使用委派，也就是使用了“客戶—服務器”的方式來編程。首先，是用戶提供的用例（XP中叫作“用戶故事”）。但是用例太寬泛了，不足以支持編程工作的展開。于是，用戶再提供每個用例的具體的事件流。在XP中，是提供驗收測試，驗收測試中也包含了事件流。
?事件流，就是驅動我們開發的第一個“客戶”。理解了事件流，我們就可以畫出UML的序列圖。序列圖描述了系統的業務模塊提供了哪些服務，從而完成事件流。我們可以直接將序列圖的邏輯編寫成控制器類。控制器就是我們源代碼中的第一個“客戶”。它和業務服務Service類構成了“客戶—服務器”關系，可能也會和領域模塊的領域模型類構成“客戶—服務器”關系。
?在控制器類這個“客戶”中，我們已經實現了整個事件流的功能。只不過，有不少要調用的服務（也就是方法，不管是哪一個類的方法，控制器自己的方法，屬于Service業務服務類的方法或是領域模型類的方法等）還沒有實現。
?將這些服務按照邏輯和是否會在客戶端造成重復為標準，分配給各個模塊的各個類。按照“針對接口”編程的原則，將這些服務分發到各個接口中去，而不是實現類。
?現在，雖然程序還沒有開發完成，但我們已經知道程序在邏輯上已經完成了，或者說，已經設計完成了。我們只剩下兩項簡單的實現層面的工作要做：1，編寫服務的實現代碼；2，利用重構，將這些方法移到最適合的接口和實現類中去。
?“服務”是我們所需要的。我們用方法來實現服務。而方法又可能需要一些變量來保存狀態，其中有些狀態需要使用實例變量來保存。僅此而已！
?重構，其實總的思路也是盡量消除變量，特別是實例變量；盡量提煉出方法，而不使用變量。因為，變量是“實現”級別的，是直接的源代碼，是死的，不允許變化。而方法是“設計”級別的，是活的，只要方法簽名不變，其內部的實現代碼可以任意變化。而且，變量不是一個“程序執行點”，不可以攔截，而方法就可以攔截，如AOP面向方面編程，或者代理模式，裝飾者模式等的攔截。
?按照方法和數據的比例，類可以分為三種類型：只有數據和get/set方法的啞容器類，既有數據又有實際方法的一般類，只有方法沒有實例變量的類。
?1，只有數據和get/set方法的啞容器類
?它們僅僅是數據的容器。Martin Fowler將它們稱為“嬰兒類” [5]。作為一個起點，是可以的，但是它并不成熟。甚至，我們很難認為它們是真正面向對象的。但是，現實中，還是有不少這樣的類存在。比如MVC模式的表現模塊中的Model模型。它的任務就是封裝將要呈現給客戶的數據。還有，領域模塊的領域模型類，它封裝了業務實體的數據。但是，我們都可以在它們內部封裝一些使用這些數據的方法。
?總之，碰到這種只有數據和get/set方法的啞容器類，請特別留意，看是否能夠重構，讓它成為正常的類。
?2，只有方法沒有實例變量的類
?由于方法是編程世界的一等公民，所以這種類型的類是正常的，健康的，在現實世界還是非常普遍的。這些類，是提供了服務，但是服務的實現代碼不需要保存實例變量的類。像表現模塊（也許說它屬于業務模塊更貼切）的控制器類，業務模塊的業務服務Service類，領域模塊的DAO數據訪問服務類都是這一類型的類。
?這些類有一個優點，那就是它們不怕多線程的應用。因為它們不需要保存特定于線程的數據。所以，我們可以用單例模式來使用它們。即，整個應用程序中，只生成這些類的一個實例，用于為所有用戶的請求提供服務。JavaEE的Web容器中，Servlet就是單例的。Spring框架管理的類，也可以使用單例。
單一功能的方法
?在面向對象的開發方法中，接口、類、方法都需要對應于單一的邏輯概念。貫徹這一原則，就可以使接口、類和方法的數量變多、塊頭變小、關系變簡單、邏輯變清晰。重構的一大目標，就是將一個大方法編成多個小的單一責任的方法。單一責任的方法，很多都是重構的結果。
?OO的委派，實際上就是委派給其他類的方法來提供服務。優秀的OO軟件，就是一層一層的方法委派其他類（作為“服務器”的類）的方法來提供功能。其代碼的特點就是一個方法內部調用了幾個方法來實現功能，這些方法的名字就解釋了它們的功能。然后，這些被調用的方法內部又像這樣調用了一些方法。循環不已，直到最底層的充當“服務器”的類的方法中是調用API類庫的幾個方法而告終。
單一職責的接口
?一個設計上的邏輯概念，應該有且僅有一個提供對應邏輯的接口。這條原則就是類的內聚性原則：一個模塊的組成元素之間的功能相關性。Robert C. Martin把內聚性和引起一個模塊或者類改變的作用力聯系起來。[2]
?“就一個類而言，應該僅有一個引起它變化的原因”。接口也是類。所以，我們可以說“就一個接口而言，應該僅有一個引起它變化的原因”。實際上，一個實現類，是很難做到“僅有一個引起它變化的原因”的。而接口這個純設計層面的概念就不同了，它是可以真正做到“僅有一個引起它變化的原因”這一要求的。即使一個實現類能夠做到“僅有一個引起它變化的原因”，那也可能會造成實現類太小、太多的問題。而接口只包含方法簽名，并沒有實現代碼，所以，即使存在大量的接口也沒有問題。
?職責，就是“變化的原因”。如果你能夠想到多于一個動機去改變一個類或接口，那么這個類或接口就具有多于一個的職責。
?那么，為什么要把兩個職責分類到兩個單獨的接口中呢？因為每一個職責都是一個變化的軸線。當業務需求發生變化時，該變化就會反映為接口的職責的變化。如果一個接口承擔了多余一個的職責，那么引起它變化的原因就會有多個。
?如果一個接口承擔的職責過多，就等于把這些職責都耦合到了一起。一個職責的變化，可能會引起接口完成其他職責的能力被削弱。
?比如說，一個業務模塊的業務服務模塊有兩類業務服務，一類是提供增刪改查領域模型數據的服務，另一類是判斷數據完整性和正確性的服務。那么，這些服務就需要分別存放在兩個不同的業務服務Service接口中。這樣，在需求變化，從而導致服務改變時，我們可以只改變一個接口，而另一個接口及其所有客戶類都不會受到影響。
用接口來隔離實現類
?一個設計上的邏輯概念，應該有且僅有一個提供對應邏輯的接口。現實中，我們的實現類可能并不是這么純正的，可能，我們的實現類同時實現了很多個接口，這樣的實現類，叫作“雜湊類”。但是這并沒有多大的關系，因為這僅僅是一個“實現”級別的問題。我們仍然擁有一個純正的接口，我們在使用這個實現類的時候，是通過接口來使用的。這樣，雜湊類實現的其他接口的方法，我們并不會使用，也不能夠使用。接口的任何實現類都和“客戶”調用代碼無關！
直接使用編程語言的概念進行設計
?軟件開發的真正進步依賴于編程技術的進步，而這又意味著編程語言的進步。C++就是這樣的一個進步。它已經取得了爆炸式的流行，因為它是一門直接支持更好的軟件設計的主流編程語言。
?C++在正確的方向上邁出了一步，但是還需要更大的進步。[6]
?Java就是這樣一門比C++更加先進，更加面向對象的語言。Java可以更加有效的直接支持軟件設計。
?我們在進行軟件設計時，應該直接使用Java的概念來描述軟件系統，進行設計。這樣，我們就可以直接將設計轉化成實現。既然我們主張“針對接口編程”，那么，我們就應該主要使用“接口（Interface）”這個概念來描述系統。另外，既然我們更重視“服務”，也就是方法，那么我們就使用方法，而不是數據來描述接口。
?XP提出的CRC圖（Class,Responsibilities,Collaboration類、責任、類間關系）很符合我們的要求[7]。CRC圖，描述了一個類，我們這里通常是描述一個接口Interface。其中的責任，就是服務，也就是方法。它是接口的內在要求，是接口之所以存在的原因。類間關系，就是接口和其它接口之間的關系。接口之間互相協作，才能夠完成業務功能。
?我們在進行軟件設計時，不要考慮設計的具體實現的細節問題。我們只需要考慮接口應該提供那些服務，以及和哪些接口協作，怎樣協作即可。
盡量使用模式來解決問題
?內行的設計者們都知道：不是解決任何問題都要從頭做起。它們更愿意復用以前的解決方案。當找到一個好的解決方案，他們會一遍又一遍的使用它們。這些經驗是他們成為內行的部分原因。因此，你會在很多面向對象系統中看到類和相互通信的對象的重復模式。這些模式解決特定的設計問題，使面向對象設計更靈活、優雅，最終復用性更好。它們幫助設計者將新的設計建立在以往工作的基礎上。服用以往成功的設計方案。一個熟悉這些模式的設計者不需要再去發現它們，而能夠立即將它們應用于設計問題中。[3]
?給“模式”所下的定義是這樣的：
?自從1994年，GoF的劃時代名著《設計模式—可復用面向對象軟件的基礎》問世之后，在程序員世界引起了軒然大波。眾多的模式著作紛紛推出，涉及各個領域。其中，Martin Fowler的《分析模式：可復用的對象模型》和《企業應用架構模式》，以及Sun Java中心編寫的《J2EE核心模式》都是其中的上乘之作。另外還有很多特定領域的模式著作。它們搜集了特定領域的一些模式。
?今天，簡單的瀏覽這些模式書籍，我們就可以得到一大堆的專家級解決方案和經驗。
?實際上，使用模式來解決問題，并不需要你精研很多種模式，只需要你大致了解它們使用的場合，能夠在遇到這類問題時想起應該到哪里尋找對應的模式即可。模式，僅僅應該作為一個字典。
?但是，《設計模式—可復用面向對象軟件的基礎》這本書還是應該精心研讀。因為這本書中的23種模式，是最重要，應用最廣泛的模式。
?當然，凡事都不可太過，過猶不及！現在，有一些程序員凡事都以模式馬首是瞻，不分場合都要套用模式。我們應該注意到，用模式來解決問題，一般情況下都會增加軟件的復雜性。本來，一個類解決的問題，現在需要幾個類協作才能夠解決。所以，對于明顯簡單的功能，不宜使用復雜的模式。另外，一個軟件中不宜使用太多的模式。否則，會產生大量的類和類間的關系，使系統過于復雜。

面向方面編程技術
?面向方面編程AOP(Aspect-Oriented Programming)是1996年Gregor Kiczales在PARC提出的一種新的編程范式。AOP是一種與OOP截然不同的看待應用程序結構的方式，按照AOP的觀念，系統被分解為方面（aspect）而不是對象。
?OOP是一種成功的、極具表現力的編程范式，很多領域概念都可以自然的表達為對象，從而將其中通用的代碼模塊化。然而，還是有OOP照顧不到的角落。
?衡量OOP成功與否的標準就是它在多大程度上避免了代碼重復。
?代碼重復是最糟糕的代碼臭味。只要出現重復的代碼，必定有什么地方存在嚴重的問題—要么是設計有問題，要么是實現有問題。
?一般情況下，OOP能夠很好地避免代碼重復。具體繼承可以幫助我們在不同類型之間共享相同的行為；多態讓我們可以用同樣的方式處理不同類型的對象，將注意力集中到它們的共同之處。
?而委派，使類之間構成了“客戶—服務器”關系。客戶類代碼簡單的調用服務器類的方法即可完成眾多的功能“委派”。
?但是，有些時候，我們無法用OOP避免代碼重復，或者無法用OOP得到一個優雅的解決方案。
?就拿日志記錄來說吧。假設我們要對每一個控制器類的每一個方法調用都進行日志記錄。那么，使用OOP委派的編程風格，也就是使用“客戶—服務器”調用模式。我們需要在軟件的每一個控制器類的每一個方法中都增加一行調用Log日志記錄的代碼。盡管OOP委派已經很好的將記錄日志的服務封裝在作為“服務器類”的Log類中，但是，作為“客戶—服務器”調用模式，總是不能夠去掉客戶類中調用服務器的服務的代碼。如果很多個“客戶類”都需要調用“服務器類”提供的“服務”，那么“客戶類”中的調用代碼，就會不可避免的存在大量的重復。這是“客戶—服務器”這種客戶主調模式不可避免的弊端。
?當然，老實說，這類“客戶類”中的重復出現的調用代碼，并不是什么大不了的問題。存在這些重復代碼的軟件，照樣可以是一個比較健壯的軟件。這也正是我把OOP面向對象編程技術作為開發有效軟件的第一技術的原因。
?但是，今天，AOP面向方面編程提供了另一種調用模式，使客戶類能夠不需要調用代碼，就能夠獲得所需的功能！這樣，就完全消除了重復代碼。
?AOP的調用模式，就是好萊塢原則：“不要試圖聯系我們，我們到時候自會通知你。”這完全不同于OOP委派的“客戶—服務器”調用模式。OOP中，如果一個類（客戶類）需要另一個類（服務器類）提供的服務，就需要在客戶類的源代碼中顯式地加上調用代碼。而在AOP的“好萊塢原則”中，如果一個類（客戶類）需要另一個類（服務器類）提供的服務，那么就不需要在客戶類中作任何需要服務的聲明。而是在服務器類中指定需要將服務提供給哪些客戶類。
?用我們現實生活中的事情做個類比：
?我需要坐出租車，那么我就需要親自打電話去給出租車公司，調用它們的“服務”。這就是OOP委派的“客戶—服務器”調用模式的工作原理。出租車公司提供專業化的出租車服務，客戶只需要簡單的調用它們提供的服務。
?或者，我走在路上，隨地扔了一張廢紙。然后，清潔工會將這張廢紙撿走。這里，我并沒有主動要求清潔工提供服務，而是清潔工自己為我提供的服務。
?又或者，我每天走在公路上。但是，這條公路并不是我建造的，它的維修也和我無關。
?清掃垃圾，維修道路、橋梁，實際上是政府為公民提供的一項服務，或者叫作“基礎設施”，不管是有形的基礎設施，還是無形的基礎設施。
?政府提供“基礎設施”（如：清掃垃圾，維修道路等），和AOP的“好萊塢原則”原理是一致的。我把“好萊塢原則”稱作是“客戶—基礎設施”調用模式。“客戶”，就是實際上需要服務的類。“基礎設施”，就是為客戶封裝和提供服務的類（AspectJ這樣直接支持AOP的語言中，叫作“方面”，而在像SpringAOP這樣的OOP語言的AOP框架中，還是用一般的類來表示“基礎設施”）。“客戶—基礎設施”調用模式中，是“基礎設施”自己作用于“客戶”。“客戶”根本不知道有“基礎設施”的存在！
?基礎設施，又分為兩部分：封裝服務的類和指定該類為哪些客戶類的哪些方法服務的部分。
AOP的重要概念
?首先，讓我們來澄清AOP中的各個重要概念的定義。由于AOP興起時間不久，而且流派眾多，再加上國內翻譯又各異，所以在這些概念的定義上有很多不同的版本。[8]
?一、關注(concern)
?一個關注可以使一個特定的問題、概念、或是應用程序的興趣區間。或者說，是“涉眾”對應用程序的期望。涉眾，就是與程序有關的人或者物，如客戶，程序員，關聯系統，客戶端等應用程序的環境中的某些部分。總而言之，是應用程序必須達到的一個目標。
?日志、安全性、事務管理、性能要求、用戶管理、角色管理、角色授權管理等等，都是系統中常見的“關注”。在一個OO的應用程序中，關注可能已經被代碼模塊化了，也可能還散落在整個對象模型之中。
?實際上，“關注”不是AOP獨有的概念，應該是應用程序都有的一個概念。它有些類似于面向對象的UML圖中“用例”，或者是XP的“故事”。
?二、橫切關注（crosscuting concern）
?如果一個關注的實現代碼散落在很多個類或方法之中（如：日志、安全性檢查），我們就稱之為“橫切關注”。
?如果用OOP實現橫切關注，那么必然會造成調用代碼重復。如果我們使用AOP實現橫切關注，就可以讓客戶類中不必進行任何代碼調用。
?橫切關注，正是AOP的用武之地。
?三、方面(aspect)
?一個方面是對一個橫切關注的模塊化，它將那些本來散落在各處的、用于實現這個關注的代碼規整到一處。它一般包括兩個模塊：封裝服務代碼的模塊和指定該服務為哪些客戶類的哪些方法服務的 模塊。
?四、連接點(join point)
?程序執行過程中的一點。如：
?1，方法調用（method invocation）：對方法（可能包括構造器）的調用，不過并非所有AOP框架都支持在對象構造時的增強（advise）。
?這是最重要，最常用的連接點。我們在面向對象編程技術中曾經說過，重構的一大手段和目標就是構造大量的方法。因為，方法是一個連接點，是一個抽象，我們可以利用方法這一層抽象，任意的修改方法內的實現代碼。所以，我們的代碼中應該是大量存在方法這個蘭接點的。即使沒有，我們也可以在應用AOP編程時重構，在需要攔截的地方重構出一個方法，來作為連接點！
?有些AOP實現，如JBoss AOP，就只提供了方法調用這一種連接點。
?2，字段訪問(field access)
?讀或者寫實例變量。同樣，并非所有的AOP框架都支持對字段訪問的增強。那些支持這類增強的AOP框架都可以區分讀操作和寫操作。
?Spring AOP,JBoss AOP都不支持字段攔截。字段攔截是一種潛在的危險，它違反了OO的封裝原則。
?一般來說，我認為最好還是不要使用字段增強。OO程序中對字段的訪問，可以用set/get屬性這樣的方法調用來代替。AOP對字段的攔截，通常也可以通過方法層面的增強來代替，從而保持對象的封裝。
?3，異常拋出(throws)
?特定的異常被拋出。JBoss AOP框架只支持方法調用。但是，仍然可以通過編程獲得異常拋出。實際上，異常拋出這個連接點，是方法調用這個連接點的衍生品。能夠攔截方法，那么一定能夠攔截拋出的異常。
?五、增強(advice)
?這個術語有很多種譯法,羅時飛在《精通Spring》一書中譯作：“裝備”；Spring中文論壇在《Spring Framework開發參考手冊》中譯作“通知”，石一楹在《expert one-to-one J2EE Development without EJB中文版》一書中譯作“增強”。這里，我就把它稱作是“增強”吧！
?增強(advice)，是在特定的連接點執行的動作。很多AOP框架都以攔截器(interceptor)的形式來表現增強—所謂攔截器，就是這樣一個對象：當連接點被調用時，它會收到一個回調消息。增強的例子包括：
?1，在允許執行連接點之前，檢查安全憑證。如Spring框架的一個附屬開源項目Acegi，就是這樣一個使用Spring AOP攔截方法訪問的項目。
?2，在執行某個方法連接點之前開啟事務，在連接點執行完畢后提交或者回滾事務。Spring AOP框架提供了這個功能。
?六、切入點(pointcut)
?一組連接點的總稱，用于指定某個增強應該在何時被調用。切入點常用正則表達式或別的通配符語法來描述。有些AOP實現技術還支持切入點的組合。
?切入點加上增強，就是一個完整的方面，或者叫作“基礎設施”。可以實現橫切關注。
?七、引入(introduction)
?又譯作“混入”。指，為一個現有的類或接口添加方法或字段。這種技術用于實現Java眾多多重繼承，或者給現有的對象模型附加新的API。譬如說，可以通過引入讓一個現有的對象實現一個接口。
?八、混入繼承（mixin inheritance）
?一個“混入類”封裝了一組功能，這組功能可以被“混入”到現有的類當中，并且無需求助于傳統的繼承手段。在AOP這里，混入是通過引入來實現的。在Java語言中，可以通過混入來實現多重繼承。
?九、織入(weaving)
?將方面整合到完整的執行流程（或完整的類，此時被織入的就是引入）中。這是AOP的實現機制，AspectJ是使用預編譯器，在編譯之前通過生成代碼實現織入的，這叫作“靜態織入”。
?Spring AOP等AOP框架是在運行時通過動態代理生成匿名類的匿名對象的方式織入的。這叫作“動態織入”。
?十、攔截器（interceptor）
?很多AOP框架（例如Spring和JBoss 4，但不包含AspectJ）用它來實現字段和方法的攔截(interceptor)。隨之而來的就是在連接點（譬如方法攔截）處掛接一條攔截器鏈(interceptor chain)，鏈條上的每個攔截器通常會調用下一個攔截器。實際上，攔截是一種AOP的實現策略，而不是AOP的核心概念。
?十一、AOP代理(AOP proxy)
?AOP框架創建的對象，這個匿名類的匿名對象，它既委派目標對象完成目標對象的工作，也織入了攔截連接點的通知。在Spring AOP中，AOP代理可以是JDK動態代理或者CGLIB代理。
?AOP代理也并不是所有AOP實現都有的一個概念，它是Spring AOP框架和JBoss AOP框架等動態AOP框架愛實現AOP的根本方法。
實現AOP的主要技術策略
?AOP面向方面編程思想目前已經有很多種實現和實現方法。下面是用于實現AOP的主要技術策略：
?一、J2SE動態代理
?在Java中，實現AOP最顯而易見的策略莫過于使用Java1.3引入的動態代理。動態代理是一種強大的語言結構，它使我們可以為一個或多個接口“憑空”地創建實現對象，而不需要預先有一個實現類。
?如果需要用動態代理實現環繞增強，可以在其中調用必要的攔截器鏈。攔截器鏈上的最后一個攔截器將借助反射調用目標對象—如果有目標對象的話。
?動態代理最大的好處在于：這是一種標準的Java語言特性。除了AOP框架之外不需要第三方庫，也不會受到應用服務器的任何影響。
?動態代理的最大局限性在于：它只能針對接口進行代理，不能針對類。即，需要“客戶—基礎設施”中的客戶類實現所需的接口，然后在程序中使用接口來使用新的對象的方法。不過，既然我們主張“針對接口編程”，那么這項限制并不是壞事，反而能夠使程序員養成良好的“針對接口編程”的習慣。
?另外，動態代理只能對方法調用進行增強，而不能像AspectJ那樣對字段進行增強。不過，既然我們使用方法來提供所有的服務，那么“對字段進行增強”這項功能也就是完全無用的，反而會引起程序員使用不良的編程方法。
?Spring框架，默認時使用J2SE動態代理提供AOP實現。開發者也可以指定使用“動態字節碼生成”技術來實現AOP。Nanning框架也使用J2SE動態代理提供AOP實現。
?二、動態字節碼生成
?為了針對Java類提供代理，我們需要動態代理之外的工具，那就是動態字節碼生成（dynamic byte code generation）。在這方面，最流行的工具是CGLIB(Code Generation Library)。在Spring中，如果需要針對類（而不是接口）提供代理，就會用到CGLIB。它可以針對指定的類動態生成一個子類，并覆蓋其中的方法，從而實現方法攔截。
?不過CGLIB有一個小問題：因為它是通過繼承來實現代理的，所以無法為final方法提供代理。
?三、Java代碼生成
?最笨的方法，就是讓容器生成新的源碼。這種方法，最早大概是MTS微軟事務服務器采用的，后來的Java的EJB也采用了這種方法來提供“基礎設施”。雖然這種方法很笨。但是，它們確實是早期的AOP嘗試。現在，隨著動態代理和動態字節碼生成技術的出現，這種做法正在逐漸退出流行。
?另外，不得不補充一句：代碼生成，基本上都是最糟糕的編程技術。通常，我們都可以使用OOP的委派或者AOP來達到相同的目的。自動生成代碼，將會在需要修改代碼時引起眾多可怕的問題!微軟是用了不少自動代碼生成技術，另外MDA模型驅動開發方法和基于元數據的產生式編程都是常見的源代碼生成技術。對于這些技術，我一直都抱著懷疑的態度！只要還有其他的方法可以實現目標，我是絕對不會使用源代碼生成這種技術的！
?四、使用定制的類加載器
?使用定制的類加載器，我們可以在一個類被加載時自動對其進行增強。即便用戶使用new操作符構造實例，增強仍會生效。JBoss AOP和AspectWerk都采用這種做法對類進行增強，具體的增強信息則是在運行時從XML配置文件中讀取。
?這種做法的風險在于：它偏離了Java的標準。在某些應用服務器中，這種做法可能會導致問題，因為J2EE服務器需要控制整個類加載的層級體系。
?五、語言擴展
?如果我們希望把方面當作一等公民來對待，就需要一種同時支持AOP和OOP的語言。為了達到這個目的，可以對現有的OO語言進行擴展，就像C++擴展C語言、引入OO的概念那樣。最早出現的AOP實現AspectJ就對Java進行了這樣的擴展。
?AspectJ是功能最強大的AOP實現。但是，它是一種新的語言，語法比Java更復雜。而且，還需要使用AspectJ的預編譯器首先編譯AspectJ源碼，將它們變成增強后的Java代碼，然后再進行Java的編譯，太過繁瑣。
Spring AOP框架
?在所有的AOP實現中，我認為Spring AOP框架是最好的選擇。盡管它使用的動態代理和動態字節碼生成技術實現的AOP功能并不是最強大的，但是對于大多數情況已經夠用，而且夠簡單，沒有任何特殊的要求。
?并且，Spring框架很好的整合了AspectJ，在必要的時候，我們可以使用AspectJ的強大能力來實現AOP。
?Spring AOP是用純Java實現的，它不像AspectJ那樣需要特殊的編譯過程，也不需要像JBoss AOP那樣需要控制類裝載器層次，因此適用于J2EE容器或應用服務器，也適用于任何使用Java的程序。不過，你的程序也必須要使用Spring框架來管理。Spring AOP只能夠為Spring框架管理的Java類提供AOP服務。
?Spring目前只支持攔截方法調用和異常拋出，不支持攔截字段訪問。
?Spring提供代表切入點或各種通知類型的類。Spring使用術語advisor顧問來表示代表方面(aspect)的對象。它包含一個增強(advice)和一個指定特定連接點(join point)的切入點(pointcut)。
?Spring AOP框架的目標并不是提供極其完善的AOP實現（雖然Spring AOP非常強大），而是提供一個和Spring IOC容器緊密結合的AOP實現，幫助解決企業級應用中的常見問題。
?因此，Spring AOP的功能通常是和Spring IOC容器聯合使用的。AOP通知是用普通的bean定義語法定義的。增強和切入點本身由Spring IOC管理—這是一個重要的和其他AOP實現的區別。
?有些事使用Spring AOP是無法容易或高效的實現的，如非常細粒度的對象，此時可以使用AspectJ。
?總的來說，Spring針對J2EE企業級應用中大部分能用AOP解決的問題提供了一個優秀的解決方案。
如何更好的使用AOP
?面向方面編程(AOP)為軟件開發提供了一種全新的視角—橫切的視角。讓我們看待軟件的視角從縱向的一維世界，變為平面的世界。也大大提高了我們開發軟件的能力。最近，AOP將會取代OOP的論調層出不窮。
?的確，AOP是一種不錯的編程范式和思考方法，但是，OOP才是編程的根本。AOP只是OOP的有益補充，它們之間不是對立關系，而是互補的關系。AOP絕對不會，也不可能替代OOP。兩者各有各的領地，而OOP的應用范圍更大！
?如果一個軟件，連最起碼的OO原則都沒有遵循，又怎么可能奢望依靠AOP來達到健壯的目的呢！
?現在，在一些程序員中有一種傾向，就是在編程中一門心思的應用AOP來編程。只要發現任何調用代碼重復，都要使用方面來解決。
?這就造成了程序中使用了太多的方面。整個程序的邏輯變得難以理解和修改。
?我認為，只應該在出現大量調用代碼重復的情況下，才應該使用AOP的“客戶—基礎設施”來解決，否則應該使用OOP的“客戶—服務器”模式。對于難以決定應該使用OOP還是AOP的場合，應該使用OOP。

面向關注軟件開發
?面向對象編程技術，是一種解決業務關注的編程技術。比如說，一個企業級應用，用戶需要用戶管理的功能，同時這個軟件的所有模塊都需要事務處理功能，日志功能和安全性檢查的功能。
?使用OO技術時，當我們要編寫實現用戶管理功能的代碼模塊時，我們得到的系統關注（UML稱作“用例”，XP稱作“用戶故事”），是：用戶管理模塊，需要有增加、刪除、修改和查詢用戶的功能。同時，所有的數據庫操作要有日志，要使用事務，要檢查安全性，只有符合條件的用戶才能夠調用這些管理功能。
?然后，我們根據這個業務關注，編寫出滿足這些要求的軟件模塊。其中，日志、事務、安全性檢查代碼都與其它業務關注的實現模塊出現了代碼重復。
?可以說，OOP是用縱向的一維的視角來看待軟件系統的。
?AOP則是一種解決橫切公共關注[9]的編程技術。對于上面例子中的日志、事務、安全性檢查等公共的關注，我們不是把它們分散到各個業務關注中，而是集中在一起，構成“橫切公共關注”，使用AOP的技術，在一個模塊，也就是方面內實現，各個業務關注根本不用知道還存在這些關注，當然，在實現業務關注的OO代碼中也不會體現這些橫切關注。
?我們可以看到，不論是OOP還是AOP，都只是一種編程的范式，是面向關注，解決關注的一種手段。
?但是軟件開發的根本是什么呢？就是“涉眾”的“關注”。軟件就是要滿足涉眾的關注，滿足了涉眾的關注，那么這個軟件就成功了！
?沒有“關注”，OOP和AOP就都成了無本之木，無源之水，沒有目標的箭。而企業級應用，最大的變數和風險，就是客戶的需求的變化，也就是系統“關注”的變化。面向關注的軟件開發(COSD,concern-oriented Software Development)，讓我們始終面向涉眾的“關注”這個根本的目標來開發軟件。也讓我們在“關注”的旗幟下，綜合運用OOP和AOP編程技術，分別解決縱向的業務關注和橫切的公共關注，相輔相成。
?面向關注軟件開發(COSD)的思想，是來自于AOP提出的概念“關注(concern)”，是重新審視OOP和AOP相互之間關系的思考結果。
?
敏捷開發方法的代表作—XP
?極限編程（Extreme Programming,簡稱XP）是目前討論最多、實踐最多、爭議也是最多的一種敏捷開發方法。XP是一套能夠快速開發高質量軟件所需的價值觀、原則和活動的集合，使軟件能以盡可能快的速度開發出來并向客戶提供最高效益。
XP的前提
?極限編程的假設：平滑成本曲線—變化的成本不會隨時間的推移而急劇上升。而非傳統中普遍認為的“變化的成本隨時間的推移而以指數方式上升”[7]。傳統的計算機科學家認為，對軟件的改變，會隨著項目時間的推移而變得越來越困難，其成本將是在項目開始初期就將這些需求考慮進來的幾十倍。這在過去，確實是軟件開發的事實。
?但是，隨著面向對象編程技術的發展，這一個假設已經變得不符合實際情況了！具有良好面向對象編程技術功底的程序員，完全可以開發出高內聚、低耦合，結構簡單，易于修改的健壯的軟件，其“成本曲線”是“平滑的”，而非“陡峭的”。即使在軟件完成之后，對軟件進行大規模的修改和添加新功能，也僅僅比在項目開始的時候明確定義這些需求增加極少的成本。
?所以，如果要使用XP取得成功，首先就需要能夠掌握本文前面章節介紹的那些方法，讓軟件的健壯度更高。可以說，XP對開發人員的要求是比較高的，需要有扎實的編程水平和面向對象的思想。
為什么需要XP
?那么我們為什么不在項目開始之前就確定所有的需求，而要在項目進行，甚至已經完成的時候修改軟件呢？如果能夠做到這一點，當然好，但是，現實中，我們常常無法做到這一點。
?1，程序員對于開發軟件是專家，但卻不是軟件應用領域的專家。而用戶雖然是軟件應用領域的專家，但是他們往往不清楚軟件能夠做到什么，不能夠做到什么，或者做一項工作的成本如何。由于開發人員和用戶對相互領域的不了解，所以在軟件實際開發出來之前，開發人員和用戶都無法清楚的定義軟件需要的功能。
?往往直到軟件被實際開發出來的，用戶試用之后，才能夠明白自己到底需要怎樣的軟件。特別是在企業級應用中，軟件開發完成之后，大規模的修改軟件是常事。
?2，隨著時間的推移，軟件應用的環境本身就在發生變化。特別是在企業級應用中，企業的業務環境一直處于不斷的變化之中，這就要求企業級應用也要能夠適應企業的變化。而這些可能的變化，對于開發者來說，是很難預見的。
?3，一般的軟件開發過程中，我們往往選擇分多個版本、階段開發軟件。就是首先開發一個初級的版本，發行。之后再在其基礎上添加其他功能。這是一般的軟件開發的策略。這也要求，我們不可能在軟件開發的初期就能夠考慮到未來若干年內我們軟件的全部需求。比如，Windows操作系統，這個軟件已經歷時十多年，發布了無數個版本。顯然，最初開發Windows的時候是不可能預見到今天的Windows的。
?總之，軟件開發過程中，需求的變化是必然的，絕對的。不變的需求是暫時的，相對的。
?面對不確定的未來，以前，我們一般基于“變化的成本隨時間的推移而以指數方式上升”這一假設，在項目開發的初期，想方設法的預測未來的種種變化，試圖抓住“不確定的未來”。但是，這常常是徒勞的。而且，這么做的結果，往往是把本來簡單的需求復雜化了。其中的很多需求，根本就是客戶所不需要的。
?譬如說，現在很流行遠程方法調用。很多程序員想當然的認為軟件將來需要提供遠程調用這樣的功能。他們花了大力氣來使用復雜的CORBA,Web Services,RMI,EJB等技術提供遠程調用功能，大大增加了軟件的開發成本，而實際上，大部分的軟件最后都沒有這樣的需求。而且，即使將來真的需要提供遠程調用的功能，對于設計良好的軟件，到時候再增加這種功能也非難事。
?簡單的軟件被搞復雜了，而客戶卻需要為并不需要的功能埋單！
?
融合XP的軟件開發過程
?如果我們在軟件開發中貫徹了那些開發健壯軟件的編程技術，使我們的軟件比較健壯，也就是說符合“平滑成本曲線—變化的成本不會隨時間的推移而急劇上升”這一實踐XP的前提，那么我們就可以使用極限編程方法來開發軟件，提高軟件開發的生產效率和商業價值。
獲取需求
?傳統的軟件開發方法把這個階段稱作“需求調研”。因為，按照傳統的方法，是開發人員調查研究軟件的需求。而XP不同，XP是讓客戶在軟件開發人員的引導下為開發人員提供軟件的需求。因為，程序員對于開發軟件是專家，但卻不是軟件應用領域的專家。顯然，對于軟件應該是什么樣的，客戶是更有發言權的。軟件的需求，理所當然應該由客戶來提供。
?一、初步提出軟件需求
?客戶提出軟件應該實現的功能，而開發人員則告訴客戶這些功能是否能夠實現，以及需要花費多少成本。由客戶最后決定需要實現哪些功能。
?這個階段，客戶提出的需求，不必深入到細節，只需要一個個粗略的需求。如果深入到細節，那么就會陷入傳統開發方法過份需求調研和分析的陷阱中。
?XP實踐之：小版本—將一個簡單系統迅速投入生產，然后以很短的周期發布新版本。
?XP將整個軟件分成多個小版本，多階段發行。客戶根據功能的優先級將功能劃分到多個版本中分批予以實現。但是，第一個版本，如果還沒有一個軟件的架構，那么這個版本需要實現哪些功能由開發人員決定。開發人員選擇那些便于搭建架構的功能，比如用戶管理，權限管理等功能，首先實現。
?二、版本開發中的軟件需求
??? 初步提出的軟件需求是大致的，概括的，還沒有深入軟件需求的細節。進入版本開發之后，我們需要客戶提供足夠的需求細節，以支持“需求驅動開發”。
?比如說，初步需求階段用戶管理這樣的需求，在版本開發階段，需要明確怎樣的用戶管理功能，比如，需要有增加、刪除、查看、修改用戶信息的功能。
?用UML表示，就是“用戶管理”用例。增加、刪除、查看、修改用戶這四個詳細的子用例，或者說是四個事件流。一旦程序員得到了確定的事件流，就可以以此為依據，畫出UML的“序列圖”，驅動軟件開發的展開。
?三、橫切公共關注
?開發人員從客戶提供的系統需求中，提取出公共的系統需求，譬如說，日志，訪問控制等。對于這些橫切公共關注，我們可以使用OOP的方式實現。編寫一個類來提供這些服務，然后在各個業務模塊中通過“客戶—服務器”模式，調用這個類的方法來使用這些公共關注的服務。
?或者，更進一步，使用AOP的方式實現。編寫方面來提供這些服務。通過“客戶—基礎設施”這樣的調用模式，在業務模塊并不知道的情況下，為它們提供這些服務。
測試驅動開發和驗收測試級重構
?極限編程的哲學思想是實證主義的哲學思想：“任何不能度量的事物都是不存在的”[4]。極限編程反對傳統開發方法重視過程和文檔的做法，主張快速的開發、構建、測試和部署軟件。認為，一切決策都應該基于軟件的實際運行結果，而不是無端的猜測。經常“問問電腦”[8]，而不是基于一種毫無證據的信念，這是XP人的基本編程原則。
?XP人首先就需要是一個皈依實證主義哲學的信徒。
?因此，XP的開發方法和過程，可以用這樣的公式來表示：
?軟件=測試驅動開發+重構。
?一、驗收測試驅動開發
?怎樣才能夠證明開發人員已經實現了一個客戶需要的功能呢？這就需要測試—驗收測試。驗收測試，是在用例實現之前由客戶在開發人員的幫助下編寫的。驗收測試，就是一段文字，用來驗證系統是否已經滿足客戶需求。
?開發人員可以根據這段文字，用規范的腳本語言來形式化的定義。通常，我們為每個應用程序編寫一套腳本語言。一般，我們使用XML文件的形式，或者是文本文件的形式。開發人員自己編寫一個簡單的程序，讀取這個驗收測試的文本文件，根據文本文件中的內容，調用軟件中相應的方法，予以執行。腳本語言和具體的方法之間的對應關系，由開發人員自己定義。
?實際上，驗收測試[2]，就是程序的一個用戶界面，是基于文本文件或者XML文件的一個用戶界面。是調用軟件核心業務邏輯的一個簡單界面。通過它，我們能夠知道軟件的核心業務邏輯是否運行正常。
?驗收測試是程序，因此是可以運行的。我們在軟件開發的過程中可以經常運行這些驗收測試，以保證軟件一直處于正確的狀態。
?而且，驗收測試沒有用戶界面，可以和單元測試一樣批量快速運行，把結果保存到文件里。
?驗收測試是關于一項軟件功能的最終可執行文檔。程序員可以閱讀這些驗收測試來真正的理解這些功能，從而明白應該怎樣來實現這些功能。驗收測試，本身就是“事件流”，程序員可以據此畫出“序列圖”，實現驗收測試驅動的軟件開發。
?通過驗收測試，驅動軟件開發，是XP推薦的軟件開發方法。
?二、“客戶—服務器”模式層層委派開發軟件
??? 我們使用“客戶—服務器”模式，通過層層委派的方式來編寫軟件。
?序列圖描述了系統的業務模塊提供了哪些服務，完成了事件流。我們可以直接將序列圖的邏輯編寫成控制器類（或者叫作“業務委派”, 所謂業務委派，是指在客戶端和業務服務層之間，增設一個“代表層”，所有客戶端到服務器端的調用，都“委托”該層完成。[10]）。
?控制器就是我們核心業務邏輯的第一個客戶。它和業務服務類構成了“客戶—服務器”關系，可能也會和領域模塊的領域模型類構成“客戶—服務器”關系。
?為了實現用戶請求的功能，我們在控制器中調用幾個方法來實現這個用戶需求。但是，現在我們還沒有任何可以使用的方法。我們現在照樣在控制器中寫上要調用的方法，盡管它們還沒有被編寫和實現。沒關系，以后會實現的！
?將這些方法按照邏輯和是否會在客戶端造成重復為標準，分配給各個模塊的各個類。按照“針對接口”編程的原則，將這些服務分發到各個接口中去，而不是實現類。
?我們可以使用CRC圖來幫助完成這個分配方法的工作。
?現在，雖然程序還沒有開發完成，但我們已經知道程序在邏輯上已經完成了，或者說，已經設計完成了。我們只剩下兩項簡單的實現層面的工作要做：1，編寫接口的實現類，實現所需的方法；2，利用重構，將這些方法移到最適合的接口和實現類中去。
?三、驗收測試級重構
?重構，就是“在不改變代碼外在行為的前提下，對代碼做出修改，以改進程序的內在結構”[5]。一旦編寫好代碼，對代碼的任何修改，都可以算是重構。
?重構總是和測試聯系在一起的。沒有自動化測試的支持，是不可能進行有效的重構的。按照所需要的測試，重構可以分為兩類：
?一是“單元測試級的重構”，也是大家使用最為廣泛的重構。但是，這類重構改善的只是軟件局部的質量，一般就是一兩個類的改善。
?另一種是“驗收測試級的重構”，這是改善整個模塊的質量的重構。它是對整個模塊實現機制的改善，常常涉及到多個接口和類的修改。
?在需求變化的過程中，依靠自動化的驗收測試，我們可以很容易的進行驗收級重構，快速地響應軟件需求的變化。也可以使軟件變得越來越健壯。
單元測試驅動開發和單元測試級重構
?在編寫具體的類時，我們也使使用“單元測試驅動開發”的。首先編寫測試類，然后再編寫實現類，逐個方法的完成單元測試，最后完成類的編寫。在需要改善類的實現代碼時，使用單元測試級的重構，改善類的內部結構。
?XP開發軟件，就是自頂向下，一層層的由測試驅動開發，在需要改善使，使用這些測試安全的進行重構。
小結
?最后，整個軟件的開發工作和軟件質量，都可以通過驗收測試和單元測試得到保障和度量。客戶可以隨時監控軟件開發的進展情況。客戶花的錢可以直接看到成果。而且，通過小版本快速迭代的發布，客戶可以及早的享用軟件開發的成果，也可以即時地終止不合算的軟件項目，而不會造成投入全部付之東流。
???
使用Java開發企業級應用的參考架構
?現在，讓我們使用Java實際的開發兩個企業級應用的參考架構。這個架構并不實現特定的業務需求，僅僅是兩個開發企業級應用的架構。這個架構是健壯的，易于修改的，也是符合“平滑成本曲線—變化的成本不會隨時間的推移而急劇上升”這一XP要求的。
JavaEE
?Java EE，Java平臺企業版（Java Platform Enterprise Edition）， 是Sun公司為企業級 應用推出的標準平臺。Java平臺共分為三個主要版本Java EE、Java SE和Java ME。原來，它們叫作J2EE、J2SE、J2ME。
?Java EE是使用Java進行企業開發的一套擴展標準。Java EE平臺提供了多層、分布式的應用模型，重新利用組件的能力，統一安全的模式以及靈活的處理控制能力。Java EE包括EJB, JTA, JDBC, JCA, JMX, JNDI, JMS, JavaMail, Servlet, JSP等規范[10]。
“經典”的JavaEE架構
?通常，人們認為Java EE是一種分布式平臺，EJB在該平臺中占有中心地位。“經典”的Java EE架構是這樣的[7]：
?1，Java類分散在不同的JVM中，雖然要想把這些類并置在一起、消除遠程調用的程中負載也是可以辦到的。
?2，Web層一般由一個MVC架構實現（其他架構方案也都是如此）。如果應用系統設計的比較精心，那么就會有一個專門的客戶端代理層，通過它調用遠程EJB,這樣就能夠干凈利落的解除web層和EJB之間的耦合。
?3，所有的業務對象都是帶遠程接口的無狀態session bean，運行在EJB容器中。EJB容器提供遠程調用機制、事物管理、線程管理，可能還有基于角色的安全服務。
?4，所有的數據訪問都要通過entity bean。Entity bean提供了O-R映射。
?5，EIS層由一個或多個數據庫或者遺留系統組成。如果存在多個帶事務的資源，通過EJB容器訪問的JTA服務會負責協調分布式服務。
?對于不準備提供EJB集群服務或者遠程調用EJB的企業級應用，也可以使用本地EJB。
?Java EE的這種架構提供了強大的遠程調用能力、JTA聲明式事務和聲明式安全等服務，以及集群部署EJB的能力。從而使Java在短短幾年時間內占領企業級應用市場。
?但是，這種架構在多年的實踐中，被發現了不少弱點：
?1，這種架構開發起來十分困難和低效。這主要是EJB規范太過復雜。按照EJB2.1規范的定義，EJB組件必須事先很多的接口， 比如Home接口、Remote接口、local 接口，等等．還要針對各種應用類型定義許多的xml描述文件。當我們需要訪問某個組件或者服務的時候，必須通過JDNI查找，通過名字綁定服務，才能找到我們需要的對象。
?2，運行起來也是十分低效的。Entity Bean的實現機制有問題，導致了Entity Bean訪問數據庫十分低效。甚至，目前很少有人采用Entity Bean來訪問數據庫。但是，如果不使用Entity Bean，Session Bean
使用其他數據庫訪問方式，則會存在一些問題。因為有些數據庫訪問機制，如Hibernate的Session Factory必須是單個實例的，而Session Bean中是無法實現單例的。
?另外，EJB的執行效率也比POJO慢。
??? 過去，人們認為EJB是Java EE的核心。但是，實際上，所有的Java EE服務，包括JTA,RMI,JNDI,JMS等，都可以脫離EJB容器來使用，它們實際上都是Web容器提供的功能，EJB容器只是提供了一種訪問這些服務的方法而已，我們完全可以不通過EJB而直接使用這些Java EE服務。
?Java開源軟件
?Java是一種開放的技術，它的發展，既由官方的JCP（Java Community Process)組織通過制定規范推動，也由Java開源社區推動。戰斗在一線的程序員，開發出了很多開源的Java軟件，這些軟件得到了很大的應用，極大地推動了Java的發展。我將使用這些開源軟件，結合Java EE提供的服務，不使用EJB，來開發企業級軟件。
?Struts是一種Web層開發框架，它是使用MVC模式實現的。目前，它是JavaEE領域中主流的Web層開發技術，不論使用EJB還是其他技術，一般都使用它來編寫Web層。
?Ant是java世界事實上的標準構建工具。它可以執行一系列的自動化任務，包括構建項目，運行軟件和自動化運行單元測試等。
?JUnit是XP創始人Kent Beck開發的一個單元測試工具。可以使用Ant自動化運行Junit測試。
?Hibernate則是事實上的O-R映射的標準框架。它通過xml文件配置，來映射數據庫表和Java程序中的POJO對象，通過同步緩存和數據庫，自動更新數據庫。它使我們可以像使用對象型數據庫那樣使用關系型數據庫。
?Spring框架，是一個輕量級的應用框架。Spring的目標就是提供一中貫穿始終的解決方案，將各種專用框架整合成一個連貫的整體。它可以整合Struts、Hibernate等框架，甚至簡化EJB的開發和訪問。
?Spring的威力來源于兩個方面：IOC容器和AOP框架。使用Spring框架，完全可以取代EJB的功能。
?這些開源框架，可以幫助我們實現非EJB的企業級應用。
不用EJB的簡單Java EE架構
?對于簡單的企業級應用，我們可以使用簡單的技術實現。這種架構，雖然簡單，但仍然很健壯。
?使用Struts作為Web層開發技術，使用POJO作為業務對象，使用DAO模式封裝的JDBC作為數據訪問層技術。通過DAO模式，我們也實現了簡單的O-R映射。
?一個典型的客戶用例的實現模塊中，我們的類分為以下幾個部分：
?1，Struts的控制器模塊Action，實際上，也就是“業務委派”模式的業務委派類。它們從視圖中接收用戶請求，然后調用業務服務類的方法實現用戶的請求。
??? Action和Servlet一樣，都是單例。也就是說，一臺機器上只有一個Action類的實例，為所有的客戶服務。也就是說，它不能夠保存客戶的狀態，因為狀態可以保存在HttpRequest、HttpSession、ServletContext里。
?2，Struts的MVC模式中的Model—ActionForm，它用于在Action和視圖之間傳遞數據。ActionForm中的數據，如果作為表單提交，需要是String型的。
?3，領域模塊的領域模型類。它是O-R映射中代表數據庫表的對象。也作為參數和返回值在控制器Action類和業務服務Service類之間，以及Service類和DAO類之間傳遞數據。
?在Action中，Action從視圖中拿到的數據容器類ActionForm并不能夠直接調用業務服務Service類的方法，必須要轉換為領域模型對象，或者簡單對象才能夠作為參數調用業務服務Service類的方法。
?Service類的方法返回的參數，也必須要封裝到ActionForm中才能夠讓視圖拿到顯示給用戶。
?4，業務模塊的業務服務Service接口及其實現類
?Service接口中封裝了Action要調用的所有業務操作。其實現類實現了這個接口。Service實現類是POJO，而不是session bean。
?Service類中要與數據庫交互的操作，都委派給DAO接口的實現類。
?Service實現類也應該是單例的，因為它只是提供服務，并不需要保存狀態。所有的數據都可以通過方法的參數傳遞進來。
?要實現單例，我們可以使用一個工廠類，也可以直接在Service實現類里提供單例的實現方法。這里，為了簡單，我在Service實現類里直接實現了單例。
public class JDBCMessageServiceImpl implements IMessageService{
?private static JDBCMessageServiceImpl instance=null;
?/**
* @return JDBCMessageServiceImpl 返回這個Service類的一個實例
??? */
?? public static JDBCMessageServiceImpl getInstance(){
??? if(null==JDBCMessageServiceImpl.instance){
???? JDBCMessageServiceImpl.instance=new JDBCMessageServiceImpl();
????? }
??????? return instance;
?? }
……
?5，領域模塊的數據訪問對象DAO接口及其實現類
??? DAO接口中封裝了持久化領域模型類的所有方法。通過DAO，我們實現了內存中的領域模型類和硬盤上的數據庫表之間的映射。這里，DAO的實現類是使用JDBC方式訪問數據庫的類。
?DAO實現類一樣是提供數據訪問服務的服務類，也應該是單例的。我們使用和Service類一樣的方式實現單例。
?在DAO實現類中，我們盡量使用領域模型類作為參數和返回值。這樣，就實現了領域模型類和數據庫表之間的O-R映射。在DAO實現類之外，我們可以使用領域模型類來操作數據庫表中的數據。
?這個架構中，我們在Service模塊和DAO模塊中都使用了接口—實現類這種方式。對于同一個接口，可以有無數個實現類。
?這里，我僅僅使用JDBC這一種方式實現DAO接口。實際上，我們可以很方便的編寫一個使用iBatis,Hibernate或者JDO等其他數據訪問技術的DAO實現類。
?另外，我們可以使用獨立于Web容器的連接池。
?我們可以使用Web容器的JNDI將實現連接池的數據源發布到JNDI上，客戶代碼從JNDI上得到數據源的實例，調用連接池中的連接。但是，不同的Web容器發布JNDI是很不一致的，而且獲得JNDI也是非常費事的。
?我們可以用Apache的DBCP框架，直接編寫連接池。這不需要任何Web容器的支持，可以在一般的Java程序中使用。
?如果需要遠程調用，我們可以在應用中集成Axis，提供Web Servics。
?如果需要集群部署，我們也可以在多臺服務器上部署多個Web應用程序。
?一、這個架構的優點
?1，不需要EJB容器，只需要Web容器即可，降低了成本。
?2，不需要EJB那樣累贅的部署描述符。
?3，容易在不同的Web容器和應用服務器之間切換。
?4，實現更加簡單，業務服務Service和數據訪問對象DAO都是簡單的POJO類。
?二、這個架構的缺點
?1，這里使用了直接的單例模式來生成單例，而不是使用容器管理來實現單例，代碼之間因而有一定的耦合。
?2，同樣，由于沒有容器管理對象的實例。所以，我們必須在客戶代碼中手工的調用接口實現類的創建單例的方法。這樣，在代碼中就出現了一定的耦合。如果需要改變實現類，我們就必須修改調用實現類的客戶的源代碼。
如，在Action中：
?ImessageService messageService=JDBCMessageServiceImpl.getInstance();
?另外，在Service實現類中，也需要得到DAO實現類的單例：
?public class JDBCMessageServiceImpl implements IMessageService{
?private IMessageDao messageDao=null;
?? public JDBCMessageServiceImpl() {
???? /*
????? 由于沒有元數據配置，所以，必須要在構造器中直接傳入類的實例。
????? */
???? setMessageDao(JDBCMessageDaoImpl.getInstance());
?? }
?……
?3，我們必須手工編寫事務，不能夠使用EJB容器提供的容器管理事務CMT。EJB的CMT允許用戶在配置文件中聲明使用事務，而不需要手工編寫事務。
?4，不能夠使用EJB提供的對Session Bean，Entity Bean的聲明性訪問控制。EJB提供的訪問控制，可以控制EJB方法的訪問權。
?當然，這個架構一樣可以通過Web Services的訪問控制機制實現這一點。而且，EJB雖然提供了聲明性訪問控制的機制，但是由于各個EJB容器都有不同的配置方法，移植起來十分困難，所以也很少使用。
?總之，這個架構是簡單、健壯、功能強大的。對于小規模的企業級應用完全可以使用這種簡單的架構。
?對于更大規模的企業級軟件，也許使用更加強大、復雜的技術框架，效率更高。比如說，使用Hibernate技術提供DAO實現類，或者更進一步，使用Spring框架來管理事務和業務對象的單例。
?由于這個架構在業務服務模塊Service和數據訪問模塊DAO中使用了接口和實現分離的方式，增加Spring、Hibernate等框架都是非常容易的。這也正反映了這個架構的健壯之處。
使用“輕量級容器”的Java EE架構
?“輕量級容器”，是指提供了管理、定位業務對象的方法。一般就是指IOC反轉控制容器。它實際上是提供了一個Dictionary類或相似的類，也就是名—值對的集合。在容器啟動時，它生成類的實例，然后放在這個字典內，當應用程序中需要這個類的實例時，如果聲明為單例，就從這個字典內按照名字取出對象。如果聲明為多例模式，容器就生成一個新的實例返回給客戶代碼。
?這樣就實現了單例。不再需要像上面那樣在一般的POJO類中編寫實現單例的代碼了。
?而且，現在，調用代碼中就只需要接口，不需要具體的實現類了。我們可以在配置文件中改變提供的實現類，不需要再修改源代碼了。
?Spring就是這樣一個輕量級的容器。Java EE的JNDI實際上也可以看作是一個容器。它是一個注冊表，也就是“名—值”對的集合。不同的是，它把這些對象放在了網上進行遠程發布。訪問JNDI對象是十分麻煩的。
?另外，Spring還提供了AOP框架，這可以讓它提供聲明式的服務，如，EJB容器那樣的聲明式事務等。而且，比EJB容器更加強大，可以自己編寫方面。
?Spring的IOC容器和AOP框架，讓它完全能夠替代EJB容器。比EJB容器更簡單，更強大。
?當然，還存在其他的IOC容器和AOP框架，但是目前只有Spring結合了這兩者。所以，這里我使用Spring來開發架構。
?一、使用“輕量級容器”的Java EE架構
?這個架構和前面那個不用EJB的簡單Java EE架構十分類似。這里，我們給予前面的架構進行修改，將它變為使用“輕量級容器”的Java EE架構。
?Web層，我們仍然使用Struts框架。業務服務模塊Service和數據訪問模塊DAO仍然使用POJO和接口—實現類分離的風格。在DAO的實現類中，我們為了演示Hibernate，所以增加了Hibernate的Dao實現類。當然，原來的基于JDBC的實現類一樣可用。
?首先，使用Spring以后，借助于Spring 的IOC容器，我們沒有必要再在Service和DAO實現類中提供創建單例的方法了，也沒有必要再在Service的實現類的默認構造其中創建DAO實現類的單例了。只需要空的構造器，然后再在配置文件中配置屬性，將DAO實現類的實例通過set方法傳進來即可。
?在Struts的Action類中，也不再需要直接用Service實現類的單例方法來獲得單例了，而是通過Spring的getBean(“*”)方法從Spring的注冊表中得到Service實現類的單例。即使實現類改變，也不需要改變源代碼，只需要修改Spring的xml配置文件即可。
?Spring提供了直接集成Hibernate的方法。可以將Hibernate的SessionFactory對象也置于SpringIOC容器的管理下，生成單例。
?Spring直接提供了幾個類，可以在xml文件中通過配置，聲明式的提供事務。不僅可以為Hibernate提供事務，也可以為我們前面架構中的JDBC實現提供聲明式的事務。如果我們使用的應用服務器提供JTA事務支持，Spring也可以通過聲明的方式提供JTA事務。
?另外，Spring還有一個子項目，Acegi Security System for Spring。這個框架是使用Spring AOP框架和Web容器的Filter機制，再加上本地線程變量ThreadLocal實現的一種安全機制。它在保護Web資源時，使用Web容器標準的Filter過濾器機制，在保護POJO類時，使用Spring AOP的聲明式保護，可以保護任何Spring管理的POJO的方法。這比EJB的聲明式安全機制更加強大，EJB只能夠保護EJB組件。
?但是，Acegi的安全機制比較復雜。如果是B/S應用，僅僅需要提供對Web資源的保護，建議不要使用它。它更適合對遠程調用的組件（如，Web Services,RMI,EJB,Hessian，Burlap和Spring Http Invoker等）的方法級訪問控制。
?二、這個架構的優點
?1，架構簡單，但是功能強大，甚至比使用重量級的EJB容器的經典架構更加強大。
?2，這種架構和不用EJB的簡單架構一樣，都可以通過部署多個應用程序，來實現集群部署。
?3，與不用EJB的簡單架構相比，本方案使用了一個輕量級的容器，這樣做并沒有增加多少復雜性，反而是減少了代碼，降低了復雜性。與EJB容器相比，當然是更加容易學習和配置。
?4，如果輕量級容器提供了AOP，那么就能夠提供比EJB更加強大的基礎設施和聲明式服務。
?5，這種架構不需要EJB容器。
?6，Spring已經提供了很多類，讓我們可以簡單的訪問很多Java EE服務，如JNDI，屬性文件等，都可以簡單的通過配置來完成。它還對一些常用的框架提供了支持，如iBatis,Hibernate等。通過Spring提供的Hibernate支持類，我們可以簡單的使用Hibernate，代碼量要比直接使用Hibernate少很多！
?7，由于我們不使用EJB容器的服務，也很少使用Web容器提供的服務，因此，我們的應用程序可以方便的在不用的應用服務器間移植。
?8，IOC可以讓輕量級服務器為你“組裝”對象。也就是說應用程序中不在需要編寫尋找或者生成合作對象的代碼了。比如說，Service實現類中已經不需要再生成DAO實現類的實例的代碼了。
?9，沒有這些組裝對象的代碼，我們仍然可以使用JUnit來測試我們的應用程序。因為輕量級框架可以在任何Java程序中運行。我們可以在Junit測試類中創建和使用Spring等輕量級容器。
?
總結
“源代碼就是設計”
?1992年，Jack W.Reeves寫了一篇論文《什么是軟件設計》，答案是“源代碼就是設計”！[2]
?源代碼編譯的過程，就是軟件實現的過程，而源代碼編寫的過程，就是軟件設計的過程。至于我們通常所說的分析軟件和設計軟件，只是對軟件設計過程之中的更高層次的分析和設計過程。它們分析和設計的仍然是源代碼這個真正的最終的設計文檔。
?源代碼，有兩類讀者，一類是編譯器，它將源代碼編譯成可以運行的軟件，它對于源代碼的唯一要求，就是符合語言規范，沒有語法錯誤。另一類，就是軟件的開發人員，他們需要經常地閱讀和修改源代碼。他們是普通的人類，只能夠理解組織優良，邏輯清晰的文字。顯然，源代碼最重要的讀者顯然是這些挑剔的人類。
??? 源代碼就是設計文檔，就是一篇關于軟件怎樣組織的說明文章。你讀過幾十萬行字的書嗎？如果你要寫一本幾十萬行字的書，那么怎樣才能夠讓讀者能夠很容易的閱讀、理解、然后修改呢？
?寫這樣一本書的要求，就是寫代碼的要求！顯然，我們編寫的代碼，應該組織合理，賦予邏輯，有足夠的抽象層次，能夠讓讀者一步步地深入到細節，而不是直接把細節全部拋給讀者。
?章，節，段，不是很像源代碼的包、類和方法嗎？
?健壯的軟件，就是開發者容易閱讀、理解，然后修改的軟件；就是結構簡單，邏輯清晰的軟件；就是經過了層層抽象的軟件，每一層都是結構簡單，邏輯清晰的！
?軟件技術的發展，就是對源代碼抽象能力的發展！
總結
?本文所論述的這些編程技術和軟件開發方法，不僅對于開發健壯的企業級應用有積極的意義，對開發所有類型健壯的軟件也一樣有意義。學習和實踐這些編程技術和開發方法，將會有效的提高我們編寫的軟件的質量和商業價值。
?
??????????????? 致? 謝
?
?本文是在劉文予教授的悉心指導下完成的。劉教授在理論、方法和實踐中都給予了我莫大的指導和幫助，使我在理論和實踐上有了很大的提高，順利完成了本篇論文。在此,謹向導師致以衷心的感謝。
?我還要感謝公司里的同事。
?還有James Gosling，感謝他為這個世界帶來了Java這門我最鐘愛的編程語言。Java改變了我的一生！
?同時,還要感謝我在華中科技大學求學期間，對我給予關心,幫助的所有老師和同學。
?最后，再次對所有關心、幫助我的老師、同學和同事表示衷心地感謝！
?
?
?????????????? 參 考 文 獻
?
?[1]? Martin Fowler. 企業應用架構模式. 王懷民 周斌 譯. 北京。機械工業出版社，2005年.
?[2]? Robert C.Martin. 敏捷軟件開發：原則、模式與實踐. 鄧輝 譯. 北京。清華大學出版社,? 2003年.
?[3]? Erich Gamma, Richard Helm, Ralph Johnson, et al. 設計模式：可復用面向對象軟件的基礎. 李英軍，馬曉星，蔡敏等 譯. 北京。機械工業出版社， 2005年.
?[4]? Rod Johnson.? J2EE設計開發編程指南. 魏海萍 譯. 北京。 電子工業出版社， 2003年.
?[5]? Martin Fowler. 重構—改善既有代碼的設計. 侯捷，熊節 譯.? 北京。 中國電力出版社， 2003年.
?[6]? Kent Beck. 解析極限編程—擁抱變化. 唐東銘 譯. 北京。人民郵電出版社， 2002年.
?[7] Rod Johnson, Juergen Hoeller.? Expert One-on-One J2EE Development without EJB中文版.? JavaEye 譯. 北京。 電子工業出版社， 2005年.
?[8]? Iver Jacoboson, Pan-Wei Ng.? AOSD中文版—基于用例的面向方面軟件開發.? 徐鋒 譯.? 北京。 電子工業出版社, 2005年.? .77-85
?[9]? Deepak Alur, John Crupi, Dan Malks.? J2EE核心模式、第二版.
???? 北京。 機械工業出版社， 2005年.? .218-227
?[10]? Mark Cade, Simon Roberts.? J2EE架構師認證指南. 武欣，羅云峰，劉侃 譯.? 北京。 機械工業出版社， 2004年.? .15-17

轉載于:https://www.cnblogs.com/armlinux/archive/2006/06/23/2391091.html

總結

以上是生活随笔為你收集整理的开发健壮的企业级应用的研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。