軟件架構(gòu)設(shè)計(jì)實(shí)踐- 基于SSM框架 課件 第1、2章 軟件設(shè)計(jì)模式導(dǎo)論、典型軟件設(shè)計(jì)模式

軟件架構(gòu)設(shè)計(jì)實(shí)戰(zhàn)——基于SSM框架Software

Architecture

Design

Practice

Based

on

SSM

Framework第1章軟件設(shè)計(jì)模式導(dǎo)論123軟件設(shè)計(jì)模式概述軟件設(shè)計(jì)模式的基本原則使用設(shè)計(jì)模式的優(yōu)點(diǎn)軟件設(shè)計(jì)模式概述軟件設(shè)計(jì)模式是軟件設(shè)計(jì)中常見(jiàn)問(wèn)題的典型解決方案，就像能根據(jù)需求進(jìn)行調(diào)整的預(yù)制藍(lán)圖，可用于解決軟件項(xiàng)目開(kāi)發(fā)中反復(fù)出現(xiàn)的設(shè)計(jì)問(wèn)題。與方法或庫(kù)的使用方式不同特定的代碼與算法的區(qū)別11.1軟件設(shè)計(jì)模式產(chǎn)生的背景“設(shè)計(jì)模式”這個(gè)術(shù)語(yǔ)最初并不是出現(xiàn)在軟件設(shè)計(jì)中，而是被用于建筑領(lǐng)域的設(shè)計(jì)中?！督ㄖＪ秸Z(yǔ)言：城鎮(zhèn)、建筑、構(gòu)造》《建筑的永恒之道》設(shè)計(jì)模式思想應(yīng)用在Smalltalk中的圖形用戶接口的生成中軟件工程界才開(kāi)始研討設(shè)計(jì)模式的話題1977年1979年1987年1990年1995年《設(shè)計(jì)模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》啟發(fā)：設(shè)計(jì)模式產(chǎn)生的重要性——GoF四人組——23個(gè)經(jīng)典設(shè)計(jì)模式1.1軟件設(shè)計(jì)模式產(chǎn)生的背景GoF四人組合著的《設(shè)計(jì)模式》并不是一種具體“技術(shù)”，它講述的是思想，它不僅僅展示了接口或抽象類在實(shí)際案例中的靈活應(yīng)用和超人智慧，讓你能夠真正掌握接口或抽象類的應(yīng)用，從而在原來(lái)的Java語(yǔ)言基礎(chǔ)上躍進(jìn)一步，更重要的是，GoF反復(fù)強(qiáng)調(diào)一個(gè)宗旨：要讓程序盡可能的重用。這其實(shí)在做一個(gè)極限挑戰(zhàn)：在軟件項(xiàng)目開(kāi)發(fā)中唯一不變就是如何應(yīng)對(duì)不斷變化的需求。但是我們還是要尋找出不變的東西，并將它和變化的東西分離開(kāi)來(lái)，這需要非常的智慧和經(jīng)驗(yàn)。1.2軟件設(shè)計(jì)模式的基本要素軟件設(shè)計(jì)模式使人們可以更加簡(jiǎn)單方便地復(fù)用成功的設(shè)計(jì)和體系結(jié)構(gòu)。模式名稱（PatternName）問(wèn)題（Problem）解決方案（Solution）效果（Consequence）2軟件設(shè)計(jì)模式的基本原則設(shè)計(jì)模式是從實(shí)際業(yè)務(wù)當(dāng)中抽取出來(lái)，然后進(jìn)行抽象，形成一種通用的解決問(wèn)題的思路，是從具體到抽象的過(guò)程；在解決實(shí)際問(wèn)題的時(shí)候，不能生搬硬套的使用某一種設(shè)計(jì)模式，而要考慮該問(wèn)題與哪種設(shè)計(jì)模式的應(yīng)用場(chǎng)景、特征相匹配，從而選擇某個(gè)或多個(gè)設(shè)計(jì)模式。2.1開(kāi)閉原則開(kāi)閉原則（OpenClosedPrinciple，OCP）由勃蘭特·梅耶（BertrandMeyer）提出，他在1988年的著作《面向?qū)ο筌浖?gòu)造》（ObjectOrientedSoftwareConstruction）中提出：軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉（Softwareentitiesshouldbeopenforextension，butclosedformodification），這就是開(kāi)閉原則的經(jīng)典定義。開(kāi)閉原則的含義是：當(dāng)軟件項(xiàng)目的應(yīng)用需求改變時(shí)，在不修改軟件實(shí)體的源代碼或者二進(jìn)制代碼的前提下，可以擴(kuò)展模塊的功能，使其滿足新的需求。2.1開(kāi)閉原則1.開(kāi)閉原則的作用：（1）降低軟件測(cè)試的工作量：如果軟件開(kāi)發(fā)遵守開(kāi)閉原則，軟件測(cè)試時(shí)只需要對(duì)擴(kuò)展的代碼進(jìn)行測(cè)試，因?yàn)樵械臏y(cè)試代碼仍然能夠正常運(yùn)行。（2）提高代碼的可復(fù)用性：在軟件項(xiàng)目開(kāi)發(fā)中，項(xiàng)目模塊粒度越小，被復(fù)用的可能性就越大，在遵守開(kāi)閉原則的情況下，通過(guò)對(duì)原有模塊的擴(kuò)展能夠提高代碼的可復(fù)用性。（3）提高軟件項(xiàng)目的可維護(hù)性：遵守開(kāi)閉原則的軟件項(xiàng)目，其基礎(chǔ)代碼（模塊）越來(lái)越穩(wěn)固，在項(xiàng)目維護(hù)的過(guò)程中，工作量會(huì)大大減少，降低維護(hù)成本。2.1開(kāi)閉原則2.開(kāi)閉原則的實(shí)現(xiàn)方法可以通過(guò)“抽象約束、封裝變化”來(lái)實(shí)現(xiàn)開(kāi)閉原則，即通過(guò)接口或者抽象類為軟件實(shí)體定義一個(gè)相對(duì)穩(wěn)定的抽象層，而將相同的可變因素封裝在相同的具體實(shí)現(xiàn)類中。因?yàn)槌橄箪`活性好，適應(yīng)性廣，只要抽象的合理，可以基本保持軟件架構(gòu)的穩(wěn)定。而軟件中易變的細(xì)節(jié)可以從抽象派生來(lái)的實(shí)現(xiàn)類來(lái)進(jìn)行擴(kuò)展，當(dāng)軟件需求發(fā)生變化時(shí)，只需要根據(jù)新需求重新派生一個(gè)實(shí)現(xiàn)類來(lái)擴(kuò)展就可以完成。開(kāi)閉原則也是在軟件項(xiàng)目開(kāi)發(fā)中最為重要的一個(gè)基本原則。2.1開(kāi)閉原則3.示例：開(kāi)閉原則的使用——Windows的桌面主題設(shè)計(jì)2.2里氏代換原則里氏替換原則（LiskovSubstitutionPrinciple，LSP）由麻省理工學(xué)院計(jì)算機(jī)科學(xué)實(shí)驗(yàn)室的里斯科夫（Liskov）女士在1987年的“面向?qū)ο蠹夹g(shù)的高峰會(huì)議”（OOPSLA）上發(fā)表的一篇文章《數(shù)據(jù)抽象和層次》（DataAbstractionandHierarchy）里提出來(lái)的，她提出：繼承必須確保超類所擁有的性質(zhì)在子類中仍然成立（Inheritanceshouldensurethatanypropertyprovedaboutsupertypeobjectsalsoholdsforsubtypeobjects）。2.2里氏代換原則1.里氏替換原則的作用（1）里氏替換原則是實(shí)現(xiàn)開(kāi)閉原則的重要方式之一。（2）里氏替換原則克服了繼承中重寫父類方法造成的可復(fù)用性變差的缺點(diǎn)。（3）里氏替換原則是動(dòng)作正確性的保證。即類的擴(kuò)展不會(huì)給已有的系統(tǒng)引入新的錯(cuò)誤，降低了代碼出錯(cuò)的可能性。（4）里氏替換原則增強(qiáng)了程序的健壯性，在項(xiàng)目需求變更時(shí)可以做到非常好的兼容性，提高程序的可維護(hù)性、可擴(kuò)展性，降低需求變更時(shí)引入風(fēng)險(xiǎn)的概率。2.2里氏代換原則2.里氏替換原則的實(shí)現(xiàn)方法（1）子類可以實(shí)現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法；（2）子類中可以增加自己特有的方法；（3）當(dāng)子類的方法重載父類的方法時(shí)，方法的前置條件（即方法的輸入?yún)?shù)）要比父類的方法更寬松；這樣做的目的是確保能夠調(diào)用到父類被重載的方法，在子類繼承父類的過(guò)程中，不能由于繼承，而讓父類的某些方法無(wú)法被調(diào)用。（4）當(dāng)子類的方法實(shí)現(xiàn)父類的方法時(shí)（重寫/重載或?qū)崿F(xiàn)抽象方法），方法的后置條件（即方法的輸出/返回值）要比父類的方法更嚴(yán)格或相等。例如：父類的某個(gè)方法返回值的數(shù)據(jù)類型T，子類相同方法（重載或者重寫）返回值的數(shù)據(jù)類型為S，那么里氏替換原則就要求S必須小于等于T。2.2里氏代換原則通過(guò)重載父類的方法來(lái)完成新的功能寫起來(lái)雖然簡(jiǎn)單，但是整個(gè)繼承體系的可復(fù)用性會(huì)變差，特別是運(yùn)用多態(tài)比較頻繁時(shí)，程序運(yùn)行出錯(cuò)的概率就會(huì)增大。關(guān)于里氏替換原則的例子，最有名的是“正方形不是長(zhǎng)方形”。當(dāng)然，生活中也有很多類似的例子，例如，企鵝和鴕鳥(niǎo)從生物學(xué)的角度來(lái)劃分，它們屬于鳥(niǎo)類；但從類的繼承關(guān)系來(lái)看，由于它們不能繼承“鳥(niǎo)”會(huì)飛的功能，所以它們不能定義成“鳥(niǎo)”的子類；同樣，由于“氣球魚(yú)”不會(huì)游泳，所以不能定義成“魚(yú)”的子類；“玩具炮”上不了戰(zhàn)場(chǎng)，所以不能定義成“炮”的子類等。2.2里氏代換原則示例2：里氏替換原則——“鴕鳥(niǎo)不是鳥(niǎo)”的類設(shè)計(jì)2.3依賴倒轉(zhuǎn)原則依賴倒置原則的原始定義為：高層模塊不應(yīng)該依賴低層模塊，兩者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴抽象（Highlevelmodulesshouldnotdependuponlowlevelmodules.Bothshoulddependuponabstractions.Abstractionsshouldnotdependupondetails.Detailsshoulddependuponabstractions）。其核心思想是：要面向接口編程，不要面向?qū)崿F(xiàn)編程。2.3依賴倒轉(zhuǎn)原則1.依賴倒置原則的作用（1）依賴倒置原則可以降低類間的耦合性。（2）依賴倒置原則可以提高系統(tǒng)的穩(wěn)定性。（3）依賴倒置原則可以減少并行開(kāi)發(fā)引起的風(fēng)險(xiǎn)。（4）依賴倒置原則可以提高代碼的可讀性和可維護(hù)性。2.3依賴倒轉(zhuǎn)原則2.依賴倒置原則的實(shí)現(xiàn)方法依賴倒置原則的目的是通過(guò)面向接口的編程來(lái)降低類間的耦合性，所以我們?cè)趯?shí)際編程中只要遵循以下四點(diǎn)，就能在項(xiàng)目中滿足這個(gè)原則。（1）每個(gè)類盡量提供接口或抽象類，或者兩者都具備。（2）變量的聲明類型盡量用接口或者是抽象類。（3）任何類都不應(yīng)該從具體類派生。（4）使用繼承時(shí)盡量遵循里氏替換原則。2.3依賴倒轉(zhuǎn)原則依賴倒置原則在Spring框架的IOC中具有重要的應(yīng)用，同時(shí)在SpringMVC框架以及MyBatis框架中也有很多應(yīng)用點(diǎn)。示例3：依賴倒置原則——顧客購(gòu)物程序中的類設(shè)計(jì)2.4單一職責(zé)原則單一職責(zé)原則（SingleResponsibilityPrinciple，SRP）又稱單一功能原則，也是由羅伯特·C·馬?。≧obertCMartin）于《敏捷軟件開(kāi)發(fā)：原則、模式和實(shí)踐》一書(shū)中提出的。這里的職責(zé)是指類變化的原因，單一職責(zé)原則規(guī)定一個(gè)類應(yīng)該有且僅有一個(gè)引起它變化的原因，否則類應(yīng)該被拆分（Thereshouldneverbemorethanonereasonforaclasstochange）。該原則提出對(duì)象不應(yīng)該承擔(dān)太多職責(zé)，如果一個(gè)對(duì)象承擔(dān)了太多的職責(zé)，至少存在以下兩個(gè)缺點(diǎn)：（1）一個(gè)職責(zé)的變化可能會(huì)削弱或者抑制這個(gè)類實(shí)現(xiàn)其他職責(zé)的能力；（2）當(dāng)調(diào)用者需要該類的某一個(gè)職責(zé)時(shí)，不得不將其他不需要的職責(zé)全都包含進(jìn)來(lái)，從而造成冗余代碼或代碼的浪費(fèi)。2.4單一職責(zé)原則1.單一職責(zé)原則的優(yōu)點(diǎn)單一職責(zé)原則的核心就是控制類的粒度大小、將對(duì)象解耦、提高其內(nèi)聚性。遵循單一職責(zé)原則將有以下優(yōu)點(diǎn)。（1）降低類的復(fù)雜度。一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)，其邏輯肯定要比負(fù)責(zé)多項(xiàng)職責(zé)更簡(jiǎn)單。（2）提高類的可讀性。由于類的職責(zé)單一、復(fù)雜性降低，代碼的可讀性就更好。（3）提高系統(tǒng)的可維護(hù)性。每個(gè)類都專注于單一業(yè)務(wù)，項(xiàng)目在維護(hù)中自然更容易。（4）變更引起的風(fēng)險(xiǎn)降低。變更在軟件項(xiàng)目開(kāi)發(fā)中是不可避免的，遵守單一職責(zé)原則，當(dāng)修改一個(gè)功能時(shí)，可以顯著降低對(duì)其他功能的影響。2.4單一職責(zé)原則2.單一職責(zé)原則的實(shí)現(xiàn)方法單一職責(zé)原則是最簡(jiǎn)單但又最難靈活運(yùn)用的原則，需要設(shè)計(jì)人員發(fā)現(xiàn)類的不同職責(zé)并將其分離，再封裝到不同的類或模塊中。而發(fā)現(xiàn)類的多重職責(zé)需要設(shè)計(jì)人員具有較強(qiáng)的分析設(shè)計(jì)能力和相關(guān)重構(gòu)經(jīng)驗(yàn)。下面以大學(xué)學(xué)生工作管理程序?yàn)槔榻B單一職責(zé)原則的應(yīng)用。2.4單一職責(zé)原則示例3：?jiǎn)我宦氊?zé)原則——大學(xué)學(xué)生管理工作的類設(shè)計(jì)大學(xué)學(xué)生工作主要包括學(xué)生生活輔導(dǎo)和學(xué)生學(xué)業(yè)指導(dǎo)兩個(gè)方面的工作，其中生活輔導(dǎo)主要包括班委建設(shè)、出勤統(tǒng)計(jì)、心理輔導(dǎo)、費(fèi)用催繳、班級(jí)管理等工作，學(xué)業(yè)指導(dǎo)主要包括專業(yè)引導(dǎo)、學(xué)習(xí)輔導(dǎo)、科研指導(dǎo)、競(jìng)賽輔導(dǎo)等工作。2.5接口隔離原則接口隔離原則（InterfaceSegregationPrinciple，ISP）要求程序員盡量將臃腫龐大的接口拆分成更小的和更具體的接口，讓接口中只包含客戶必須使用方法的最小集合。2002年羅伯特·C·馬丁給“接口隔離原則”的定義是：客戶端不應(yīng)該被迫依賴于它不使用的方法（Clientsshouldnotbeforcedtodependonmethodstheydonotuse）。該原則還有另外一個(gè)定義：一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上（Thedependencyofoneclasstoanotheroneshoulddependonthesmallestpossibleinterface）。2.5接口隔離原則接口隔離原則和單一職責(zé)都是為了提高類的內(nèi)聚性、降低它們之間的耦合性，體現(xiàn)了封裝的思想，但兩者是不同的：（1）單一職責(zé)原則注重的是職責(zé)，而接口隔離原則注重的是對(duì)接口依賴的隔離。（2）單一職責(zé)原則主要是約束類，它針對(duì)的是程序中的實(shí)現(xiàn)和細(xì)節(jié)；接口隔離原則主要約束接口，主要針對(duì)抽象和程序整體框架的構(gòu)建。2.5接口隔離原則1.接口隔離原則的優(yōu)點(diǎn)（1）將臃腫龐大的接口分解為多個(gè)粒度小的接口，可以預(yù)防外來(lái)變更的擴(kuò)散，提高系統(tǒng)的靈活性和可維護(hù)性。（2）接口隔離提高了系統(tǒng)的內(nèi)聚性，減少了對(duì)外交互，降低了系統(tǒng)的耦合性。（3）接口的粒度大小定義合理，能夠保證系統(tǒng)的穩(wěn)定性；但是，如果定義過(guò)小，則會(huì)造成接口數(shù)量過(guò)多，使設(shè)計(jì)復(fù)雜化；如果定義太大，靈活性降低，無(wú)法提供定制服務(wù)，給整體項(xiàng)目帶來(lái)無(wú)法預(yù)料的風(fēng)險(xiǎn)。（4）使用多個(gè)專門的接口還能夠體現(xiàn)對(duì)象的層次，因?yàn)榭梢酝ㄟ^(guò)接口的繼承，實(shí)現(xiàn)對(duì)總接口的定義。（5）能減少項(xiàng)目工程中的代碼冗余。過(guò)大的接口里面通常放置許多不用的方法，當(dāng)實(shí)現(xiàn)這個(gè)接口的時(shí)候，被迫設(shè)計(jì)冗余的代碼。2.5接口隔離原則2.接口隔離原則的實(shí)現(xiàn)方法在具體應(yīng)用接口隔離原則時(shí)，應(yīng)該注意以下事項(xiàng)。（1）接口盡量小，但是要有限度。一個(gè)接口只服務(wù)于一個(gè)子模塊或業(yè)務(wù)邏輯。（2）為依賴接口的類定制服務(wù)。只提供調(diào)用者需要的方法，屏蔽不需要的方法。（3）了解環(huán)境，拒絕盲從。每個(gè)項(xiàng)目或服務(wù)都有特定的應(yīng)用領(lǐng)域和業(yè)務(wù)環(huán)境，要求不同，接口拆分的標(biāo)準(zhǔn)就不同，需要深入了解業(yè)務(wù)邏輯。（4）提高內(nèi)聚，減少對(duì)外交互。使接口用最少的方法去完成更多的工作。2.5接口隔離原則示例4：接口隔離原則——學(xué)生成績(jī)管理的類設(shè)計(jì)2.6迪米特法則迪米特法則（LawofDemeter，LoD）又稱之為最少知識(shí)原則（LeastKnowledgePrinciple，LKP)，產(chǎn)生于1987年美國(guó)東北大學(xué)（NortheasternUniversity）的一個(gè)名為迪米特（Demeter）的研究項(xiàng)目，由伊恩·荷蘭（IanHolland）提出，被UML創(chuàng)始者之一的布奇（Booch）普及，后來(lái)又因?yàn)樵诮?jīng)典著作《程序員修煉之道》（ThePragmaticProgrammer）提及而廣為人知。迪米特法則的定義是：只與你的直接朋友交談，不跟“陌生人”說(shuō)話（Talkonlytoyourimmediatefriendsandnottostrangers）。其含義是：如果兩個(gè)軟件實(shí)體無(wú)須直接通信，那么就不應(yīng)當(dāng)發(fā)生直接的相互調(diào)用，可以通過(guò)第三方轉(zhuǎn)發(fā)該調(diào)用。其目的是降低類之間的耦合度，提高模塊的相對(duì)獨(dú)立性。2.6迪米特法則1.迪米特法則的優(yōu)點(diǎn)迪米特法則要求限制軟件實(shí)體之間通信的寬度和深度，正確使用迪米特法則將有以下兩個(gè)優(yōu)點(diǎn)。（1）降低了類之間的耦合度，提高了模塊的相對(duì)獨(dú)立性。（2）由于耦合度降低，從而提高了類的可復(fù)用率和系統(tǒng)的擴(kuò)展性。但是，過(guò)度使用迪米特法則會(huì)使系統(tǒng)產(chǎn)生大量的中介類，從而增加系統(tǒng)的復(fù)雜性，使模塊之間的通信效率降低。所以，在釆用迪米特法則時(shí)需要反復(fù)權(quán)衡，確保高內(nèi)聚和低耦合的同時(shí)，保證系統(tǒng)的結(jié)構(gòu)清晰。2.6迪米特法則2.迪米特法則的實(shí)現(xiàn)方法從迪米特法則的定義和特點(diǎn)可知，它強(qiáng)調(diào)以下兩點(diǎn)：（1）從依賴者的角度來(lái)說(shuō)，只依賴應(yīng)該依賴的對(duì)象。（2）從被依賴者的角度說(shuō)，只暴露應(yīng)該暴露的方法。2.6迪米特法則在運(yùn)用迪米特法則時(shí)要注意以下六點(diǎn)：（1）在類的劃分上，應(yīng)該創(chuàng)建弱耦合的類。類與類之間的耦合越弱，就越有利于實(shí)現(xiàn)可復(fù)用的目標(biāo)。（2）在類的結(jié)構(gòu)設(shè)計(jì)上，盡量降低類成員的訪問(wèn)權(quán)限。（3）在類的設(shè)計(jì)上，優(yōu)先考慮將一個(gè)類設(shè)置成不變類。（4）在對(duì)其他類的引用上，將引用其他對(duì)象的次數(shù)降到最低。（5）不暴露類的屬性成員，而應(yīng)該提供相應(yīng)的訪問(wèn)器（setter和getter方法）。（6）謹(jǐn)慎使用序列化（Serializable）功能。2.6迪米特法則示例5：迪米特法則——藝人與經(jīng)紀(jì)人的類設(shè)計(jì)2.7合成復(fù)用原則合成復(fù)用原則（CompositeReusePrinciple，CRP）又叫組合/聚合復(fù)用原則（Composition/AggregateReusePrinciple，CARP），它要求在軟件復(fù)用時(shí)，要盡量先使用組合或者聚合等關(guān)聯(lián)關(guān)系來(lái)實(shí)現(xiàn)，其次才考慮使用繼承關(guān)系來(lái)實(shí)現(xiàn)。如果要使用繼承關(guān)系，則必須嚴(yán)格遵循里氏替換原則。合成復(fù)用原則同里氏替換原則相輔相成的，兩者都是開(kāi)閉原則的具體實(shí)現(xiàn)規(guī)范。2.7合成復(fù)用原則1.合成復(fù)用原則的重要性

通常類的復(fù)用分為繼承復(fù)用和合成復(fù)用兩種，繼承復(fù)用雖然有簡(jiǎn)單和易實(shí)現(xiàn)的優(yōu)點(diǎn)，但它也存在以下三個(gè)缺點(diǎn)：（1）繼承復(fù)用破壞了類的封裝性。因?yàn)槔^承會(huì)將父類的實(shí)現(xiàn)細(xì)節(jié)暴露給子類，父類對(duì)子類是透明的，所以這種復(fù)用又稱為“白箱”復(fù)用。（2）子類與父類的耦合度高。父類實(shí)現(xiàn)的任何改變都會(huì)導(dǎo)致子類的實(shí)現(xiàn)發(fā)生變化，這不利于類的擴(kuò)展與維護(hù)。（3）限制了復(fù)用的靈活性。從父類繼承而來(lái)的實(shí)現(xiàn)（屬性和方法）是靜態(tài)的，在編譯時(shí)已經(jīng)確定，所以在運(yùn)行時(shí)不可能發(fā)生變化。2.7合成復(fù)用原則三個(gè)優(yōu)點(diǎn)：（1）維持了類的封裝性。因?yàn)槌蓡T對(duì)象的內(nèi)部細(xì)節(jié)是新對(duì)象看不見(jiàn)的，所以這種復(fù)用又稱為“黑箱”復(fù)用。（2）類之間的耦合度低。這種復(fù)用所需的依賴較少，新對(duì)象存取成員對(duì)象的唯一方法是通過(guò)成員對(duì)象的接口。（3）復(fù)用的靈活性高。這種復(fù)用可以在運(yùn)行時(shí)動(dòng)態(tài)進(jìn)行，新對(duì)象可以動(dòng)態(tài)地引用與成員對(duì)象類型相同的對(duì)象。2.7合成復(fù)用原則2.合成復(fù)用原則的實(shí)現(xiàn)方法合成復(fù)用原則是通過(guò)將已有的對(duì)象納入新對(duì)象中，作為新對(duì)象的成員對(duì)象來(lái)實(shí)現(xiàn)的，新對(duì)象可以調(diào)用已有對(duì)象的功能，從而達(dá)到復(fù)用。該原則在軟件開(kāi)發(fā)框架，例如：MyBatis中，具有廣泛的應(yīng)用。2.7合成復(fù)用原則示例6：合成復(fù)用原則——汽車分類管理的類設(shè)計(jì)2.7合成復(fù)用原則總結(jié)

本節(jié)介紹的7種基本原則，是各種軟件設(shè)計(jì)模式的基礎(chǔ)，是各種設(shè)計(jì)模式都要遵守的規(guī)范，其目的只有一個(gè)：降低對(duì)象之間的耦合，增加程序的可復(fù)用性、可擴(kuò)展性和可維護(hù)性。對(duì)于這些基本規(guī)則，可以歸納為：訪問(wèn)加限制，函數(shù)要節(jié)儉，依賴要減少，動(dòng)態(tài)加接口，父類要抽象，擴(kuò)展不更改。

就像我們?cè)谌粘Ｉ钪?，在做事情之前都要先定好?guī)則，對(duì)做事情增加一些約束和限制，確保不越界?！皼](méi)有規(guī)矩，不成方圓”，凡事都有其固有的規(guī)律。人們要想實(shí)現(xiàn)預(yù)期的目的，就必須按其規(guī)律行事。3使用設(shè)計(jì)模式的優(yōu)點(diǎn)設(shè)計(jì)模式的本質(zhì)是面向?qū)ο笤O(shè)計(jì)原則的實(shí)際運(yùn)用，是對(duì)類的封裝性、繼承性和多態(tài)性以及類的各種關(guān)聯(lián)關(guān)系的在實(shí)際應(yīng)用中的經(jīng)驗(yàn)總結(jié)。在軟件開(kāi)發(fā)中遵循軟件設(shè)計(jì)模式的規(guī)范要求，能夠使代碼的編寫更加規(guī)范、高效、易懂，在應(yīng)用能夠更好的做到代碼復(fù)用。3.1項(xiàng)目代碼優(yōu)劣的評(píng)價(jià)原則代碼是所有軟件項(xiàng)目都具有的“成果”，是軟件實(shí)現(xiàn)的“基本零件”，也是軟件產(chǎn)品中最真實(shí)的存在，類似構(gòu)成硬件產(chǎn)品的基本組件。1.可維護(hù)性2.可理解性3.可擴(kuò)展性4.可復(fù)用性3.2使用設(shè)計(jì)模式帶來(lái)的變化

在軟件項(xiàng)目開(kāi)發(fā)中正確使用軟件設(shè)計(jì)模式，不僅能夠提高軟件項(xiàng)目的健壯性和容錯(cuò)能力，同時(shí)還能夠減少項(xiàng)目開(kāi)發(fā)的工作量，節(jié)約項(xiàng)目成本。同時(shí)能夠提高程序員的思維能力、編程能力和設(shè)計(jì)能力；還可以使程序設(shè)計(jì)更加標(biāo)準(zhǔn)化、代碼編制更加工程化，使軟件開(kāi)發(fā)效率大大提高，從而縮短軟件的開(kāi)發(fā)周期。

當(dāng)然，軟件設(shè)計(jì)模式只是一個(gè)引導(dǎo)，在具體的軟件開(kāi)發(fā)中，必須根據(jù)設(shè)計(jì)的應(yīng)用系統(tǒng)特點(diǎn)和要求來(lái)恰當(dāng)選擇。對(duì)于簡(jiǎn)單的程序開(kāi)發(fā)，若能寫一個(gè)簡(jiǎn)單的算法要比引入某種設(shè)計(jì)模式更加容易。但對(duì)大項(xiàng)目的開(kāi)發(fā)或者框架設(shè)計(jì)，用設(shè)計(jì)模式來(lái)組織代碼顯然更好，這也是現(xiàn)在大型軟件系統(tǒng)開(kāi)發(fā)所采用的方式。4習(xí)題1.開(kāi)閉原則的核心思想是什么？2.依賴倒置原則在項(xiàng)目開(kāi)發(fā)中如何體現(xiàn)？3.單一職責(zé)原則與接口隔離原則的聯(lián)系與區(qū)別是什么？4.面向?qū)ο蟪绦蛟O(shè)計(jì)中的類繼承關(guān)系與合成復(fù)用原則的區(qū)別是什么？5.遵循軟件設(shè)計(jì)模式在軟件項(xiàng)目開(kāi)發(fā)中能夠帶來(lái)什么樣的好處？軟件架構(gòu)設(shè)計(jì)實(shí)戰(zhàn)——基于SSM框架Software

Architecture

Design

Practice

Based

on

SSM

Framework第2章典型軟件設(shè)計(jì)模式123單例模式原型模式工廠模式4建造者模式5代理模式6MVC模式單例模式

單例（Singleton）模式是指一個(gè)類只有一個(gè)實(shí)例，且該類能自行創(chuàng)建這個(gè)實(shí)例的一種軟件設(shè)計(jì)模式。例如，Windows中只能打開(kāi)一個(gè)任務(wù)管理器，這樣可以避免因打開(kāi)多個(gè)任務(wù)管理器窗口而造成內(nèi)存資源的浪費(fèi)，或出現(xiàn)各個(gè)窗口顯示內(nèi)容的不一致等錯(cuò)誤。

單例模式在現(xiàn)實(shí)生活中的應(yīng)用也非常廣泛，例如公司CEO、部門經(jīng)理等都屬于單例模型。J2EE標(biāo)準(zhǔn)中的ServletContext和ServletContextConfig、Spring框架應(yīng)用中的ApplicationContext、數(shù)據(jù)庫(kù)中的連接池等也都是單例模式。1單例模式單例模式主要具有3個(gè)特點(diǎn)：1.單例類只有一個(gè)實(shí)例對(duì)象；2.該單例對(duì)象必須由單例類自行創(chuàng)建；3.單例類對(duì)外提供一個(gè)訪問(wèn)該單例的全局訪問(wèn)點(diǎn)。1單例模式單例模式在應(yīng)用當(dāng)中較為方便，且生命周期管理也比較簡(jiǎn)單，主要優(yōu)點(diǎn)包括以下3個(gè)方面：①

單例模式可以保證內(nèi)存里只有一個(gè)實(shí)例，減少了內(nèi)存的開(kāi)銷。②

單例模式可以避免對(duì)資源的多重占用。③

單例模式設(shè)置全局訪問(wèn)點(diǎn)，可以優(yōu)化和共享資源的訪問(wèn)。1單例模式單例模式主要有以下3個(gè)方面的缺點(diǎn)：①

單例模式一般沒(méi)有接口，擴(kuò)展困難。如果要擴(kuò)展，則除了修改原來(lái)的代碼，沒(méi)有第二種途徑，違背開(kāi)閉原則。②

在并發(fā)測(cè)試中，單例模式不利于代碼調(diào)試。在調(diào)試過(guò)程中，如果單例中的代碼沒(méi)有執(zhí)行完，也不能模擬生成一個(gè)新的對(duì)象。③

單例模式的功能代碼通常寫在一個(gè)類中，如果功能設(shè)計(jì)不合理，則很容易違背單一職責(zé)原則。1單例模式單例模式的應(yīng)用場(chǎng)景主要有以下5個(gè)方面。1.需要頻繁創(chuàng)建的一些類，使用單例模式可以降低系統(tǒng)的內(nèi)存壓力，減少垃圾回收（GarbageCollection簡(jiǎn)稱GC）頻率。2.某個(gè)類在運(yùn)行期間只能生成一個(gè)對(duì)象的時(shí)候，如SpringMVC框架中的核心控制器DispatchServlet實(shí)例。3.某些類創(chuàng)建實(shí)例時(shí)占用資源較多，或?qū)嵗臅r(shí)較長(zhǎng)，且經(jīng)常使用，例如MyBatis框架中的SqlSessionFactory實(shí)例。4.某類需要頻繁實(shí)例化，而創(chuàng)建的對(duì)象又頻繁被銷毀的時(shí)候，如多線程的線程池、網(wǎng)絡(luò)連接池等。5.某個(gè)實(shí)例需要在應(yīng)用中被共享使用，由于單例模式只允許創(chuàng)建一個(gè)對(duì)象，共享該對(duì)象可以節(jié)省內(nèi)存，并加快對(duì)象訪問(wèn)速度。如Web應(yīng)用中的配置管理對(duì)象。1單例模式單例模式的結(jié)構(gòu)在單例模式中必須由所在類來(lái)完成對(duì)象的創(chuàng)建，然后供其他類調(diào)用，一般稱之為單例類；在訪問(wèn)類中通過(guò)單例類提供的靜態(tài)方法獲取單例類的實(shí)例，然后調(diào)用相應(yīng)方法。1單例模式單例模式的實(shí)現(xiàn)①懶加載單例模式publicclassLazySingleton{privatestaticvolatileLazySingletoninstance=null;//保證instance在所有線程中同步privateLazySingleton(){//private避免類在外部被實(shí)例化}publicstaticsynchronizedLazySingletongetInstance(){//getInstance方法前加同步if(instance==null){instance=newLazySingleton();}returninstance;}}1單例模式單例模式的實(shí)現(xiàn)②預(yù)加載單例模式publicclassPreSingleton{privatestaticfinalPreSingletoninstance=newPreSingleton();privatePreSingleton(){}publicstaticPreSingletongetInstance(){returninstance;}}1原型模式

在有些系統(tǒng)中，存在大量相同或相似對(duì)象的創(chuàng)建問(wèn)題，如果用傳統(tǒng)的構(gòu)造函數(shù)來(lái)創(chuàng)建對(duì)象，會(huì)比較復(fù)雜且耗時(shí)耗資源，用原型模式生成對(duì)象就比較高效。

2原型模式1.原型模式的定義與特點(diǎn)原型（Prototype）模式是指用一個(gè)已經(jīng)創(chuàng)建好的實(shí)例作為原型，通過(guò)復(fù)制該原型對(duì)象來(lái)創(chuàng)建一個(gè)和原型相同或相似的新對(duì)象。用這種方式創(chuàng)建對(duì)象非常高效，根本無(wú)須知道對(duì)象創(chuàng)建的細(xì)節(jié)。而且Java自帶的原型模式基于內(nèi)存二進(jìn)制流的復(fù)制，在性能上比直接創(chuàng)建（new）一個(gè)對(duì)象更加優(yōu)良。同時(shí)可以使用深克隆方式保存對(duì)象的狀態(tài)，使用原型模式將對(duì)象復(fù)制一份，并將其狀態(tài)保存起來(lái)，簡(jiǎn)化了創(chuàng)建對(duì)象的過(guò)程，以便在需要的時(shí)候使用（例如恢復(fù)到歷史某一狀態(tài)），可輔助實(shí)現(xiàn)撤銷操作。2原型模式2.原型模式的應(yīng)用場(chǎng)景（1）對(duì)象之間相同或相似，即只是個(gè)別的幾個(gè)屬性不同的時(shí)候。（2）創(chuàng)建對(duì)象成本較大，例如初始化時(shí)間長(zhǎng)，占用CPU太多，或者占用網(wǎng)絡(luò)資源太多等，需要優(yōu)化資源。（3）創(chuàng)建一個(gè)對(duì)象需要繁瑣的數(shù)據(jù)準(zhǔn)備或訪問(wèn)權(quán)限等，需要提高性能或者提高安全性。（4）系統(tǒng)中大量使用該類對(duì)象，各個(gè)調(diào)用者都需要給它的屬性重新賦值。在Spring中，原型模式應(yīng)用的非常廣泛，例如scope=‘prototype’、JSON.parseObject()等都是原型模式的具體應(yīng)用。2原型模式3.原型模式的結(jié)構(gòu)由于Java提供了對(duì)象的clone()方法，所以用Java實(shí)現(xiàn)原型模式很簡(jiǎn)單。原型模式包含以下3個(gè)主要角色：（1）抽象原型類：規(guī)定了具體原型對(duì)象必須實(shí)現(xiàn)的接口。（2）具體原型類：實(shí)現(xiàn)抽象原型類的clone()方法，它是可被復(fù)制的對(duì)象。（3）訪問(wèn)類：使用具體原型類中的clone()方法來(lái)復(fù)制新的對(duì)象。2原型模式

2原型模式的類結(jié)構(gòu)圖原型模式4.原型模式的實(shí)現(xiàn)原型模式的克隆分為淺克隆和深克隆。淺克?。簞?chuàng)建一個(gè)新對(duì)象，新對(duì)象的屬性和原來(lái)對(duì)象完全相同，對(duì)于非基本類型屬性，仍指向原有屬性所指向的對(duì)象的內(nèi)存地址。深克隆：創(chuàng)建一個(gè)新對(duì)象，屬性中引用的其他對(duì)象也會(huì)被克隆，不再指向原有對(duì)象地址。Java中的Object類提供了淺克隆的clone()方法，具體原型類只要實(shí)現(xiàn)Cloneable接口就可實(shí)現(xiàn)對(duì)象的淺克隆，這里的Cloneable接口就是抽象原型類。2原型模式2//具體原型類classRealizetypeimplementsCloneable{Realizetype(){System.out.println("具體原型創(chuàng)建成功！");}publicObjectclone()throwsCloneNotSupportedException{System.out.println("具體原型復(fù)制成功！");return(Realizetype)super.clone();}}//原型模式的測(cè)試類publicclassPrototypeTest{@Testpublicvoidtest()throwsCloneNotSupportedException{RealizeTypeo1=newRealizeType();RealizeTypeo2=(RealizeType)o1.clone();System.out.println("o1==o2?"+(o1==o2));}}工廠模式

工廠模式在框架應(yīng)用中是最常見(jiàn)的軟件設(shè)計(jì)模式，例如Spring框架、Struts框架等，工廠模式主要分為3種類型：簡(jiǎn)單工廠模式、工廠方法模式和抽象工程模式。

現(xiàn)實(shí)生活中，原始社會(huì)是自給自足，所有需要都是自己生產(chǎn)（沒(méi)有工廠），農(nóng)耕社會(huì)就存在一些小作坊、民間酒坊等（簡(jiǎn)單工廠模式），在工業(yè)革命時(shí)代就出現(xiàn)了流水線生產(chǎn)（工廠方法模式），在現(xiàn)代產(chǎn)業(yè)鏈中就出現(xiàn)了代工廠（抽象工廠模式），一些企業(yè)只做研發(fā)和設(shè)計(jì)（例如蘋果公司等），而另外一些企業(yè)只負(fù)責(zé)生產(chǎn)（例如富士康等）。軟件項(xiàng)目代碼同樣是由簡(jiǎn)到繁一步一步迭代而來(lái)的，但對(duì)于調(diào)用者來(lái)說(shuō)，采用工廠模式卻是越來(lái)越簡(jiǎn)單。

工廠模式最主要的目的就是把“對(duì)象的創(chuàng)建與使用相分離”，工廠只負(fù)責(zé)對(duì)象的創(chuàng)建，而使用者只負(fù)責(zé)調(diào)用。在工廠模式中，被創(chuàng)建的對(duì)象成為“產(chǎn)品”，把創(chuàng)建產(chǎn)品的對(duì)象成為“工廠”。33.1簡(jiǎn)單工廠模式在應(yīng)用中，如果要?jiǎng)?chuàng)建的產(chǎn)品不多，只要一個(gè)工廠類就可以完成，這種模式叫“簡(jiǎn)單工廠模式”。在簡(jiǎn)單工廠模式中創(chuàng)建對(duì)象的方法通常為靜態(tài)(static)方法，因此簡(jiǎn)單工廠模式（SimpleFactoryPattern）又稱為靜態(tài)工廠方法模式（StaticFactoryMethodPattern）。3.1簡(jiǎn)單工廠模式1.簡(jiǎn)單工廠模式的優(yōu)點(diǎn)：①在工廠類中包含了必要的邏輯判斷，可以決定在什么時(shí)候創(chuàng)建哪一個(gè)產(chǎn)品的實(shí)例。調(diào)用者可以很方便的創(chuàng)建出相應(yīng)的產(chǎn)品。工廠和產(chǎn)品的職責(zé)區(qū)分明確；②調(diào)用者無(wú)需知道所創(chuàng)建具體產(chǎn)品的類名，只需知道相應(yīng)參數(shù)即可；③也可以引入配置文件，在不修改調(diào)用者代碼的情況下更換和添加新的具體產(chǎn)品類。3.1簡(jiǎn)單工廠模式2.簡(jiǎn)單工廠模式的缺點(diǎn)：①簡(jiǎn)單工廠模式的工廠類單一，負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，職責(zé)過(guò)重，一旦異常，整個(gè)系統(tǒng)將受影響，且工廠類代碼會(huì)非常臃腫，違背高聚合原則；②使用簡(jiǎn)單工廠模式會(huì)增加系統(tǒng)中類的個(gè)數(shù)（引入新的工廠類），增加系統(tǒng)的復(fù)雜度和理解難度；③系統(tǒng)擴(kuò)展困難，一旦增加新產(chǎn)品不得不修改工廠邏輯，在產(chǎn)品類型較多時(shí)，可能造成邏輯過(guò)于復(fù)雜；④簡(jiǎn)單工廠模式使用了static工廠方法，造成工廠角色無(wú)法形成基于繼承的等級(jí)結(jié)構(gòu)。3.1簡(jiǎn)單工廠模式簡(jiǎn)單工廠模式的類結(jié)構(gòu)圖3.2工廠方法模式

簡(jiǎn)單工廠模式每增加一個(gè)產(chǎn)品就要增加一個(gè)具體產(chǎn)品類和一個(gè)對(duì)應(yīng)的具體工廠類，這增加了系統(tǒng)的復(fù)雜度，違背了“開(kāi)閉原則”。工廠方法模式是對(duì)“工廠”做進(jìn)一步的抽象，得到抽象工廠，然后由具體工廠實(shí)現(xiàn)抽象工廠并負(fù)責(zé)某一產(chǎn)品的生產(chǎn)。工廠方法模式可以使系統(tǒng)在不修改原來(lái)代碼的情況下引進(jìn)新的產(chǎn)品，即滿足開(kāi)閉原則。3.2工廠方法模式工廠方法模式的優(yōu)點(diǎn)：①用戶只需要知道具體工廠的名稱就可得到所要的產(chǎn)品，無(wú)須知道產(chǎn)品的具體創(chuàng)建過(guò)程；②靈活性增強(qiáng)，對(duì)于新產(chǎn)品的創(chuàng)建，只需多寫一個(gè)相應(yīng)的工廠類；③典型的解耦框架，在應(yīng)用當(dāng)中較為常見(jiàn)，高層模塊只需要知道產(chǎn)品的抽象類，無(wú)須關(guān)心其具體實(shí)現(xiàn)類，滿足迪米特法則、依賴倒置原則和里氏替換原則。3.2工廠方法模式工廠方法模式的缺點(diǎn)：①類的個(gè)數(shù)容易過(guò)多，增加了復(fù)雜度；②增加了系統(tǒng)的抽象性和理解的難度；3.2工廠方法模式工廠方法模式的結(jié)構(gòu)與實(shí)現(xiàn)工廠方法模式由抽象工廠、具體工廠、抽象產(chǎn)品和具體產(chǎn)品等4個(gè)要素構(gòu)成。①抽象工廠（AbstractFactory）：提供了創(chuàng)建產(chǎn)品的接口，調(diào)用者通過(guò)它訪問(wèn)具體工廠的工廠方法來(lái)創(chuàng)建產(chǎn)品；②具體工廠（SpecificFactory）：主要是實(shí)現(xiàn)抽象工廠中的抽象方法，完成具體產(chǎn)品的創(chuàng)建；③抽象產(chǎn)品（AbstractProduct）：定義了產(chǎn)品的規(guī)范，描述了產(chǎn)品的主要特性和功能；④具體產(chǎn)品（Product）：實(shí)現(xiàn)了抽象產(chǎn)品角色所定義的接口，由具體工廠來(lái)創(chuàng)建，它同具體工廠之間一一對(duì)應(yīng)。3.2工廠方法模式工廠方法模式的類結(jié)構(gòu)圖3.2工廠方法模式在工廠方法模式中，具體生產(chǎn)哪種產(chǎn)品，一般是配置在XML文件中的，例如：Spring、SpringMVC、MyBatis等，代碼示例如下所示。<?xmlversion="1.0"encoding="UTF-8"?><config><className>SpecificFactory1</className></config>3.3抽象工廠模式抽象工廠模式就是要考慮多等級(jí)產(chǎn)品的生產(chǎn)，即一個(gè)工廠可以生產(chǎn)多個(gè)等級(jí)的產(chǎn)品，例如A電器廠既可以生產(chǎn)電視機(jī)還可以生產(chǎn)空調(diào)，這里稱之為一個(gè)產(chǎn)品族；同一個(gè)等級(jí)的產(chǎn)品又可以由不同的生產(chǎn)商來(lái)生產(chǎn)，例如：空調(diào)有A工廠生產(chǎn)的還有B工廠生產(chǎn)的，這里稱之為一個(gè)產(chǎn)品等級(jí)。33.3抽象工廠模式使用抽象工廠模式一般要滿足以下條件：（1）系統(tǒng)中有多個(gè)產(chǎn)品族，每個(gè)具體工廠創(chuàng)建同一族但屬于不同等級(jí)結(jié)構(gòu)的產(chǎn)品。（2）系統(tǒng)一次只可能消費(fèi)其中某一族產(chǎn)品，即同族的產(chǎn)品可以一起使用。33.3抽象工廠模式抽象工廠模式除了具有工廠方法模式的優(yōu)點(diǎn)外，還具有以下優(yōu)點(diǎn)：（1）可以在類的內(nèi)部對(duì)產(chǎn)品族中相關(guān)聯(lián)的多等級(jí)產(chǎn)品共同管理，而不必專門引入多個(gè)新的類來(lái)進(jìn)行管理。（2）當(dāng)需要產(chǎn)品族時(shí)，抽象工廠可以保證客戶端始終只使用同一個(gè)產(chǎn)品的產(chǎn)品族。（3）抽象工廠增強(qiáng)了程序的可擴(kuò)展性，當(dāng)增加一個(gè)新的產(chǎn)品族時(shí)，不需要修改原代碼，更好滿足開(kāi)閉原則。其缺點(diǎn)是：當(dāng)產(chǎn)品族中需要增加一個(gè)新的產(chǎn)品時(shí)，所有的工廠類都需要進(jìn)行修改。增加了系統(tǒng)的抽象性和理解難度。33.3抽象工廠模式抽象工廠模式的4個(gè)要素如下：①抽象工廠（AbstractFactory）：提供了創(chuàng)建產(chǎn)品的接口，它包含多個(gè)創(chuàng)建產(chǎn)品的方法，可以創(chuàng)建多個(gè)不同等級(jí)的產(chǎn)品。②具體工廠（SpecificFactory）：主要是實(shí)現(xiàn)抽象工廠中的多個(gè)抽象方法，完成具體產(chǎn)品的創(chuàng)建。③抽象產(chǎn)品（AbstractProduct）：定義了產(chǎn)品的規(guī)范，描述了產(chǎn)品的主要特性和功能，抽象工廠模式有多個(gè)抽象產(chǎn)品。④具體產(chǎn)品（Product）：實(shí)現(xiàn)了抽象產(chǎn)品接口所定義的方法，由具體工廠來(lái)創(chuàng)建，它同具體工廠之間是多對(duì)一的關(guān)系。33.3抽象工廠模式3抽象工廠模式的類結(jié)構(gòu)圖3.3抽象工廠模式抽象工廠模式的實(shí)現(xiàn)①抽象工廠：提供了產(chǎn)品的生成方法，其主要代碼如下所示：interfaceAbstractFactory{publicAbstractProduct1getProduct1();publicAbstractProduct2getProduct2();}②具體工廠：實(shí)現(xiàn)了產(chǎn)品的生成方法，其主要代碼如下所示：classSpecificFactory1implementsAbstractFactory{publicProduct1getProduct1(){System.out.println("具體工廠1生成-->具體產(chǎn)品11...");returnnewProduct11();}publicProduct2getProduct2(){System.out.println("具體工廠2生成-->具體產(chǎn)品21...");returnnewProduct21();}}3課程思政工廠模式的思想來(lái)源于社會(huì)生產(chǎn)勞動(dòng)的大分工，工廠是工業(yè)生產(chǎn)的基礎(chǔ)，通過(guò)工廠的工業(yè)化生產(chǎn)，極大地豐富了人們的物質(zhì)生活，提供了勞動(dòng)效率，促進(jìn)了社會(huì)進(jìn)步和科學(xué)技術(shù)發(fā)展。中國(guó)早已成為世界工廠，中國(guó)制造享譽(yù)全球，中國(guó)離不開(kāi)世界，世界也離不開(kāi)中國(guó)。近年來(lái)，隨著中國(guó)科技突飛猛進(jìn)的發(fā)展，中國(guó)制造正在轉(zhuǎn)向中國(guó)智造，傳統(tǒng)的工廠正在轉(zhuǎn)變?yōu)橹悄芑S、無(wú)人化工廠，這將更好的推動(dòng)工業(yè)化生產(chǎn)，也必將促進(jìn)中國(guó)社會(huì)更好的發(fā)展，對(duì)于我國(guó)的軟件產(chǎn)業(yè)而言，這或許是一個(gè)難得的發(fā)展機(jī)遇。請(qǐng)大家堅(jiān)定理想信念，相信隨著國(guó)產(chǎn)替代的不斷深入，卡脖子問(wèn)題將逐步解決，我國(guó)的軟件產(chǎn)業(yè)一定會(huì)大有前途！3建造者模式1.建造者模式的特點(diǎn)建造者模式指將一個(gè)復(fù)雜對(duì)象的構(gòu)造與它的表示相分離，使同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示，這樣的設(shè)計(jì)模式被稱為建造者模式。它是將一個(gè)復(fù)雜的對(duì)象分解為多個(gè)簡(jiǎn)單的對(duì)象，然后一步一步構(gòu)建而成。它將變與不變相分離，即產(chǎn)品的組成部分是不變的，但每一部分是可以靈活選擇的。4建造者模式建造者模式主要有以下3個(gè)方面的優(yōu)點(diǎn)：（1）封裝性好，構(gòu)建和表示相分離；（2）擴(kuò)展性好，各個(gè)具體的建造者相互獨(dú)立，有利于系統(tǒng)的解耦；（3）客戶端不必知道產(chǎn)品內(nèi)部組成細(xì)節(jié)，建造者可以對(duì)創(chuàng)建過(guò)程逐步細(xì)化，而不對(duì)其它模塊產(chǎn)生任何影響，便于控制細(xì)節(jié)風(fēng)險(xiǎn)。4建造者模式建造者模式也有以下2個(gè)方面的缺點(diǎn)：（1）產(chǎn)品的組成部分必須相同，這限制了其使用范圍。（2）如果產(chǎn)品的內(nèi)部變化復(fù)雜，則建造者也要同步修改，后期維護(hù)成本較大。建造者模式和工廠模式的關(guān)注點(diǎn)不同：建造者模式注重零部件的組裝過(guò)程，而工廠方法模式更注重零部件的創(chuàng)建過(guò)程，但兩者可以結(jié)合使用。4建造者模式建造者模式由產(chǎn)品、抽象建造者、具體建造者、指揮者等4個(gè)要素構(gòu)成。①產(chǎn)品（Product）：它是包含多個(gè)組成部件的復(fù)雜對(duì)象，由具體建造者來(lái)創(chuàng)建其各個(gè)零部件。②抽象建造者（AbstractBuilder）：它是一個(gè)包含創(chuàng)建產(chǎn)品各個(gè)子部件的抽象方法的接口，通常還包含一個(gè)返回復(fù)雜產(chǎn)品的方法。③具體建造者(ConcreteBuilder）：實(shí)現(xiàn)Builder接口，完成復(fù)雜產(chǎn)品的各個(gè)部件的具體創(chuàng)建方法。④指揮者（Director）：它調(diào)用建造者對(duì)象中的部件構(gòu)造與裝配方法完成復(fù)雜對(duì)象的創(chuàng)建，在指揮者中不涉及具體產(chǎn)品的信息。4建造者模式4建造者模式的類結(jié)構(gòu)圖建造者模式建造者模式主要適用于以下應(yīng)用場(chǎng)景：（1）相同的方法，不同的執(zhí)行順序，產(chǎn)生不同的結(jié)果；（2）多個(gè)部件或零件，都可以裝配到一個(gè)對(duì)象中，但是產(chǎn)生的結(jié)果又不相同；（3）產(chǎn)品類非常復(fù)雜，或者產(chǎn)品類中不同的調(diào)用順序產(chǎn)生不同的作用；（4）初始化一個(gè)對(duì)象特別復(fù)雜，參數(shù)多，而且很多參數(shù)都具有默認(rèn)值。4建造者模式建造者模式和工廠模式的區(qū)別（1）建造者模式更加注重方法的調(diào)用順序，工廠模式注重創(chuàng)建對(duì)象；（2）創(chuàng)建對(duì)象的力度不同，建造者模式創(chuàng)建復(fù)雜的對(duì)象，由各種復(fù)雜的部件組成，工廠模式創(chuàng)建出來(lái)的對(duì)象都一樣；（3）關(guān)注點(diǎn)不一樣，工廠模式只需要把對(duì)象創(chuàng)建出來(lái)就可以了，而建造者模式不僅要?jiǎng)?chuàng)建出對(duì)象，還要知道對(duì)象由哪些部件組成；（4）建造者模式根據(jù)建造過(guò)程中的順序不一樣，最終對(duì)象部件組成也不一樣。4代理模式

在日常生活中，能夠經(jīng)常見(jiàn)到：租房中介、婚介、律師事務(wù)所等，這些都是代理模式的實(shí)際體現(xiàn)。代理模式的定義也非常簡(jiǎn)單，是指為其它對(duì)象提供一種代理，幫助對(duì)象行使自己的權(quán)利，完成相應(yīng)的功能，并且能夠控制對(duì)這個(gè)對(duì)象的訪問(wèn)。

代理對(duì)象在調(diào)用者（客戶）和目標(biāo)對(duì)象之間起到中介作用，代理模式屬于結(jié)構(gòu)性設(shè)計(jì)模式。使用代理模式主要有兩個(gè)目的：一是保護(hù)目標(biāo)對(duì)象，二是增強(qiáng)目標(biāo)對(duì)象，代理模式的結(jié)構(gòu)類圖如圖。5代理模式5代理模式的類圖結(jié)構(gòu)代理模式代理模式主要包括3個(gè)要素組成：1.抽象主題（AbstractSubject）類：通過(guò)接口或抽象類聲明真實(shí)主題和代理對(duì)象實(shí)現(xiàn)的抽象方法。2.真實(shí)主題（RealSubject）類：實(shí)現(xiàn)了抽象主題中的抽象方法，是代理對(duì)象所代表的真實(shí)對(duì)象，是最終要引用的對(duì)象。3.代理（Proxy）類：提供了與真實(shí)主題相同的接口，其內(nèi)部含有對(duì)真實(shí)主題的引用，它可以訪問(wèn)、控制或擴(kuò)展真實(shí)主題的功能。5代理模式根據(jù)代理的創(chuàng)建時(shí)間不同，代理模式分為靜態(tài)代理和動(dòng)態(tài)代理。1.靜態(tài)代理：由程序員創(chuàng)建代理類或特定工具自動(dòng)生成源代碼再對(duì)其編譯，在程序運(yùn)行前代理類的字節(jié)碼文件（.class）就已經(jīng)存在了；2.動(dòng)態(tài)代理：在程序運(yùn)行時(shí)，運(yùn)用Java語(yǔ)言的反射機(jī)制動(dòng)態(tài)創(chuàng)建而成。代理模式是面向切面編程的基礎(chǔ)，在SpringAOP編程中會(huì)結(jié)合代碼再重點(diǎn)講解靜態(tài)代理和動(dòng)態(tài)代理的具體實(shí)現(xiàn)細(xì)節(jié)。5代理模式主要的應(yīng)用場(chǎng)景包括以下5個(gè)方面：1.遠(yuǎn)程代理2.虛擬代理3.安全代理4.智能指引5.延遲加載5代理模式代理模式主要具有以下3方面的優(yōu)點(diǎn)：1.職責(zé)清晰2.高擴(kuò)展性3.解耦合5代理模式代理模式的簡(jiǎn)單示例5packageproxy;publicclassProxyTest{//調(diào)用者（客戶）publicvoidtest(){Proxyproxy=newProxy();//生成代理對(duì)象proxy.request();//調(diào)用代理對(duì)象方法}}//抽象主題interfaceAbstractSubject{voidrequest();}//真實(shí)主題classRealSubjectimplementsAbstractSubject{publicvoidre