北京大學(xué)軟件工程國家工程研究中心建設(shè)概要

1、軟件體系結(jié)構(gòu)(Software Architecture)講義九：軟件框架構(gòu)造技術(shù)及案例分析內(nèi) 容軟件框架概述軟件框架研究現(xiàn)狀實例研究San Francisco商業(yè)開發(fā)平臺軟件構(gòu)造技術(shù)的發(fā)展創(chuàng)造性的活動60年代，匯編語言結(jié)構(gòu)化方法70年代，面向功能，面向數(shù)據(jù)面向?qū)ο蠓椒?0年代，軟件復(fù)用基于構(gòu)件方法軟件復(fù)用進一步發(fā)展軟件復(fù)用成為軟件構(gòu)造技術(shù)的研究熱點軟件復(fù)用技術(shù)（1/2）軟件復(fù)用是提高軟件生產(chǎn)力和質(zhì)量的一種技術(shù)，將已有軟件的各種有關(guān)知識用于構(gòu)造新的軟件，以縮短軟件開發(fā)和維護的花費代碼級復(fù)用領(lǐng)域知識、開發(fā)經(jīng)驗、體系結(jié)構(gòu)、需求、設(shè)計等的復(fù)用復(fù)用級別軟件復(fù)用技術(shù)（2/2）依據(jù)復(fù)用的組織方式個別的(A

2、d-hoc)復(fù)用復(fù)用在個人系統(tǒng)化的(Systematic)復(fù)用定義了復(fù)用過程和指南項目級別、特定領(lǐng)域抽象級別較高的產(chǎn)品復(fù)用系統(tǒng)化復(fù)用對于提高軟件的質(zhì)量和生產(chǎn)率具有更大的作用，也有較大的風(fēng)險軟件框架概念的出現(xiàn)Smalltalk-80開發(fā)環(huán)境中的框架Model-View-Controller (MVC)，被認為是第一個得到廣泛應(yīng)用的框架Apple Inc. User Interface Framework之后出現(xiàn)了一系列框架產(chǎn)品：Interview,ET+,Fire alarm system, (Taligent) CommonPoint, (IBM)San Francisco等等許多學(xué)者，包括J

3、ohnson, Pree, Bosch等對框架，尤其是面向?qū)ο罂蚣苷归_了大量研究，包括框架設(shè)計、框架實現(xiàn)、框架描述、框架復(fù)用、框架演化等軟件框架的概念軟件框架的定義和描述定義1 一個框架由一組協(xié)作類組成，闡明了整個設(shè)計、類間依賴及成員類的責(zé)任分布。楊芙清，97定義2 一個框架是有意義的相互協(xié)作的類的集合，它能夠同時表達針對一個特定領(lǐng)域?qū)崿F(xiàn)公共的需求和設(shè)計所需要的小尺度模式和主要機制。Firesmith, 94定義3 框架是一種微體系結(jié)構(gòu)，為特定領(lǐng)域內(nèi)的軟件系統(tǒng)提供未完全實現(xiàn)的模板。Jacobson, Booch, 99定義4 框架是指一個部分完成的軟件（子）系統(tǒng)，它將要被進一步實例化?？蚣芏x

4、了一個軟件系統(tǒng)族的體系結(jié)構(gòu)，并且提供了基本構(gòu)造單元?？蚣芡瑫r定義了針對特定的功能，需要在哪里進行調(diào)整和修改。Buschmann, 96定義5 一個框架是一個類的集合，它體現(xiàn)了針對解決相關(guān)問題家族的抽象設(shè)計。Jacobson, Foot, 88定義6 一個應(yīng)用框架，也稱為類屬應(yīng)用（Generic applications），是為特定應(yīng)用領(lǐng)域提供可復(fù)用結(jié)構(gòu)的協(xié)作類集合。Gamma, 95軟件框架的概念(續(xù))框架反映了一個領(lǐng)域內(nèi)應(yīng)用的軟件體系結(jié)構(gòu)，包括其組成成分、關(guān)系以及約束框架同時定義了針對特定的功能需要在哪里進行調(diào)整和修改因此，軟件框架1. 提供了創(chuàng)建具體應(yīng)用的基本構(gòu)造單元。2. 是一個部分完成

5、的軟件（子）系統(tǒng)，它將要被進一步實例化。框架的分類框架的分類根據(jù)應(yīng)用范圍分類基礎(chǔ)設(shè)施框架：GUI框架、語言處理框架中間件集成框架：ORB框架、消息中間件企業(yè)應(yīng)用框架：San Francisco根據(jù)復(fù)用方式分類白盒框架：MFC黑盒框架：Avalon項目框架的特性部分實現(xiàn)逐步實現(xiàn)，逐步具體化DSSA 框架 應(yīng)用DSSA是框架的高層設(shè)計，框架是抽象應(yīng)用框架的特性“反向控制”Hollywood Principle: Dont call us. Well call you.框架的特性固定點和擴展點對于面向?qū)ο罂蚣芏?，擴展點是抽象類框架特性相關(guān)概念領(lǐng)域工程框架體現(xiàn)了特定領(lǐng)域的需求，抽象了特定領(lǐng)域中一組應(yīng)

6、用系統(tǒng)的共性，因此領(lǐng)域分析是一種得到領(lǐng)域知識的較理想的方法產(chǎn)品線應(yīng)用框架是軟件產(chǎn)品線核心資產(chǎn)庫的重要組成部分，框架的設(shè)計和生產(chǎn)屬于產(chǎn)品線核心資產(chǎn)庫建設(shè)的范疇構(gòu)件庫從軟件構(gòu)造的角度來講，框架是一種大粒度的構(gòu)件?？蚣芘c構(gòu)件庫的區(qū)別框架不僅僅是類的簡單集合，而且定義了一個領(lǐng)域通用的高層設(shè)計構(gòu)件庫的結(jié)構(gòu)建立于構(gòu)件分類基礎(chǔ)之上，而框架則直接反映了問題域的結(jié)構(gòu)相關(guān)概念框架和體系結(jié)構(gòu)框架決定了應(yīng)用系統(tǒng)的體系結(jié)構(gòu)一個框架可以被實例化成為多個應(yīng)用系統(tǒng)，每個應(yīng)用系統(tǒng)具有特定的體系結(jié)構(gòu)，因此框架從框架使用的角度來看，框架和體系結(jié)構(gòu)之間存在著1對多(1:N)的關(guān)系從框架開發(fā)的角度來看，框架反映了一個領(lǐng)域的體系結(jié)構(gòu)（D

7、SSA），它是DSSA的一個實例，因此，DSSA和框架之間同樣存在著1對多(1:N)的關(guān)系從在軟件開發(fā)過程中所起的作用而言，體系結(jié)構(gòu)是軟件的高層設(shè)計抽象，它有助于系統(tǒng)開發(fā)團隊之間的交流DSSA是可以視為“參考”體系結(jié)構(gòu)，對于領(lǐng)域內(nèi)應(yīng)用系統(tǒng)體系結(jié)構(gòu)的設(shè)計具有指導(dǎo)意義而開發(fā)框架最重要的目的則是針對特定領(lǐng)域的設(shè)計和代碼復(fù)用相關(guān)概念應(yīng)用體系結(jié)構(gòu)、DSSAApplication(N)Architecture(N)DSSA(1)Framework111n實例化領(lǐng)域工程n1n1相關(guān)概念框架和軟件開發(fā)過程框架在整個軟件開發(fā)過程中屬于資產(chǎn)庫建設(shè)的范疇，是領(lǐng)域設(shè)計和領(lǐng)域?qū)崿F(xiàn)的重要制品之一基于框架的軟件開發(fā)活動可以

8、分為框架的設(shè)計和開發(fā)框架開發(fā)階段基于框架定制應(yīng)用系統(tǒng)框架使用階段框架演化和維護階段設(shè)計和開發(fā)一個框架成本高，但是通過復(fù)用帶來的效益也更加顯著框架本身是可復(fù)用資產(chǎn)，也有助于實現(xiàn)擴展部分的復(fù)用相關(guān)概念框架和設(shè)計模式從粒度上看，設(shè)計模式要小于框架，一個框架可以包括多個設(shè)計模式，但是設(shè)計模式不可能包括框架框架要比設(shè)計模式更加特化，框架總是與特定的應(yīng)用領(lǐng)域相關(guān)，而通常設(shè)計模式更加普通，可以應(yīng)用任何的應(yīng)用領(lǐng)域框架的設(shè)計、實現(xiàn)以及描述利用了設(shè)計模式相關(guān)概念框架與變化性控制框架體現(xiàn)了領(lǐng)域共性通過擴展點支持變化性 應(yīng)用程序框架構(gòu)件構(gòu)件構(gòu)件構(gòu)件構(gòu)件構(gòu)件構(gòu)件領(lǐng)域不變部分可變部分內(nèi)容軟件框架概念軟件框架構(gòu)造技術(shù)實例研

9、究San Francisco商業(yè)開發(fā)平臺軟件框架構(gòu)造技術(shù)軟件框架的開發(fā)過程模型開發(fā)過程中的相關(guān)技術(shù)研究領(lǐng)域分析擴展點設(shè)計框架實現(xiàn)和測試框架的描述框架的測試和維護框架的演化白盒黑盒框架Visual Builder框架的開發(fā)軟件框架的開發(fā)過程模型領(lǐng)域分析領(lǐng)域模型，DSSA，標識變化性捕獲框架需求識別框架問題域內(nèi)的擴展點和固定點框架設(shè)計框架SA設(shè)計，擴展點設(shè)計，固定點設(shè)計框架實現(xiàn)和測試框架文檔化應(yīng)用分析應(yīng)用設(shè)計應(yīng)用實現(xiàn)新的需求、需求變化或更好的領(lǐng)域理解框架文檔領(lǐng)域分析共性和變化性當(dāng)在某個領(lǐng)域而不是單個系統(tǒng)考慮問題時，就會發(fā)現(xiàn)一些特性是領(lǐng)域中所有系統(tǒng)共同具有的，而其它特性只是個別系統(tǒng)具有所有系統(tǒng)都具有

10、的特性是該領(lǐng)域中系統(tǒng)的本質(zhì)特性，體現(xiàn)為該領(lǐng)域中系統(tǒng)的共性只是部分或者個別系統(tǒng)具有的特性則體現(xiàn)為領(lǐng)域中系統(tǒng)的變化性變化性分類時間上的變化性和空間上的變化性時間上的變化性：產(chǎn)品隨著時間的變化解決產(chǎn)品的演化問題空間上的變化性：產(chǎn)品家族中產(chǎn)品間的區(qū)別解決產(chǎn)品的復(fù)用問題問題域的變化性和解空間的變化性問題域的變化性主要來自于業(yè)務(wù)領(lǐng)域、客戶、用戶對領(lǐng)域應(yīng)用系統(tǒng)需求的變化業(yè)務(wù)策略：實現(xiàn)什么功能？解空間的變化來自于系統(tǒng)設(shè)計、實現(xiàn)技術(shù)、系統(tǒng)運行環(huán)境的變化實現(xiàn)機制：怎樣實現(xiàn)功能？變化性分類（續(xù)）變化性模式必須的(Mandatory)需求：所有現(xiàn)有系統(tǒng)都具有這類需求可選的(Optional)需求：部分現(xiàn)有系統(tǒng)具有這類

11、需求，并非全部系統(tǒng)都具有多選一的(Alternative)：只能從多個變化項選擇其中一個滿足需求，這些變化項存在互斥關(guān)系多選多的(Multiple Parallel Variability):這些變化性之間不存在互斥的關(guān)系，可以同時存在變化性維度組織機構(gòu)、數(shù)據(jù)、功能、過程問題域?qū)崿F(xiàn)技術(shù)解空間擴展點（1/3）為什么需要擴展點支持應(yīng)用領(lǐng)域的變化性提高框架的靈活性提高框架的可復(fù)用性什么是擴展點擴展點是軟件框架中針對應(yīng)用需求的、支持適應(yīng)性變更的的擴展機制擴展點是定義良好的框架特性，可以通過特例化或者組裝等擴展機制來滿足特定應(yīng)用的需求擴展點OOF面向?qū)ο罂蚣苤兄饕褂靡韵录夹g(shù)實現(xiàn)擴展功能繼承組合委托參數(shù)

12、化 擴展點OOF(續(xù))模板方法（Template method）:定義不變流程調(diào)用鉤子方法實現(xiàn)共性的領(lǐng)域知識鉤子方法（Hook method）:定義變化的部分實現(xiàn)特定應(yīng)用的特殊需求定義為抽象方法擴展點OOF(續(xù))元模式THhook1:1 Connection PatternTHhooks1:N Connection PatternTHhook1:1 Recursive Connection PatternTHhooks1:N Recursive Connection PatternTHhook1:1 Recursive Unification PatternTHhook1:N Recursiv

13、e Unification PatternTHUnification Pattern擴展點CBF構(gòu)件接口調(diào)用接口定義和實現(xiàn)的分離支持構(gòu)件功能的特定行為、算法和實現(xiàn)插件支持特定算法和行為的動態(tài)加載和執(zhí)行構(gòu)件的參數(shù)化支持構(gòu)件對事件和狀態(tài)變化的響應(yīng)擴展點CBF插座插件模板抽象構(gòu)件外觀擴展點CBF構(gòu)件組裝參數(shù)化組裝：運行參數(shù)、配置文件、腳本程序消息機制：消息中間件代理：樁方式、適配器、容器、Web Service機制擴展點CBF腳本消息機制Web Services容器小結(jié)OOF和CBF的不同面向?qū)ο罂蚣軝C制：面向?qū)ο蠹夹g(shù)的多態(tài)和繼承機制復(fù)用方式：通過繼承框架中的抽象類來完成特定行為的定制，白盒復(fù)用問題

14、：框架的過度增值、脆弱的基類和隱式體系結(jié)構(gòu)基于構(gòu)件的框架機制：構(gòu)件接口調(diào)用、構(gòu)件組裝等復(fù)用方式：通過一些集成機制得到對象或者構(gòu)件的不同組裝，來定義特定行為的，黑盒復(fù)用框架描述語言（1/6）框架文檔必須包含的內(nèi)容框架的目的明確框架針對的問題域，以及框架為問題域的哪些問題提供了解決方案如何使用框架框架得到正確使用并發(fā)揮最優(yōu)效果的關(guān)鍵所在應(yīng)用實例閱讀實例是理解框架主要結(jié)構(gòu)的方法框架使用者可以從一組實例中看出框架的邊界和不足框架的設(shè)計描述表達框架的整體體系結(jié)構(gòu)和擴展點的設(shè)計細節(jié)框架描述語言（2/6）Cook Book途徑類似“菜譜”的、一步一步講述如何使用框架使用自然語言，舉例說明框架的使用，易于理解

15、對框架設(shè)計的描述不充分MVC Cook Book方法、 MacApp Cook Book方法、 Active Cook Book方法框架描述語言（3/6）模式途徑主題（Motif）方法每一個主題描述一個待解決的問題，給出不同的解決方案適合描述框架如何被使用面向?qū)ο笤O(shè)計模式方法面向?qū)ο笤O(shè)計模式描述了部分的面向?qū)ο笤O(shè)計，并不適合表達一個面向?qū)ο罂蚣艿耐暾O(shè)計框架描述語言（4/6）結(jié)構(gòu)化語言途徑框架描述語言（FDL）類似于C+函數(shù)說明形式化的框架實現(xiàn)語言以及實現(xiàn)模板沒有給出框架的設(shè)計描述基于XML語言比較全面地給出了框架中的關(guān)鍵實體、實體的性質(zhì)以及實體之間的關(guān)系對框架如何使用的描述不充分框架描述語言

16、（5/6）UML擴展途徑UML-F采用一系列布爾類型的標識值來描述面向?qū)ο罂蚣苤械娜N變化點：可變方法、可擴展類和可擴展接口variable標記值表示可變方法extensible標記值表示可擴展類dynamic和static標記值分別表示運行時配置或者非運行時配置的需求appl-class標記值表明一個類是否特定于應(yīng)用incomplete用來表示可擴展接口框架描述語言（6/6）框架描述途徑比較CookBook模式途徑主題 OO模式框架描述語言XML語言途徑ULMF框架的目的好好差差差差如何使用框架好好好一般一般好應(yīng)用范例好好差好好差設(shè)計細節(jié)的表達差好好差一般好框架總體結(jié)構(gòu)的表達差一般好差一般一

17、般框架的測試（1）框架測試的主要目的是驗證開發(fā)完成的框架是否滿足領(lǐng)域分析階段的需求測試活動：單元測試：針對固定點集成測試：框架是否覆蓋了所針對的領(lǐng)域構(gòu)件之間的協(xié)作是否正確框架擴展點實現(xiàn)是否正確 除了框架本身的測試，框架文檔也是其中重要測試內(nèi)容，需要驗證框架文檔是否正確的描述了框架擴展點框架的測試（2）由于框架是針對復(fù)用開發(fā)的軟件制品，它并不是完整的應(yīng)用系統(tǒng)，因此在進行測試時，需要采取以下策略：通過開發(fā)驅(qū)動模塊調(diào)用框架接口，測試框架對外提供的功能在進行集成測試時，最有效的措施就是在領(lǐng)域中選擇一個有代表性的應(yīng)用系統(tǒng)進行構(gòu)造，測試基于框架能否完成目標系統(tǒng)，即框架的可復(fù)用性。從這個角度來看，框架的復(fù)用

18、過程也是框架的測試過程，一個被復(fù)用多次的框架，其正確性將有顯著提高框架的維護（1）框架維護首要的目標是通過改善框架結(jié)構(gòu)，提高框架性能以及可復(fù)用性，即完善性維護，原因：框架作為一種可復(fù)用資產(chǎn)，內(nèi)部錯誤比例將隨著不斷復(fù)用大大降低框架是針對特定領(lǐng)域的，其設(shè)計已經(jīng)考慮了變化性，具有較高的靈活性，可以通過框架擴展以實現(xiàn)需求的變化框架的維護（2）一系列重構(gòu)（Refactoring）活動有助于實現(xiàn)框架的完善性維護，所謂重構(gòu)，是指在不改變可觀察行為的前提下，對軟件內(nèi)部結(jié)構(gòu)的改變，目的是使它更易于理解并且能夠更廉價地進行改變針對面向?qū)ο蟮能浖蚣?，Opd92OJ93中總結(jié)了三類高層的重構(gòu)方式抽象類重構(gòu)：為具有一

19、部分相同屬性的類C1和C2創(chuàng)建一個抽象基類 子類重構(gòu)：將一個復(fù)雜的類分解成幾個小一點的具體類和一個表達抽象的基類 聚合類重構(gòu)：識別聚積和部件 框架的演化（1/2）應(yīng)用框架的演化過程模型 框架的演化（2/2）框架演化過程中需要考慮的問題：識別具有演化趨勢的模塊識別框架各版本之間改動較多的模塊，這些模塊應(yīng)該是下一個版本中最可能被重構(gòu)的模塊確定框架發(fā)布的適當(dāng)時間避免由于已發(fā)布的產(chǎn)品不符合功能和質(zhì)量需求而造成的不必要的維護費用變化影響分析框架的演化對下一個版本的影響和基于前一個版本開發(fā)的應(yīng)用的影響，變化影響分析結(jié)果可用來預(yù)測框架演化帶來的維護工作量需求管理預(yù)測增加新的需求的成本，決定是否在框架實例或新

20、版本框架中加入新需求框架構(gòu)造原則單一責(zé)任原則開放-封閉原則Liskov替換原則依賴倒置原則接口隔離原則單一職責(zé)原則（SRP）內(nèi)容就一個類而言，應(yīng)該僅有一個引起 它變化的原因，這條原則被稱為內(nèi)聚性原則。一般地，內(nèi)聚性是指一個模塊組成元素之間的功能相關(guān)性。 在本條原則中，把內(nèi)聚性和引起一個模塊或類的改變的作用聯(lián)系起來。為了理解這一原則，首先要回答什么是職責(zé)？在SRP中，把職責(zé)定義為：引起變化的理由a reason of change）。根據(jù)這一定義，顯然可知：如果能夠想到多個（1）動機來改變一個類，那么這個類就具有多于一個的職責(zé)。實踐中，人們很習(xí)慣以“組”的形式來考慮類的職責(zé)。例如： 一個接口“調(diào)

21、制解調(diào)器”有四個功能：interface modem public void dial (string pno); public void hangup ( ); public void send (char c); public void recv ( ); 這顯然違背了SRP原則！原因是，根據(jù)職責(zé)的定義，可以認為該接口有兩個職責(zé)：連接處理 public void dial (string pno); public void hangup ( );數(shù)據(jù)通信 public void send (char c); public void recv ( );是否將這2個職責(zé)分離取決于應(yīng)用程序變化的

22、方式：如果應(yīng)用程序的變化會影響連接函數(shù)的聲明（signature）, 那么調(diào)用send和recv就必須重新編譯，因此應(yīng)分離這兩種職責(zé)。如果應(yīng)用程序的變化總是導(dǎo)致這兩個職責(zé)同時變化，那么就不必分離這兩種職責(zé)。耦合職責(zé)的分離就上一個例子而言，可以把2個職責(zé)分離為：interfaceData Channal+send(:char) +recv( ):charinterfaceConnection+dial(pno:String) +hangup( )Modem Implementation其中，可以把ModemImpiementation類看作是一個雜湊物（kludge），通過分離它們的接口，解耦了

23、概念。所有的依賴關(guān)系都與ModemImpiementation類無關(guān)。除了main外，誰也不知道它的存在。持久化問題- 左圖給出了一種常見的違反該原則的情況其中，類Employee包含了業(yè)務(wù)規(guī)則和持久性控制。這2個職責(zé)在多數(shù)情況下不應(yīng)該合在一起。因為業(yè)務(wù)規(guī)則往往會不斷的變化，并且變化的原因也各不相同。處理：1）測試驅(qū)動的開發(fā)實踐，往往會避免這種情況發(fā)生，即迫使對這2種職責(zé)進行分離。2）如果出現(xiàn)了這種情況，可以使用FAADE和 PROXY模式對設(shè)計進行重構(gòu)，分離這2種職責(zé)。 Employee+CalculatePay +StorePersistence Subsystem結(jié)論SRP是最簡單的一個

24、原則，但也是最難運用的原則之一；在設(shè)計中，人們會自然地把職責(zé)合在一起；軟件設(shè)計真正要做的許多內(nèi)容，就是發(fā)現(xiàn)職責(zé)，并把這些職責(zé)相互分離。本質(zhì)上，其它原則都是以這種或那種方式回答第3個結(jié)論： 即分離職責(zé)。開放-封閉原則(The Open-Closed Principle,OCP)兩截門（Dutch Door）-一個被水平分割為兩部分的門，這樣的每一部分都可以獨立保持開放或關(guān)閉。 -美國英語傳統(tǒng)字典，第4版，2000年內(nèi)容：軟件實體（類、模塊、函數(shù)等）應(yīng)該是可擴展的，但是不可修改的。這一原則是Bertrand Meyer在1998年提出的。提出這一原則的背景之一：Ivar Jacobson曾經(jīng)說過：

25、“任何系統(tǒng)在其生存周期中都會 發(fā)生變化。如果期望開發(fā)的系統(tǒng)不會在第1版本后就被拋棄， 必須牢牢記住這一點?！弊裱@一原則開發(fā)的軟件具有以下特點：“對于擴展是開放的”（open for extention）這意味著模塊的行為是可以擴展的。換言之，可以改變模 塊的功能?！皩τ诟淖兪欠忾]的”（closed for modification）這意味著對模塊行為改變時，不必改動模塊的源代碼或 二進制代碼。模塊的二進制可執(zhí)行版本，無論是可鏈接的 庫、DLL或Java的.jar文件，都無需改動。 怎樣才能做到看起來似乎矛盾的以上兩點？關(guān)鍵的是抽象！不允許修改的模塊，通常被認為是具有“固定”行為的模塊。抽象基

26、類以及可能的派生類，就能夠描述一組任意可能行為的抽象體。模塊可以操作一個抽象體。由于模塊依賴一個“固定”的抽象體，因此它對于更改可以是封閉的；但通過該抽象體的派生，可以擴展該模塊的行為。例如，ClientServerClient類是既不開放又不封閉的類 （ 其中， Client 類和Server類都是具體類）實現(xiàn)OCP的一種結(jié)構(gòu)：Clientinterface Client InterfaceServerSTRATEGY模式：既開放又封閉的Client 其中，ClientInterface類是一個擁有抽象成員的抽象類。 Client 類使用這個抽象類，但Client 類的對象卻使用Server

27、類的派生類的對象。因此，如果希望Client 對象使用一個不同的服務(wù)器類，那么只需從ClientInterface類派生一個新的類，而無需對Client 類進行任何改動。Client 類需要實現(xiàn)一些功能，可以使用ClientInterface的抽象接口來描述這些功能。 ClientInterface的子類型可以以任何方式來實現(xiàn)這個接口。這樣，就可以通過創(chuàng)建ClientInterface的新的子類型的方式來擴展、更改Client 中指定的行為。實現(xiàn)OCP的另一結(jié)構(gòu)：Policy+PolicyFunction() -ServiceFunction()Implementation-ServiceFu

28、nction()Template Method模式：既開放又封閉的基類 其中，Policy類具有一組實現(xiàn)了某種策略的共有函數(shù)。和上圖中的Client類中的函數(shù)類似，這些策略函數(shù)使用一些抽象接口描述了一些要完成的功能。不同的是，在這個結(jié)構(gòu)中，這些抽象接口是Policy 類的一部分。它們在C+中表現(xiàn)為純虛函數(shù)，在Java中表現(xiàn)為抽象方法。這些函數(shù)在Policy的子類型中實現(xiàn)。這樣，可以通過從Policy類派生出新類的方式，對Policy中指定的行為進行擴展或更改。 以上兩個模式是滿足OCP原則最常用的方法。應(yīng)用它們，可以把一個功能的通用部分和實現(xiàn)細節(jié)清晰地分離開來。結(jié)論在許多方面，開發(fā)-封閉原則（

29、OCP）都是面向?qū)ο笤O(shè)計的 核心。遵循這一原則，可以帶來巨大好處-靈活性、可復(fù)用 性以及可維護性。不是使用了面向?qū)ο笳Z言就是遵循了這一原則。對應(yīng)用程序中的每一部分肆意地使用抽象，同樣不是一個好的主意。正確的做法是，開發(fā)人員應(yīng)該僅對呈現(xiàn)頻繁變化的那些部分做出抽象。其中，“拒絕不成熟的抽象與抽象本身一樣重要的”。Liskov替換原則( LSP)在C+和Java這類語言中，支持抽象和多態(tài)的關(guān)鍵機制是繼承（inheritance）。正是使用了繼承，才可能創(chuàng)建實現(xiàn)其基類中抽象方法中的派生類。是什么設(shè)計原則支配這種特殊的繼承用法？最佳的繼承層次的特征是什么？怎樣的情況會使創(chuàng)建的類層次陷入不符合OCP？ 以

30、上正是LSP原則要回答的問題。 內(nèi)容： 子類型必須能夠替換掉它們的基類型。 這一原則是Barbara Liskov在1988年首先提出的。 “若對每個類型S的對象o1, 都存在一個類型T的對象o2, 使得在所有針對編寫的程序P中，用o1,替換o2后，程序P行為功能不變，則S是T的子類型。 ” 若違反這一原則，會出現(xiàn)什么后果？例如：假定有一個函數(shù)f，它的參數(shù)指向某個基類B的“指針”或“引用”。同樣，假定有B的某個派生類D，如果把D的對象作為B類型傳遞給f，就會導(dǎo)致f出現(xiàn)錯誤的行為。那么D就違反了LSP。顯然，D對于f來說是脆弱的。違反 LSP，常常以違反OCP的方式使用運行時的類型辨別（RTTI

31、）而導(dǎo)致的。這種方式往往是顯式地使用一個if 語句或if/else來確定一個對象的類型，以便可以選擇該類型的正確行為。考慮以下程序：struct Point double x,y;struct Shape enum ShapeType square,circle itsType;Shape(ShapeType t):itsType ;struct Circle:public Shape Circle():Shape(Circle) ; void Draw() const; Point itsCenter; double itsRadius; ; struct Square:public Sha

32、pe Sqaure():Shape(Sqaure) ; void Draw() const; Point itsTopLeft; double itsSide; ;void DrawShape(const Shape& s) if (s.itsType=Shape:square) static_cast(s).Draw(); else if (s.itsType=Shape:circle) static_cast(s).Draw(); 顯然，該程序中的DrawShape函數(shù)違反了OCP它必須知道Shape類所有的派生類，且每次創(chuàng)建一個Shape的派生類都必須要更改它。其原因是， Square類

33、和Circle類是Shape的派生類，具有函數(shù)Draw（）， 但沒有重寫（override） Shape 中的函數(shù)。由于Square類和Circle類不能替換Shape，所以DrawShape函數(shù)必須檢查輸入的Shape對象，確定它的類型，繼之調(diào)用函數(shù)Draw（）。 Square類和Circle類不能替換Shape，這違反了LSP，從而使DrawShape違反了OCP。還有其它一些方式，可以引發(fā)違反Liskov替換原則。例如：is A關(guān)系的使用-沒有把子類中那些不具有多態(tài)性的函數(shù)聲明為虛函數(shù)；基于契約設(shè)計的使用-派生類違反了有關(guān)基類的約定。在派生類的方法中填加了其基類不能割舍的異常結(jié)論：LSP

34、是使OCP成為可能的主要原因之一。正是子類型的可替換性，才使使用基類的模塊在無須改變的情況下可以予以擴展。這種可替換性必須是開發(fā)人員可以隱式依賴的東西。因此如果沒有顯示地強制基類類型的契約，那么代碼就必須良好地并顯式地表達出這一點?！癷s-A”的含義過于寬泛，以至于不能作為子類型的定義。子類型的正確定義是“可替換性的”，這里的可替換性可以通過顯式或隱式的契約予以定義。依賴倒置原則( DIP)內(nèi)容：高層模塊不應(yīng)該依賴低層模塊。二者都應(yīng)該依賴抽象。抽象不應(yīng)該依賴細節(jié)。細節(jié)應(yīng)該依賴抽象。該原則是框架設(shè)計的核心原則層次化Booch曾經(jīng)說過：“所有結(jié)構(gòu)良好的面向?qū)ο髽?gòu)架都具有清晰的層次定義，每個層次通過

35、一個定義良好的、受控的接口向外提供一組內(nèi)聚的服務(wù)?！睂σ陨线@句話的簡單理解，可能會出現(xiàn)以下結(jié)構(gòu)：Policy LayerMechanism LayerUtility Layer這一結(jié)構(gòu)存在一個潛伏的錯誤特征： （1）Policy layer對于其下一直到 Utility Layer的改動，都 是敏感的。 （2）這種依賴是可傳遞的。 -結(jié)論：這一結(jié)構(gòu)是不好的！合適的模型應(yīng)該是：PolicyMechanism UtilityPolicy LayerinterfacePolicy Service InterfaceMechanism Layerinterface Mechanism Service

36、InterfaceUtility Layer每個較高層次為它所需要的服務(wù)聲明一個抽象接口，較低層次實現(xiàn)這些抽象接口；每個較高層次都通過抽象接口使用下一層。這樣1）高層就不依賴低層，而低層則依賴高層；2）不僅解除了其中的傳遞依賴關(guān)系，而且還解除了高層與其它層的依賴關(guān)系。倒置的接口所有權(quán)問題這就是著名的Hollywood 原則“Dont call us, well call you.”即低層模塊實現(xiàn)了在高層模塊中聲明并被高層模塊調(diào)用的接口。依賴于抽象這是解釋DIP規(guī)則的一個啟發(fā)式規(guī)則。該規(guī)則建議不應(yīng)該依賴具體類-即程序中的所有依賴關(guān)系都應(yīng)該終止于抽象類或接口。根據(jù)這個啟發(fā)式規(guī)則，可知：任何變量都不

37、應(yīng)該持有一個指向具體類的指針或引用；任何類都不應(yīng)該從具體類派生；任何方法都不應(yīng)該覆寫它的任何基類中已實現(xiàn)的方法。注意：在編程中，有時必須要創(chuàng)建具體類的實例，而創(chuàng)建這些實例的模塊將會依賴它們。這說明程序中一般都會出現(xiàn)違反啟發(fā)式規(guī)則的情況。如果一個具體類不太會改變，且不會創(chuàng)建其它類似的派生類，那么依賴它也不會造成損害。這說明對那些穩(wěn)定的具體類而言，啟發(fā)式規(guī)則似乎不大合理。如果具體類是不穩(wěn)定的，且還不想直接依賴之，則可以把它們隱藏在抽象接口之后，以隔離它們的不穩(wěn)定性。依賴倒置規(guī)則可應(yīng)用于任何存在一個類向另一個類發(fā)送消息的地方。違反依賴倒置原則的例子：Button+poll()Lamp+turnOn(

38、)+ turnOff()這是一個以Button控制Lamp的系統(tǒng)。其中，Button類直接依賴Lamp對象，這個設(shè)計不能讓Button控制其它設(shè)備。該設(shè)計方案就違反了DIP，即應(yīng)用程序的高層策略沒有與低層策略相分離，自然使抽象依賴于具體細節(jié)。其對應(yīng)的Java如左所示。什么是高層策略？它是應(yīng)用的抽象，是那些不隨具體細節(jié)而改變的“真理”。它是系統(tǒng)內(nèi)部的系統(tǒng)-隱喻(metaphore)Button+poll()interfaceButtonServer+turnOn() + turnOff() Lamp通過倒置對Lamp的依賴關(guān)系，可以形成以上的設(shè)計。 其中，由接口ButtonServer提供一些抽

39、象方法，Button可以使用這些方法對有關(guān)設(shè)備進行控制。由Lamp來實現(xiàn)接口ButtonServer。 這樣的設(shè)計就具有很好的靈活性。但問題是Lamp可能還受其他類的控制。但由于Lamp實現(xiàn)了接口ButtonServer，所以就做不到這一點。結(jié)論：使用傳統(tǒng)的過程化設(shè)計所創(chuàng)建的依賴關(guān)系結(jié)構(gòu)，策略是依賴于細節(jié)的。這樣會使策略受到細節(jié)改變的影響。面向?qū)ο蟪绦蛟O(shè)計倒置了依賴關(guān)系的結(jié)構(gòu)，是策略和細節(jié)都依賴抽象，并且通常是客戶的服務(wù)接口。這種依賴關(guān)系的倒置，正好是面向?qū)ο蟮臉酥舅?。依賴倒置原則是實現(xiàn)許多面向?qū)ο蠹夹g(shù)所宣稱的那些益處的低層機制。它的正確應(yīng)用對創(chuàng)建可復(fù)用的框架是必須的。同時對建造具有彈性的代

40、碼（應(yīng)對變化）是非常重要的。應(yīng)用該原則可以做到抽象和細節(jié)彼此分離，因此代碼也易于維護。接口隔離原則( ISP )內(nèi)容：不應(yīng)強迫客戶（client）依賴它們不用的方法。解決的問題：ISP原則用來處理“胖接口”所帶來的缺點。何謂胖接口？如果類的接口不是內(nèi)聚的，則稱該接口是胖接口。換言之，類的胖接口可以分解為多組方法，每一組方法服務(wù)于一組不同客戶程序。接口污染問題考慮一個安全系統(tǒng)。其中有一些Door對象，可以加鎖和解鎖，并且知道自己所處的狀態(tài)（開/關(guān)）。class Door public: virtual void Lock()=0; virtual void UnLock()=0; virtual

41、 bool IsDoorOpen()=0; 顯然，這是一個抽象類?？蛻舫绦蚩梢允褂梅螪oor的那些接口對象，而不依賴Door的特定實現(xiàn)。 現(xiàn)在考慮這樣一個實現(xiàn)-TimedDoor.其中，如果門開著的時間過長，就會發(fā)出警報。為此， TimedDoor對象需要和一個名為Timer的對象進行交互。即如果希望得到超時時間，就可以調(diào)用Timer的Register函數(shù),該函數(shù)有2個參數(shù)：一個是超時時間，另一個是TimerClient對象的指針，該對象的TimeOut函數(shù)會在達到超時時予以調(diào)用。 現(xiàn)在的問題是，如何建立類TimerClient和類TimedDoor之間的關(guān)聯(lián)，才能在超時時通知TimedDo

42、or中相應(yīng)的處理代碼？下面給出了一種可想到的方案：TimerDoorTimedDoorInterface Timer Client+Timeout0.*其中，Door繼承了Timer Client，因此TimedDoor也繼承了Timer Client，這就可以保證TimerClient把自己注冊到Timer中，并可接收TimeOut的消息。 現(xiàn)在的問題是，如何建立類TimerClient和類TimedDoor之間的關(guān)聯(lián)，才能在超時時通知TimedDoor中相應(yīng)的處理代碼？下面給出了一種可想到的方案：TimerInterface Timer Client+TimeoutDoorTimedDoo

43、r0.*其中，Door繼承了Timer Client，因此TimedDoor也繼承了Timer Client，這就可以保證TimerClient把自己注冊到Timer中，并可接收TimeOut的消息。 現(xiàn)在,類Door依賴于TimerClient。該方案的主要問題就出現(xiàn)在這里。 1）不是所有種類的Door都需要定時功能。最初的Door與定時功能沒有任何關(guān)系，如果需要創(chuàng)建一個沒有定時功能的派生類，那么就必須要提供TimeOut方法的“退化”實現(xiàn)，這就違反了接口分離原則。 2）另外，使用這些派生類的應(yīng)用程序，即使不使用定義的TimerClient，也必須引入之，因此就具有不必要的復(fù)雜性和不必要的重

44、復(fù)-“臭味”。這是一個接口污染問題： 1）Door的接口被一個它不需要的方法污染了-在Door的接口中加入這個方法只是為了給它的子類帶來好處。 2）如果這樣持續(xù)下去的話，每一次子類需要一個新方法時，就被加入到基類中，這樣就可能進一步污染了接口，使它“胖”了起來。3、實現(xiàn)分離接口的途徑 1）分離客戶（程序）就是分離接口 Door的接口和TimerClient的接口完全被不同的客戶程序所使用，即Timer使用TimerClient，而對Door的操作使用了類Door。 既然客戶程序是分離的，所以接口也應(yīng)該保持分離。原因是客戶程序?qū)λ鼈兪褂玫慕涌谑怯杏绊懙摹?2）使用委托 分離接口 創(chuàng)建一個由Tim

45、erClient 所派生的對象，并把該對象的請求委托給TimedDoor. TimerInterface Timer Client+TimeoutDoorTimedDoor+DoorTimeOut0.*Door Timer Adapter+Timeout()creates其中,當(dāng)TimedDoor想要向Timer對象注冊一個超時請求時,它就創(chuàng)建一個DoorTimerAdapter,并把它注冊給Timer.當(dāng)Timer對象發(fā)送Timeout消息給DoorTimerAdapter時, DoorTimerAdapter把這個消息委托給TimedDoor.對這一方案的分析: 1) 該方案遵循了ISP,

46、并避免了Door的客戶程序和之間的耦合. 2)即使對Timer的進行了修改,也不會影響Door的使用者. 其中Timer的定義如下: Class Timer public: void Register(int timeout,int timeoutID,TimeCclient* client); ; Class TimerClient public: virtual void TimeOut( int timeoutID)=0; ;3) Timed Door也不必具有和 TimerClient一樣的接口;4) DoorTimerAdapter會將TimerClient接口轉(zhuǎn)換為TimedDoo

47、r 接口. 因此，這是一個非常通用的解決方案。5) 該方案盡管是一種通用的,但不是很優(yōu)雅的.即每次想去注 冊一個超時請求時,都要創(chuàng)建一個新的對象.這對于那些對 內(nèi)存和運行時間要求高的系統(tǒng)而言,例如嵌入式實時系統(tǒng), 就顯得不夠理想。3）使用多繼承 分離接口下圖給出使用多繼承并達到遵循ISP的方案:TimerInterface Timer Client+TimeoutDoorTimedDoor +DoorTimeOut0.*其中,在這個模型中, TimedDoor同時繼承了Door和TimerClient.這樣,盡管這2個基類的客戶程序都可以使用TimedDoor,但在實際上卻都不再依賴Timed

48、Door.從而,它們就通過分離的接口使用同一對象.比較: 就這一問題的2),3)方案而言, 只有當(dāng)Door Timer Adapter對象所做的轉(zhuǎn)換是必須的,或不同時候回需要不同轉(zhuǎn)換時,才會選擇2)中給出的方案.結(jié)論 1、胖類可以導(dǎo)致它們的客戶程序之間產(chǎn)生不正常的、且有害的耦合關(guān)系。當(dāng)一個客戶程序要求該胖類進行一個修改時，會影響到其他所有客戶程序。因此，客戶程序應(yīng)該僅僅依賴它們實際調(diào)用的方法。 2、把胖類的接口分解為多個特定于客戶程序的接口，可以實現(xiàn)以上目標。每個特定于客戶程序的接口僅僅聲明它的特定客戶或客戶組調(diào)用的那些函數(shù)，接著該胖類就可以繼承所有特定于客戶程序的接口，并實現(xiàn)它們。這就解除了

49、客戶程序和它們沒有調(diào)用的方法之間的依賴關(guān)系，并使客戶程序之間互不依賴。小結(jié)：框架技術(shù)帶來的好處在應(yīng)用系統(tǒng)開發(fā)中使用框架減少應(yīng)用軟件上市的時間提高應(yīng)用系統(tǒng)的可靠性、易維護性和易測試性框架體現(xiàn)了專家的意見，因為框架是針對一個領(lǐng)域的需求開發(fā)的，領(lǐng)域?qū)＜业闹R體現(xiàn)于框架中建立軟件標準，良好設(shè)計的框架為一個公司的應(yīng)用開發(fā)，形成軟件生產(chǎn)線確立了標準框架提高了應(yīng)用軟件的一致性和兼容性，易于集成并且具有一致的用戶界面開發(fā)難度相當(dāng)大！內(nèi) 容軟件框架概述軟件框架研究現(xiàn)狀實例研究San Francisco商業(yè)開發(fā)平臺San Francisco 背景San Francisco（簡稱SF）是IBM網(wǎng)絡(luò)領(lǐng)域解決方案系列產(chǎn)

50、品中的戰(zhàn)略性產(chǎn)品它是一個基于Java的構(gòu)件集，使得開發(fā)者不再從最底層開始構(gòu)造商業(yè)應(yīng)用系統(tǒng)，而是利用已經(jīng)有的構(gòu)件對服務(wù)器端的商業(yè)應(yīng)用系統(tǒng)進行開發(fā)同時，應(yīng)用系統(tǒng)只需要一次開發(fā)就可以在包括Windows NT、OS/400、AIX、Solaris、HP-UX以及Reliant UNIX在內(nèi)的平臺上運行目 標目標1：為商業(yè)應(yīng)用領(lǐng)域提供一個合理的、完整的模型，提供定義良好的編程模型，使得沒有面向?qū)ο蠹寄艿膽?yīng)用提供商可以有效使用OO技術(shù)提供領(lǐng)域公共的可復(fù)用資產(chǎn)為框架的演化使用提供支持可擴展性和可修改性較強的構(gòu)件提供靈活的持久性對象存儲方案為SF框架使用者提供集成的工具目 標目標二：提高企業(yè)的競爭力，確保企

51、業(yè)使用框架可以提高應(yīng)用軟件的生產(chǎn)率和產(chǎn)品質(zhì)量好的面向?qū)ο笤O(shè)計可修改性和可擴展性支持client/server或者其分布式模型用戶界面和業(yè)務(wù)對象的分離業(yè)務(wù)對象、業(yè)務(wù)策略和業(yè)務(wù)邏輯的分離其它構(gòu)件的集成目標三：提供一個開放的解決方案，以確保框架使用者在操作系統(tǒng)、硬件環(huán)境以及應(yīng)用體系結(jié)構(gòu)方面有較大的選擇范圍SF體系結(jié)構(gòu)的特點分布式一個分布式對象基礎(chǔ)設(shè)施（distributed object infrastructure ） 一組商業(yè)應(yīng)用構(gòu)件（a set of application business components） 面向?qū)ο蠹夹g(shù)封裝了復(fù)雜的變化性，使得應(yīng)用系統(tǒng)可以使得應(yīng)用可以很容易得隨著需求的

52、變化而改變，更易于維護和演化跨平臺通過JAVA的虛擬機,SF實現(xiàn)了與操作系統(tǒng)隔離，獲得平臺獨立性商業(yè)應(yīng)用框架商用應(yīng)用框架是一些代表商業(yè)實體的類，它們相互協(xié)作實現(xiàn)核心商業(yè)過程。面向?qū)ο罂蚣艿睦迷试S商業(yè)管理系統(tǒng)的開發(fā)者依賴一個已存在的商業(yè)過程和商業(yè)對象。為此，開發(fā)者能夠集中精力完成最終的不同需求SF體系結(jié)構(gòu)（1）SF體系結(jié)構(gòu)（2）SF是一個多層的、共享的、靈活的系統(tǒng)，用于開發(fā)獨立于平臺的、分布式面向?qū)ο蟮纳虡I(yè)應(yīng)用系統(tǒng)。完整的SF框架由三個不同的層次組成：基礎(chǔ)層(Foundation)，提供構(gòu)造分布的、面向?qū)ο蟮?、多平臺的應(yīng)用系統(tǒng)所需的基礎(chǔ)設(shè)施和服務(wù)通用商業(yè)對象層(Common Business

53、Objects, 簡稱CBOs)，提供通用的商業(yè)對象的定義，作為應(yīng)用系統(tǒng)之間互操作的基礎(chǔ)核心商業(yè)過程層(Core Bussiness Processes, 簡稱CBPs)，提供商業(yè)對象和默認的商業(yè)業(yè)務(wù)邏輯SF體系結(jié)構(gòu)（3）Foundation層是SF的核心技術(shù)層提供了分布對象的創(chuàng)建、同步、持續(xù)等基礎(chǔ)服務(wù)，以及一致的應(yīng)用開發(fā)模型封裝了跨平臺分布對象管理的技術(shù)，提供了易用的API，包括如下核心功能：支持安全、分布事務(wù)過程以及組成在客戶端和服務(wù)器端的中間層，為CBOs和CBPs提供了底層支持SF體系結(jié)構(gòu)（4）通用商業(yè)對象層CBOs與Foundation層一起組成了SF的基本內(nèi)容CBO層包括三個相對獨

54、立的組成成分：通用商業(yè)對象（Common Business Objects）在描述商業(yè)活動時常使用的概念和實體公共商業(yè)服務(wù)設(shè)計模式（Design Pattern）通用財政接口（Common Financial Interface）使得一個領(lǐng)域的應(yīng)用能夠訪問另一領(lǐng)域的應(yīng)用中的商業(yè)過程不僅讓彼此獨立開發(fā)的SF應(yīng)用能夠協(xié)同工作，而且使得SF應(yīng)用與遺留下來的非SF應(yīng)用（Legacy Application）能夠進行互操作SF體系結(jié)構(gòu)（5）核心商業(yè)過程(CBPs)層是SF的頂層，提供了通用的商業(yè)過程，而且提供了基于CBOs和Foundation層的擴展機制CBP層的目的：創(chuàng)建一個良好的面向?qū)ο蟮捏w系結(jié)構(gòu)

55、和一個易于擴展的具有基礎(chǔ)應(yīng)用結(jié)構(gòu)和行為的實現(xiàn)在基礎(chǔ)應(yīng)用結(jié)構(gòu)和行為之上，提供一組有限的應(yīng)用功能。應(yīng)用的開發(fā)者應(yīng)該對這些功能進行擴展，增加用戶界面、業(yè)界特定需求、商業(yè)規(guī)則、具有競爭力的應(yīng)用特色，以及補充的應(yīng)用功能提供擴展點，是應(yīng)用開發(fā)者增加、替換商業(yè)規(guī)則的地方，經(jīng)過與領(lǐng)域?qū)＜姨接懞途暮Y選設(shè)計的Foundation 層基礎(chǔ)層為開發(fā)者提供了兩類可直接使用的功能：對象模型基類為SF中的對象提供了基本結(jié)構(gòu)，定義了構(gòu)造SF應(yīng)用系統(tǒng)的模型既包含開發(fā)者可以直接繼承和使用的方法，也包含需要開發(fā)者自行實現(xiàn)的抽象方法基類提供了一個適合各個分布式應(yīng)用系統(tǒng)領(lǐng)域的統(tǒng)一的對象模型。開發(fā)者利用這些基類和接口來構(gòu)造應(yīng)用系統(tǒng)，不

56、用再去為特定的實現(xiàn)平臺定義各自的結(jié)構(gòu)和實現(xiàn)實用程序提供用SF構(gòu)造的很多應(yīng)用系統(tǒng)都需要的服務(wù)實用程序只能直接調(diào)用，不能被擴展或者修改。例如， “管理程序”支持系統(tǒng)安全性及系統(tǒng)配置信息的定義和維護；“沖突控制程序”允許系統(tǒng)管理員中斷那些不能并發(fā)執(zhí)行的命令等Foundation ClassFoundation層包含了一系列的JAVA類，是SF商業(yè)對象繼承樹的根。若想利用SF提供的服務(wù)，編程人員必須從這些類進行繼承。 Entity編程人員可以繼承Entity類，用來創(chuàng)建持久對象，這些對象可以被多個過程共享，可以應(yīng)用在一個事務(wù)（transaction）中用Entity創(chuàng)建的實例也可以根據(jù)需要是暫時性的，

57、但大部分都用于創(chuàng)建持續(xù)性的實例，一旦實例被創(chuàng)建并且提交給永久存儲，編程人員可以隨時檢索存在的對象實例一個持續(xù)的商業(yè)對象被實例化后，其行為表現(xiàn)象一般的JAVA對象一樣?？蛻舳丝梢哉{(diào)用這些實例的方法，這些實例可能生存在獨立的地址空間上，也可能是在遠程系統(tǒng)中Dependent 當(dāng)一個對象是它對象的一部分，而且不被多個對象共享時，就要考慮繼承Foundation層中的DependentDependent本質(zhì)上不是持續(xù)的，只有當(dāng)包含它的商業(yè)對象是持續(xù)的時候，它可以變?yōu)槌掷m(xù)的。并且在它含的對象中它是私有的Dependent表達對象之間的緊耦合關(guān)系Command Command 是Dependent的一個特

58、殊子類。在SF中，Command用于封裝特定商業(yè)過程的一系列行為，以隔離特定的商業(yè)邏輯，目的是：與Command聯(lián)合使用可以提高Entity的復(fù)用若商業(yè)規(guī)則變化可以很快地識別出應(yīng)用程序的哪一部分進行修改Command對于應(yīng)用程序性能的調(diào)節(jié)起著十分重要的作用，若一個過程包含處理多個 Entities，并調(diào)用大量的相關(guān)的方法，HOME 或LOCAL方式將嚴重降低性能，在這種情況下，創(chuàng)建一個Command將會對性能有顯著的提高San Francisco的編程模式 編程模式定義了一些框架使用者應(yīng)該遵循的規(guī)則，用于遵守某些標準或正確使用某些服務(wù)。SF這些編程模式是按照不同的編程人員角色制訂的：開發(fā)人員角

59、色：開發(fā)人員進行新的商業(yè)對象的開發(fā)或用已存的對象來繼承創(chuàng)建一個新的對象。解決的問題：需要提供什么方法？如何實現(xiàn)對象之間的關(guān)系？客戶端角色：客戶端角色使用已經(jīng)存在的類，處理的是創(chuàng)建對象實例、啟動或結(jié)束事務(wù)等工作。目的：保證編程人員正確、安全地使用Foundation所提供的服務(wù)，保證應(yīng)用程序之間結(jié)構(gòu)高度的一致。例如：當(dāng)創(chuàng)建一個Entity的子類時，編程模式要你編寫一個該類的Factory，當(dāng)客戶端要創(chuàng)建該類的實例時，可以直接調(diào)用該類的Factory類進行創(chuàng)建。通用商業(yè)對象層（CBO） CBO層包括三個獨立的部分：商業(yè)領(lǐng)域通用的商業(yè)對象應(yīng)用系統(tǒng)所需要的公共服務(wù)SF中用到的通用設(shè)計模式和通用財務(wù)接口

60、 CBO層是把一些類組織成稱為“類別” （category）的組，完成商業(yè)應(yīng)用的一些公共的功能CBO可以被核心商業(yè)過程（CBP）引用，也可以直接使用。它不象使用類庫那樣，直接把一個類選擇過來可與其它的隔離開，而CBO要考慮與其相關(guān)的協(xié)同的類或關(guān)系CBO categoriesAddress 地址提供了應(yīng)用在Framework中表示和存儲地址的類和功能支持Business Partner 商業(yè)合作伙伴提供了表示商業(yè)合作伙伴及伙伴層次的類和功能Business Partner Balance 商業(yè)伙伴賬目結(jié)算 用于表示和記錄商業(yè)伙伴之間各種交易的賬目結(jié)算Classification 分類 支持動態(tài)方