軟件架構設計實踐- 基于SSM框架 課件 第1、2章 軟件設計模式導論、典型軟件設計模式

軟件架構設計實戰(zhàn)——基于SSM框架Software

Architecture

Design

Practice

Based

on

SSM

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

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

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

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

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

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

Architecture

Design

Practice

Based

on

SSM

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

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

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

單例模式可以保證內存里只有一個實例，減少了內存的開銷。②

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

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

單例模式一般沒有接口，擴展困難。如果要擴展，則除了修改原來的代碼，沒有第二種途徑，違背開閉原則。②

在并發(fā)測試中，單例模式不利于代碼調試。在調試過程中，如果單例中的代碼沒有執(zhí)行完，也不能模擬生成一個新的對象。③

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

在有些系統(tǒng)中，存在大量相同或相似對象的創(chuàng)建問題，如果用傳統(tǒng)的構造函數來創(chuàng)建對象，會比較復雜且耗時耗資源，用原型模式生成對象就比較高效。

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

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

工廠模式在框架應用中是最常見的軟件設計模式，例如Spring框架、Struts框架等，工廠模式主要分為3種類型：簡單工廠模式、工廠方法模式和抽象工程模式。

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

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

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

在日常生活中，能夠經常見到：租房中介、婚介、律師事務所等，這些都是代理模式的實際體現。代理模式的定義也非常簡單，是指為其它對象提供一種代理，幫助對象行使自己的權利，完成相應的功能，并且能夠控制對這個對象的訪問。

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