軟件架構(gòu)設(shè)計(jì)指南

軟件架構(gòu)設(shè)計(jì)指南一、軟件架構(gòu)設(shè)計(jì)當(dāng)對象、類、構(gòu)件、組件等概念出現(xiàn)并成熟之后，傳統(tǒng)意義上的軟件概要設(shè)計(jì)（或軟件系統(tǒng)設(shè)計(jì)），就逐漸改名為軟件架構(gòu)設(shè)計(jì)。所以說，軟件架構(gòu)設(shè)計(jì)就是軟件概要設(shè)計(jì)。軟件架構(gòu)設(shè)計(jì)工作由架構(gòu)師來完成，架構(gòu)師是主導(dǎo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的角色，他的具體職責(zé)為：領(lǐng)導(dǎo)與協(xié)調(diào)整個(gè)項(xiàng)目中的技術(shù)活動(dòng)（分析、設(shè)計(jì)入實(shí)施等）推動(dòng)主要的技術(shù)決策，并最終表達(dá)為軟件構(gòu)架描述確定和文檔化系統(tǒng)中對構(gòu)架而言意義重大的方面，包括系統(tǒng)的需求、設(shè)計(jì)、實(shí)施和部署等“視圖”確定設(shè)計(jì)元素的劃分以及這些主要分組之間的接口為技術(shù)決策提供規(guī)則，平衡各類涉眾的不同關(guān)注點(diǎn)，化解技術(shù)風(fēng)險(xiǎn)，并保證相關(guān)決定被有效傳達(dá)和貫徹理解、評價(jià)并接收系統(tǒng)需求?評價(jià)和確認(rèn)軟件架構(gòu)的實(shí)現(xiàn)二、軟件架構(gòu)基本概念5.1軟件架構(gòu)定義>系統(tǒng)是部件的集合，完成一個(gè)特定的功能或完成一個(gè)功能集合。架構(gòu)是系統(tǒng)的基本組織形式，描述系統(tǒng)中部件間及部件與環(huán)境音質(zhì)相互關(guān)系。架構(gòu)是指導(dǎo)系統(tǒng)設(shè)計(jì)和深化的原則。>系統(tǒng)架構(gòu)是實(shí)體、實(shí)體屬性以及實(shí)體關(guān)系的集合。>軟件架構(gòu)是軟件部件、部件屬性以及客觀存在們之間相互作用的集合，描述軟件系統(tǒng)的基本屬性和限制條件。5.2軟件架構(gòu)建模軟件架構(gòu)建模是與軟件架構(gòu)的定義和管理相關(guān)的分析、設(shè)計(jì)、文檔化、評審及其他活動(dòng)。>軟件架構(gòu)建模的目的：a）捕獲早期的設(shè)計(jì)決策。軟件架構(gòu)是最早的設(shè)計(jì)決策，它將影響到后續(xù)設(shè)計(jì)、開發(fā)和部署，對后期維護(hù)和演變也有很大的影響。b）捕獲軟件運(yùn)行時(shí)的環(huán)境。c）為底層實(shí)現(xiàn)提供限制條件。d）為開發(fā)團(tuán)隊(duì)的結(jié)構(gòu)組成提供依據(jù)。e）設(shè)計(jì)系統(tǒng)滿足可靠性、可維護(hù)性以及性能等方面的要求。f）方便開發(fā)團(tuán)隊(duì)之間的交流。5.3軟件架構(gòu)視圖軟件架構(gòu)視圖是指從一個(gè)特定的視角對系統(tǒng)或系統(tǒng)的一部分進(jìn)行的描述。架構(gòu)可以用不同的架構(gòu)視圖進(jìn)行描述，如邏輯視圖用于描述系統(tǒng)功能，進(jìn)程視圖用于描述系統(tǒng)并發(fā)，物理視圖用于描述系統(tǒng)部署。常見的有RUP的4+1視圖；5.4軟件架構(gòu)設(shè)計(jì)需包括：a）軟件系統(tǒng)中包含了哪些子系統(tǒng)和部件；b）每個(gè)子系統(tǒng)和部件都完成哪些功能；c）子系統(tǒng)和部件對外提供或使用外部的哪些；d）子系統(tǒng)和部件間的依賴關(guān)系，以及對實(shí)現(xiàn)和測試的影響；e）系統(tǒng)是如何部署的。三、軟件架構(gòu)設(shè)計(jì)步驟3.1確定影響整體技術(shù)方案的因素a）考察用戶界面的整體復(fù)雜度＞要求：識(shí)別重點(diǎn)模塊的主要信息輸入，和輸入途徑＞方法：通過重點(diǎn)模塊畫制的魯棒圖進(jìn)行分析；＞技巧用戶界面的復(fù)雜度可概括為以下幾種：/簡單數(shù)據(jù)輸入simpledatainput（例如登入界面）/數(shù)據(jù)的表態(tài)靜態(tài)視圖staticview（例如商品報(bào)價(jià)列表）/可定制視圖customizableview（例如可自定義查詢報(bào)告界面）/數(shù)據(jù)的動(dòng)態(tài)視圖dynamicview（例如實(shí)時(shí)運(yùn)行監(jiān)控視窗）/交互式圖形（例如CAD系統(tǒng)）b）考察用戶界面部署的約束＞要求：識(shí)別系統(tǒng)的部署環(huán)境和客戶端的使用環(huán)境；＞方法：主要通過訪談和觀察，識(shí)別客戶端環(huán)境；＞技巧用戶界面的部署約束可概括為以下幾種：/經(jīng)常要離線工作的移動(dòng)電腦/手持智能終端（如智能手機(jī)、MID、PAD）/支持Interner網(wǎng)上的任何一種瀏覽器（老版本瀏覽器）/支持Internet網(wǎng)上的較新版本瀏覽器/支持內(nèi)部網(wǎng)上的較新版本瀏覽器/支持內(nèi)部網(wǎng)上的特定瀏覽器/內(nèi)部網(wǎng)上的專用工作站（傳統(tǒng)C/S架構(gòu)的客戶端軟件）c）考察用戶的數(shù)量和類型＞要求：需大致識(shí)別出本系統(tǒng)用戶的數(shù)量級(jí)別和類型；＞方法：主要通過了解客戶背景信息，識(shí)別根據(jù)不同角色所對應(yīng)的人數(shù)和類型；＞技巧用戶的數(shù)量和類型可概括為以下幾種：/少數(shù)的專業(yè)用戶：關(guān)注功能強(qiáng)大，期望量身定制，樂于學(xué)習(xí)新特性，例如圖形制作系統(tǒng)的用戶；/組織內(nèi)的日常使用者：主流用戶，關(guān)注便捷和易用，例如考勤系統(tǒng)用戶；/大量的愛好者：對系統(tǒng)的功能有執(zhí)著的興趣，有意愿克服使用時(shí)遇到的的各種困難，包括軟件本身的缺陷，例如游戲軟件的用戶/數(shù)量巨大的消費(fèi)型用戶：關(guān)注速度和服務(wù)感受，例如商業(yè)網(wǎng)站的用戶d）考察系統(tǒng)接口類型＞要求：正確合理的識(shí)別系統(tǒng)中存在的接口和類型，本處重點(diǎn)的是識(shí)別外部存在的接口。＞方法：協(xié)作決定接口，見第四章；＞技巧系統(tǒng)接口類型可概括為以下幾種：/數(shù)據(jù)傳輸：僅僅為了滿足系統(tǒng)間交換數(shù)據(jù)的需要，例如電子數(shù)據(jù)交換EDI接口、數(shù)據(jù)庫同步等/通過協(xié)議提供服務(wù)：系統(tǒng)依照協(xié)議向外提供特定的服務(wù)，例如http協(xié)議、SOAP（WebService）協(xié)議等/直接訪問系統(tǒng)服務(wù)：按照類似于系統(tǒng)內(nèi)部調(diào)用的方式，直接使用系統(tǒng)的方法，例如基于RPC遠(yuǎn)程調(diào)用等e）考察數(shù)據(jù)性能和可伸縮性＞要求：正確識(shí)別是否存在大量的并發(fā)數(shù)據(jù)處理；＞方法：＞技巧性能和可伸縮性方面可概括為以下幾種：/只讀：只有對數(shù)據(jù)瀏覽和查詢操作，例如股票行情分析系統(tǒng)/獨(dú)立的數(shù)據(jù)更新：對數(shù)據(jù)的修改操作，但各用戶的修改完全隔離，相互間不存在任何潛在的沖突，例如網(wǎng)上商店各顧客對自己帳單的管理/并發(fā)的數(shù)據(jù)更新：并發(fā)用戶對數(shù)據(jù)的修改將相互影響，或者就是更改了同一數(shù)據(jù)，例如多個(gè)用戶同時(shí)使用航班預(yù)定系統(tǒng)預(yù)定同一航班的座位3.2選擇軟件構(gòu)架樣式（風(fēng)格）＞要求：根據(jù)前期細(xì)致的需求分析，選擇合理適用的軟件架構(gòu)樣式;＞方法：最常用的是使用三層或四層架構(gòu)；＞技巧軟件架構(gòu)樣式的常見種類有：/數(shù)據(jù)流構(gòu)架：是實(shí)現(xiàn)可重用性和可更改性，它的特點(diǎn)是把系統(tǒng)看作是對相繼輸入數(shù)據(jù)的一系列變換；/調(diào)用與返回構(gòu)架：一直是中大型軟件系統(tǒng)的主流構(gòu)架樣式，它的目標(biāo)是實(shí)現(xiàn)系統(tǒng)的可更更改性和可擴(kuò)展性。/獨(dú)立組件構(gòu)架：由許多通過發(fā)送消息進(jìn)行通訊的獨(dú)立進(jìn)程或?qū)ο蠼M成，它的目標(biāo)是通過解除各運(yùn)算部分之間的耦合實(shí)現(xiàn)可更改性，如股票機(jī)、各類短信預(yù)定等。目前我們常用的是調(diào)用和返回構(gòu)架中的分層構(gòu)架模式，是一種將系統(tǒng)行為或功能通過以層為首要的組織單位來進(jìn)行分配(劃分)的結(jié)構(gòu)模式。/展現(xiàn)層(UI):展現(xiàn)給用戶的界面，即用戶在使用一個(gè)系統(tǒng)的時(shí)候他的所見所得；/業(yè)務(wù)邏輯層(BLL)：根據(jù)系統(tǒng)的大小，又可以拆分為：業(yè)務(wù)接口層、業(yè)務(wù)實(shí)現(xiàn)層、業(yè)務(wù)實(shí)體層它的關(guān)注點(diǎn)主要集中在業(yè)務(wù)規(guī)則的制定、業(yè)務(wù)流程的實(shí)現(xiàn)等與業(yè)務(wù)需求有關(guān)的系統(tǒng)設(shè)計(jì)；/數(shù)據(jù)訪問層(DAL)有時(shí)候也稱為是持久層，其功能主要是負(fù)責(zé)數(shù)據(jù)庫的訪問，可以訪問數(shù)據(jù)庫系統(tǒng)、二進(jìn)制文件、文本文檔或是XML文檔；實(shí)現(xiàn)對數(shù)據(jù)表的Select，Insert，Update，Delete的操作；如果要加入ORM的元素，那么就會(huì)包括對象和數(shù)據(jù)表之間的mapping，以及對象實(shí)體的持久化。3.3利用可復(fù)用的資產(chǎn)＞要求：在需求及設(shè)計(jì)階段，正確識(shí)別現(xiàn)有可被復(fù)用的資產(chǎn)＞方法：/可復(fù)用的資產(chǎn)包括：工具、組件、WebServices、框架、模版、設(shè)計(jì)等；/項(xiàng)目經(jīng)理對項(xiàng)目設(shè)計(jì)中可能用到的資產(chǎn)情況進(jìn)行評估，并向技術(shù)經(jīng)理提出申請，將資源引入到本設(shè)計(jì)中；/技術(shù)經(jīng)理對項(xiàng)目中可能會(huì)用到的資產(chǎn)情況進(jìn)行檢查確認(rèn)；3.4子系統(tǒng)的劃分和接口的定義＞目的/支持個(gè)人或團(tuán)隊(duì)進(jìn)行獨(dú)立的開發(fā)/層次、包的劃分，為團(tuán)隊(duì)的分工協(xié)作提供最直接的依據(jù)/子系統(tǒng)的劃分，使得團(tuán)隊(duì)成員之間的依賴關(guān)系最小化，從而支持并行開發(fā)(方便集成)/為方便測試而進(jìn)行劃分，包、子系統(tǒng)及其接口的定義，應(yīng)當(dāng)支持被獨(dú)立地加以測試＞要求和方法：見第四章內(nèi)容3.5優(yōu)化設(shè)計(jì)，包括去冗余和提高重用性＞方法/通過劃分而去冗余將系統(tǒng)劃分為職責(zé)更為集中和明確的模塊（例如，對象、子系統(tǒng)、子程序等），相同的行為將通過調(diào)用一模塊來實(shí)現(xiàn)，從而避免重復(fù)的組成元素分散于系統(tǒng)各處；識(shí)別對象，并將職責(zé)分配給合適的對象，其它對象將委托它來完成對應(yīng)的行為?讓對象通過組合來復(fù)用已有對象的服務(wù)/通過泛化而去冗余將共性的行為抽取出來，專門在一處單獨(dú)定義；所有類似行為的實(shí)現(xiàn)，將關(guān)注于那些個(gè)性方面，共性方面直接從前述之處繼承，而不再重復(fù)實(shí)現(xiàn)面向?qū)ο蠓缎拖?，父類?shí)現(xiàn)共性的行為，并定義一些可重載的方法，在父方法中調(diào)用，然后讓子類重載它們以便擴(kuò)展個(gè)性行為（參考模板方法模式）泛化的去冗余途徑，主要是避免重復(fù)實(shí)現(xiàn)一些較大粒度框架性的行為，小粒度的行為復(fù)用應(yīng)當(dāng)使用前述的劃分途徑/通過模塊化而去冗余使用模板來定義共性的結(jié)構(gòu)和行為，并留出某些變量，這些變量對模板而言是行為敏感的；在具體的應(yīng)用場景，通過引入不同的參數(shù)變量，從而導(dǎo)出眾多個(gè)性化的行為組合?面向?qū)ο蠓缎拖?，主要有模板類、模板函?shù)等方式模板化去冗余途徑，形式主義是一種結(jié)構(gòu)（引入變量）與（模板）行為的二元組合，其實(shí)質(zhì)是避免行為的重復(fù)定義/通過面向方面編程而去冗余將分散在系統(tǒng)代碼之間的，行使類似職能的代碼抽取出來，作為一個(gè)方面樣子，集中到一塊來處理（這些職能包括：日志記錄、權(quán)限驗(yàn)證、資源的釋放、異常處理等），避免類似代碼的到處重復(fù)泛濫四、軟件設(shè)計(jì)方法體系（ADMEMS方法，三個(gè)階段，一個(gè)貫穿）4.1需求進(jìn)一步分析階段：全面了解客戶需求＞第1步，需求結(jié)構(gòu)化/從“不同層次的涉眾提出需求所站的立場不同”的角度，把需求劃分為三種類型，這就是需求的三個(gè)層次：業(yè)務(wù)需求：組織要達(dá)到的什么目標(biāo)；?用戶需求：用戶使用系統(tǒng)來做些什么事情；行為需求：開發(fā)人員需要實(shí)現(xiàn)什么；/從“需求定義直接目標(biāo)還是間接限制”的角度，把需求劃分為三種類型，這就是需求的三個(gè)方面：功能需求：更多的體現(xiàn)各級(jí)直接的目標(biāo)要求；?質(zhì)量需求：開發(fā)期的質(zhì)量+運(yùn)行期的質(zhì)量；約束需求：業(yè)務(wù)環(huán)境因素+使用環(huán)境因素+構(gòu)建環(huán)境因素+技術(shù)環(huán)境因素/常用需求層次-需求方面二維矩陣圖進(jìn)行表示：廣義功能11質(zhì)量約束［組織需求｝業(yè)務(wù)H標(biāo)快好省技木垃細(xì)L標(biāo)準(zhǔn)性約束法規(guī)君細(xì)1技術(shù)趨麹分枇實(shí)弟競爭因素與辭對手｝用戶需』，化行期質(zhì)量用戶群特點(diǎn)用戶北平富國語言彳丁為需求開發(fā)期質(zhì)星開發(fā)團(tuán)隊(duì)J京術(shù)水平開發(fā)團(tuán)隊(duì)腔機(jī)度開發(fā)團(tuán)隊(duì)分布情況開虛困隊(duì)業(yè)緞口正官理：課密其求苣瑾E產(chǎn)品嫩）1安裝維護(hù)圖4.1需求層次一需求方面二維矩陣＞第2步，分析約束影響/來自客戶組織的約束性要求必須充分考慮到客戶上線時(shí)間的要求、預(yù)算的限制、以及集成需要等非功能需求；?客戶所處的業(yè)務(wù)領(lǐng)域?yàn)楹?？有什么業(yè)務(wù)規(guī)則和業(yè)務(wù)限制？是否需要關(guān)注相應(yīng)的法律法規(guī)、專利限制？/來自用戶的約束性要求軟件將提供給合階層用戶？?主要用戶的年齡段？使用偏好？?使用的環(huán)境是否有影響系統(tǒng)的？/來自開發(fā)者和維護(hù)人員的約束性要求?開發(fā)團(tuán)隊(duì)的技術(shù)水平能力、磨合程度、是否分布在不同城市，有何影響？開發(fā)管理方面、源代碼管理和保密方面、是否要顧及？/來自業(yè)界本身技術(shù)環(huán)境的約束性要求技術(shù)平臺(tái)、中間件、編程語言等的流行度、成熟度、認(rèn)同度、優(yōu)缺點(diǎn)等的考慮；?所使用的技術(shù)發(fā)展的趨勢如何，是否需要考慮？循火龍果整理~4.2塑造概念架構(gòu)階段：通過關(guān)鍵功能，進(jìn)行初步設(shè)計(jì)第1步，初步設(shè)計(jì)在第一階段確定關(guān)鍵的功能子集對于關(guān)鍵的功能子集，需要在需求列表上進(jìn)行標(biāo)注；通過魯棒圖和職責(zé)協(xié)作鏈的原理，識(shí)別角色和他所對應(yīng)的職責(zé)；從事件流開始，對關(guān)鍵功能畫出用例圖和用例描述；開始尋找邊界對象，描述模外部環(huán)境和系統(tǒng)之間的交互進(jìn)行建模，通常指的就是交互，如UI；尋找控制對象，對行為進(jìn)行封裝，描述用例中事件流的控制行為，也就是業(yè)務(wù)辦法，負(fù)責(zé)控制；尋找實(shí)體對象，對需要存儲(chǔ)的信息進(jìn)行描述，通常指的就是我們的對象類，負(fù)責(zé)信息；第2步，高層分割對于功能不是太復(fù)雜的，可以直接將黑盒系統(tǒng)切分為子系統(tǒng)的；對于功能較為復(fù)雜的，需進(jìn)行高級(jí)高層分割首先將黑盒系統(tǒng)切分為更小一級(jí)的系統(tǒng)，每個(gè)更小一級(jí)的系統(tǒng)都可以有單獨(dú)的需求、設(shè)計(jì)、實(shí)現(xiàn)……之后，針對每個(gè)“更小一級(jí)的系統(tǒng)”進(jìn)行“切系統(tǒng)為子系統(tǒng)”第3步，考慮非功能需求以場景技術(shù)為跳板的非功能設(shè)計(jì)思維發(fā)現(xiàn)場景功能性的考慮，是否準(zhǔn)確，是否安全等；可靠性的考慮，安全性，容錯(cuò)性，穩(wěn)定性；易用性，用戶體驗(yàn)方面；效率的問題，頁面載入時(shí)間，資源特性等；維護(hù)性的考慮，安裝便捷，功能修改方便；通過目標(biāo)-場景-決策表，進(jìn)行評估場景，并做出決策實(shí)例：

圖2：場景思維是方法核心目標(biāo)場景決策業(yè)務(wù)需求和約束項(xiàng)目成員，在客戶現(xiàn)場，能夠訪問PM系統(tǒng)PM系統(tǒng)的用戶，分別在windows、Unix、Linux、Mac上工作，能夠訪問PM系統(tǒng)B/S架構(gòu)B/S架構(gòu)互操作牲（質(zhì)量屬性）?HR系統(tǒng)，已有員工信息，不再輸入而是互操柞導(dǎo)入PM系毓的用戶，也要管理項(xiàng)目文檔，同時(shí)訪問PM、CVS麻煩配置管理服務(wù)器，不是CVS,如何支持支持從HR系統(tǒng)導(dǎo)入員工信息功能PM作為CVS客戶端提供束檔管理能力Adapter設(shè)計(jì)模式，支持CVS、Subversion等跨平臺(tái)（質(zhì)量屬姓）DBMS>可能是Oracle.SQLServer,如何都客戶端，運(yùn)行在掌上電腦上，如何支持服務(wù)器，跑的OS可能是Wndows、Unix.Linux,如何都支持采用ORM技術(shù)不支持Java開發(fā)Server竭圖3：實(shí)例《項(xiàng)目管理系統(tǒng)》非功能性，目標(biāo)一場景一決策表4.3細(xì)化概念架構(gòu)階段>合理的劃分子系統(tǒng)/三個(gè)策略?分層的細(xì)化如將系統(tǒng)分為展現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)訪問層；又可在三層架構(gòu)中加入控制層，形成展現(xiàn)層、控制層、業(yè)務(wù)層、數(shù)據(jù)訪問層，將三層架構(gòu)轉(zhuǎn)換為四層架構(gòu)；可以繼續(xù)細(xì)化，將業(yè)務(wù)層細(xì)化為業(yè)務(wù)接口層、業(yè)務(wù)實(shí)現(xiàn)層、業(yè)務(wù)實(shí)體層；通過不斷的細(xì)化，來降低系統(tǒng)的復(fù)雜度，提高開發(fā)人員的并行開發(fā)能力；?分區(qū)的引入?先做一個(gè)高級(jí)的廣度設(shè)計(jì)，然后馬上轉(zhuǎn)到深度優(yōu)先的底層設(shè)計(jì)和實(shí)現(xiàn)上去；?分層+分區(qū)，如圖4所示，是支持迭代和并行開發(fā)的基礎(chǔ)；藉龍島代開發(fā)吧圖4：架構(gòu)中引入分區(qū)，支持迭代和并行?機(jī)制的提取對于編程實(shí)現(xiàn)而言，在沒有提取機(jī)制的情況下，機(jī)制是一種隱式的重復(fù)代碼；對于邏輯架構(gòu)設(shè)計(jì)而言，機(jī)制是一種特殊的子系統(tǒng)，在劃分子系統(tǒng)的時(shí)候不要遺忘；在實(shí)現(xiàn)不同的最終功能時(shí)，可以重用一種機(jī)制，避免重復(fù)進(jìn)行“組裝”工作，如審批機(jī)制，權(quán)限機(jī)制，各個(gè)模塊和子系統(tǒng)都可以進(jìn)行調(diào)用。/一個(gè)原理?關(guān)注點(diǎn)分離的原則通過職責(zé)劃分來分離關(guān)注點(diǎn)；利用系統(tǒng)各部分的通用性不同進(jìn)行關(guān)注點(diǎn)分離；根據(jù)不同顆粒度級(jí)別進(jìn)行關(guān)注點(diǎn)分離；?示意圖：

領(lǐng)域通用部分成‘，解合-*分技術(shù)通用部分領(lǐng)域通用部分成‘，解合-*分技術(shù)通用部分/四個(gè)原則職責(zé)不同的單元?jiǎng)潥w不同的子系統(tǒng)；通用性不同的單元?jiǎng)潥w不同的子系統(tǒng)；需要不同開發(fā)技能的劃歸不同的子系統(tǒng)；?兼顧工作量的相對均衡，進(jìn)一步切分太大的子系統(tǒng)；＞合理的接口設(shè)計(jì)/把模塊放在協(xié)作的上下文中進(jìn)行考慮，接口設(shè)計(jì)才有意義；/需要考慮的是“為了實(shí)現(xiàn)一系列的功能，這個(gè)軟件單元要和其它單元如何協(xié)作？”/協(xié)作決定接口，以此作為原則，依次在單元之間識(shí)別接口；＞細(xì)化初步設(shè)計(jì)中的魯棒圖，形成魯棒順序圖；（見案例附件）五、軟件設(shè)計(jì)經(jīng)驗(yàn)之談5.1設(shè)計(jì)模式a）工廠模式工廠模式一般用于創(chuàng)建一類對象，而不用每次在使用時(shí)通過new（）對象才能使用對象，而是通過工廠來完成對象的創(chuàng)建，這樣不但提供了統(tǒng)一創(chuàng)建對象的入口，而且對于程序的可維護(hù)和可測試性都有很大的提高。常用的場景有：工廠負(fù)責(zé)創(chuàng)建某一類對象的時(shí)候，或者說工廠的職責(zé)比較單一時(shí)，如果說多個(gè)類型的對象時(shí)候，用工廠模式就不如使用抽象工廠了；一般比較少的積累對象，可以通過類型的判定創(chuàng)建不同的對象時(shí)，也是可以通過工廠模式來完成，例如多數(shù)據(jù)庫的支持，我們在設(shè)計(jì)數(shù)據(jù)訪問層時(shí)，利用簡單對象工廠，通過枚舉或者配置文件的形式，來動(dòng)態(tài)的創(chuàng)建數(shù)據(jù)訪問層實(shí)例。一般來說類型單一的對象，或者類型比較少的時(shí)候，使用工廠模式來創(chuàng)建對象可以解決一類問題。還可以通過一個(gè)總的工廠，來創(chuàng)建多個(gè)工廠，然后多個(gè)工廠負(fù)責(zé)創(chuàng)建相應(yīng)的實(shí)例，有點(diǎn)類似我們平時(shí)說的目錄結(jié)構(gòu)似的。b）代理模式Proxy代理模式是一種結(jié)構(gòu)型設(shè)計(jì)模式，“增加一層間接層”是軟件系統(tǒng)中對許多負(fù)責(zé)問題的一種常見解決方法。在面向?qū)ο笙到y(tǒng)中，直接使用某些對象會(huì)帶來很多問題，作為間接層的proxy對象便是解決此類問題。常用的場景有：在我們?nèi)粘５墓ぷ髦幸渤３Ｓ玫酱砟Ｊ?，比如對于三層結(jié)構(gòu)中DAL數(shù)據(jù)訪問層，它把對數(shù)據(jù)庫的訪問進(jìn)行封裝°BLL業(yè)務(wù)層的開發(fā)者只是調(diào)用DAL中的方法來獲得數(shù)據(jù)；具體proxy設(shè)計(jì)模式的實(shí)現(xiàn)方法、實(shí)現(xiàn)粒度都相差很大，有些可能對單個(gè)對象作細(xì)粒度的控制，有些可能對組件模塊提供抽象代理層，在架構(gòu)層次對對象作proxy；proxy并不一定要求保持接口的一致性，只要能夠?qū)崿F(xiàn)間接控制，有時(shí)候損及一些透明性是可以接受的。c）單例模式保證一個(gè)類只有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。它的應(yīng)用場景比較廣：比如在某個(gè)服務(wù)器程序中，該服務(wù)器的配置信息存放在一個(gè)文件中，這些配置數(shù)據(jù)由一個(gè)單例對象統(tǒng)一讀取，然后服務(wù)進(jìn)程中的其他對象再通過這個(gè)單例對象獲取這些配置信息；可以使用它創(chuàng)建一個(gè)連接池，每次程序需要往數(shù)據(jù)庫中寫入內(nèi)容時(shí)才創(chuàng)建一個(gè)新連接的做法并不明智；相反，一個(gè)或一組已經(jīng)在池中的連接就可以使用Singleton模式實(shí)例化；比如有互策的訂票機(jī)制，我們可以采用單例模式，只實(shí)例化一次來操作訂票；d）建造者模式建造者模式可以將一個(gè)產(chǎn)品的內(nèi)部表象與產(chǎn)品的生成過程分割開來，從而可以使一個(gè)建造過程生成具有不同的內(nèi)部表象的產(chǎn)品對象。常用的場景有：需要生成的對象有復(fù)雜的內(nèi)部結(jié)構(gòu)。需要生成的對象的屬性相互依賴，建造者模式可以強(qiáng)迫生成順序。在對象創(chuàng)建過程中會(huì)使用到系統(tǒng)中的一些其它對象，這些對象在對象的創(chuàng)建過程中不易得到。e）觀察者模式在一對多依賴的對象關(guān)系中，如果這個(gè)'一'對象狀態(tài)發(fā)生了變化，那么它所有依賴的'多'對象都應(yīng)該被通知，然后做相應(yīng)的變化，這就是觀察者模式，它的常用場景有：當(dāng)一個(gè)對象的改變需要通知或同時(shí)需要改變其它對象的時(shí)候；比如我們要建一個(gè)網(wǎng)上購物商城，對于用戶訂購的商品信息，如果該商品的價(jià)格、促銷活動(dòng)等發(fā)生變換，系統(tǒng)將會(huì)自動(dòng)發(fā)生郵件通知到用戶，則就是典型的觀察者模式；在現(xiàn)實(shí)生活中，拍賣行拍賣物品也是一個(gè)典型的觀察者模式，拍賣師拍賣時(shí)，他觀察是否有牌子舉起出價(jià)。每次接受一個(gè)新的出價(jià)都會(huì)改變拍賣的當(dāng)前價(jià)格，并廣播通知給所有競標(biāo)人，競標(biāo)人則進(jìn)行新的出價(jià)和退出。裝飾模式能動(dòng)態(tài)的將職責(zé)附加到對象上去，若要擴(kuò)展功能，裝飾者提供了比繼承更具彈性的代替方案。裝飾模式提供了一個(gè)非常好的解決方案，它把每個(gè)需要裝飾的功能放在單獨(dú)的類中，并讓這個(gè)類包裝它所裝飾的對象，因此，當(dāng)需要執(zhí)行特殊行為時(shí)，客戶代碼就可以在運(yùn)行時(shí)根據(jù)需要有選擇地、按順序的使用裝飾功能來包裝對象了。它的常用場景有：需要擴(kuò)展一個(gè)類的功能，或給一個(gè)類增加附加責(zé)任。需要?jiǎng)討B(tài)地給一個(gè)對象增加功能，這些功能可以再動(dòng)態(tài)地撤銷。需要增加由一些基本功能的排列組合而產(chǎn)生的非常大量的功能，從而使繼承關(guān)系變得不現(xiàn)實(shí)5.2常見設(shè)計(jì)問題Session管理Session又稱會(huì)話狀態(tài)，是Web系統(tǒng)中最常用的狀態(tài)，用于維護(hù)和當(dāng)前瀏覽器實(shí)例相關(guān)的信息；我們可以寫一個(gè)SessionSate的管理類，通過靜態(tài)屬性直接來進(jìn)行訪問；同時(shí)在管理類中，我們還要考慮服務(wù)器的性能，對需要記錄的屬性到底是采用Session還是Cookies做出合理的決策。如下圖所示：publicclassSessionStateprivateSessionState()/