哈爾濱華德學院第1章設計模式簡介1.1什么是設計模式設計模式（pattern）是從許多優(yōu)秀的軟件系統中總結出的成功的可復用的設計方案。每一個設計模式描述一個在我們周圍不斷重復發(fā)生的問題，以及該問題的解決方案的核心。設計模式是對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述。模式體現的是程序整體的構思，所以有時候它也會出現在分析或者是概要設計階段模式的核心思想是通過增加抽象層，把變化部分從那些不變部分里分離出來軟件工程專業(yè)2023/2/131.1什么是設計模式設計模式的四要素模式名稱(PatternName)問題(Problem)解決方案(Solution)效果(consequences)軟件工程專業(yè)2023/2/141.2設計模式的起源軟件領域的設計模式起源于建筑學。

1977年，建筑大師Alexander出版了《APatternLanguage：Towns,Building,Construction》一書。受Alexander著作的影響，KentBeck和WardCunningham在1987年舉行的一次面向對象的會議上發(fā)表了論文：《在面向對象編程中使用模式》。2023/2/1軟件工程專業(yè)51.2設計模式的起源

目前，被公認在設計模式領域最具影響力的著作是ErichGamma、RichardHelm、RalphJohnson和JohnVlissides在1994年合作出版的著作：《DesignPatterns：ElementsofReusableObject-OrientedSoftware》（中譯本《設計模式：可復用的面向對象軟件的基本原理》或《設計模式》），該書被廣大喜愛者昵稱為GOF（GangofFour）之書，被認為是學習設計模式的必讀著作，GOF之書已經被公認為是設計模式領域的奠基之作。2023/2/1軟件工程專業(yè)61.3設計模式的分類設計模式分為三種類型，共23種。創(chuàng)建型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。結構型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。行為型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態(tài)模式、策略模式、職責鏈模式、訪問者模式。2023/2/1軟件工程專業(yè)71.4什么是框架框架通常定義了應用體系的整體結構類和對象的關系等等設計參數，以便于具體應用實現者能集中精力于應用本身的特定細節(jié)?？蚣苤饕涗涇浖弥泄餐脑O計決策，框架強調設計復用，因此框架設計中必然要使用設計模式設計模式有助于對框架結構的理解，成熟的框架通常使用了多種設計模式,如果你熟悉這些設計模式2023/2/1軟件工程專業(yè)8第2章面向對象的幾個基本原則2.1面向抽象原則設計一個類時，不讓該類面向具體的類，而是面向抽象類或接口。包含抽象方法的類稱為抽象類，在面向對象的程序設計思想中，抽象類只能做為父類使用，不能被實例化為對象。Java里面由于不允許多重繼承，所以如果要實現多個類的功能，則可以通過實現多個接口來實現。2023/2/1軟件工程專業(yè)102.2開-閉原則設計應當對擴展開放，對修改關閉。模塊應盡量在不修改原代碼的情況下進行擴展?？梢栽谲浖瓿珊髮浖M行擴展，加入新的功能。這樣，軟件就可通過不斷的增加新模塊滿足不斷變化的新需求。由于不修改軟件原來的模塊，不用擔心軟件的穩(wěn)定性。2023/2/1軟件工程專業(yè)112.3里氏代換原則如果調用的是父類的話，那么換成子類也完全可以運行。2023/2/1軟件工程專業(yè)122.4依賴倒轉原則抽象不應該依賴于細節(jié)，細節(jié)應當依賴于抽象。要針對接口編程，而不是針對實現編程。2023/2/1軟件工程專業(yè)132.5多用組合少用繼承原則設計中避開類繼承的缺點，充分使用對象組合的優(yōu)點。2023/2/1軟件工程專業(yè)142.6高內聚-低耦合原則如果類中的方法是一組相關的行為，則稱該類是高內聚的，反之稱為低內聚的。所謂低耦合就是盡量不要讓一個類含有太多的其它類的實例的引用，以避免修改系統的其中一部分會影響到其它部分。2023/2/1軟件工程專業(yè)15第3章UML類圖簡介3.1類(Class)在UML中，使用一個長方形描述一個類的主要構成，將長方形垂直地分為三層。第1層是名字層，類名字是常規(guī)字形，表明該類是具體類，類名字是斜體字形，表明該類是抽象類。第2層是變量層，也稱屬性層，列出類的成員變量及類型，格式是“變量名字：類型”。第3層是方法層，也稱操作層，列出類的方法及返回類型，格式是“方法名字（參數列表）：類型”2023/2/1軟件工程專業(yè)173.1類(Class)2023/2/1軟件工程專業(yè)18Student+name:String#age:int-money:double+setName(String):void#printMess():void+getAge():intsetAge(int):void-getMoney();名字層

變量層

方法層

+#--protected的private的友好的的public的變量或方法的訪問權限是名字前加3.2接口（Interface）表示接口的UML圖和表示類的UML圖類似，使用一個長方形描述一個接口的主要構成，將長方形垂直地分為三層。第1層是名字層，接口的名字必須是斜體字形，而且需要用<<interface>>修飾名字，并且該修飾和名字分列在2行。第2層是常量層，列出接口中的常量及類型，格式是“常量名字：類型”。第3層是方法層，也稱操作層，列出接口中的方法及返回類型，格式是“方法名字（參數列表）：類型”。2023/2/1軟件工程專業(yè)193.2接口（Interface）2023/2/1軟件工程專業(yè)20<<interface>>Creator

+MAX:int+factoryMethod():Product名字層

常量層

方法層

+public的常量或方法的訪問權限是名字前加3.3泛化關系（Generalization）2023/2/1軟件工程專業(yè)21

對于面向對象語言，UML中所說的泛化關系就是指類的繼承關系。如果一個類是另一個類的子類，那么UML通過使用一個實線連接兩個類的UML圖來表示二者之間的繼承關系，實線的起始端是子類的UML圖，終點端是父類的UML圖，但終點端使用一個空心的三角形表示實線的結束。3.4關聯關系2023/2/1軟件工程專業(yè)22

如果A類中成員變量是用B類（接口）來聲明的變量，那么A和B的關系是關聯關系，稱A關聯于B。那么UML通過使用一個實線連A和B的UML圖，實線的起始端是A的UML圖，終點端是B的UML圖，但終點端使用一個指向B的UML圖的方向箭頭表示實線的結束。3.5依賴關系2023/2/1軟件工程專業(yè)23

如果A類中某個方法的參數用B類（接口）來聲明的變量或某個方法返回的數據類型是B類型的，那么A和B的關系是依賴關系，稱A依賴于B。那么UML通過使用一個虛線連A和B的UML圖，虛線的起始端是A的UML圖，終點端是B的UML圖，但終點端使用一個指向B的UML圖的方向箭頭表示虛線的結束。3.6實現關系2023/2/1軟件工程專業(yè)24

如果一個類實現了一個接口，那么類和接口的關系是實現關系，稱類實現接口。UML通過使用虛線連接類和它所實現的接口，虛線起始端是類，虛線的終點端是它實現的接口，但終點端使用一個空心的三角形表示虛線的結束。3.7注釋2023/2/1軟件工程專業(yè)25UML使用注釋為類圖提供附加的說明。UML在一個帶卷角的長方形中顯示給出的注釋，并使用虛線將這個帶卷角的長方形和所它所注釋的實體連接起來。第4章工廠模式4.1工廠模式問題在面向對象編程中,最通常的方法是一個new操作符產生一個對象實例,new操作符就是用來構造對象實例的。一些情況下,new操作符直接生成對象會帶來一些問題。創(chuàng)建對象之前必須清楚所要創(chuàng)建對象的類信息，但個別情況下無法達到此要求。許多類型對象的創(chuàng)造需要一系列步驟。在這些情況,新對象的建立就是一個“過程”，而不僅僅是一個操作。2023/2/1軟件工程專業(yè)274.1工廠模式問題2023/2/1軟件工程專業(yè)28模式的問題：你如何能輕松方便地構造對象實例，而不必關心構造對象實例的細節(jié)和復雜過程呢？4.2工廠模式的解決方案舉個例子假如還沒有工業(yè)革命，如果一個客戶要一款寶馬車,一般的做法是客戶去生產一款寶馬車，然后拿來用。后來出現工業(yè)革命。用戶不用去創(chuàng)建寶馬車。因為客戶有一個工廠來幫他創(chuàng)建寶馬.想要什么車，這個工廠就可以建。

2023/2/1軟件工程專業(yè)294.2工廠模式的解決方案舉個例子（續(xù)）為了滿足客戶，寶馬車系列越來越多，如320i，523i,30li等系列一個工廠無法創(chuàng)建所有的寶馬系列。于是由單獨分出來多個具體的工廠。每個具體工廠創(chuàng)建一種系列。隨著客戶的要求越來越高，寶馬車必須配置空調。而且這空調必須對應給系列車才能使用。于是這個工廠開始生產寶馬車和需要的空調。最終是客戶只要對寶馬的銷售員說：我要523i空調車，銷售員就直接給他523i空調車了。而不用自己去創(chuàng)建523i空調車寶馬車.

2023/2/1軟件工程專業(yè)304.2工廠模式的解決方案結論產品應該由工廠生產，而不是由客戶去生產?？蛻糁恍枰喇a品在哪買，而不需要知道產品如何制作。類的對象也是一種產品，所以需要對象工廠去負責創(chuàng)建。解決方案：建立一個工廠來創(chuàng)建對象。2023/2/1軟件工程專業(yè)314.3工廠模式的分類在GOF的《設計模式》一書中，工廠模式就是說明通過工廠類來創(chuàng)建對象的模式。工廠模式分為三類：簡單工廠模式工廠方法模式抽象工廠模式這三種模式從上到下逐步抽象，并且更具一般性。GOF在《設計模式》一書中將工廠模式分為兩類：工廠方法模式（FactoryMethod）與抽象工廠模式（AbstractFactory）。將簡單工廠模式（SimpleFactory）看為工廠方法模式的一種特例，兩者歸為一類。

2023/2/1軟件工程專業(yè)324.3工廠模式的分類簡單工廠模式由一個工廠對象決定創(chuàng)建出哪一種產品類的實例工廠模式家族中最簡單實用的模式，可以理解為是不同工廠模式的一個特殊實現。是由一個工廠類根據傳入的參數，動態(tài)決定應該創(chuàng)建哪一個產品類（這些產品類繼承自一個父類或接口）的實例。2023/2/1軟件工程專業(yè)334.3工廠模式的分類簡單工廠模式（續(xù)）該模式中包含的角色及其職責工廠（Creator）角色抽象產品（Product）角色具體產品（ConcreteProduct）角色2023/2/1軟件工程專業(yè)344.3工廠模式的分類簡單工廠模式（續(xù)）UML類圖2023/2/1軟件工程專業(yè)354.3工廠模式的分類工廠方法模式定義一個創(chuàng)建產品對象的工廠接口，將實際創(chuàng)建工作推遲到子類當中。核心工廠類不再負責產品的創(chuàng)建，這樣核心類成為一個抽象工廠角色，僅負責具體工廠子類必須實現的接口。工廠方法模式是簡單工廠模式的衍生，解決了許多簡單工廠模式的問題。首先完全實現‘開－閉原則’，實現了可擴展。2023/2/1軟件工程專業(yè)364.3工廠模式的分類工廠方法模式（續(xù)）該模式中包含的角色及其職責抽象工廠(Creator)角色具體工廠(ConcreteCreator)角色抽象產品(Product)角色具體產品(ConcreteProduct)角色2023/2/1軟件工程專業(yè)374.3工廠模式的分類工廠方法模式（續(xù)）UML類圖2023/2/1軟件工程專業(yè)384.3工廠模式的分類抽象工廠模式所有形態(tài)的工廠模式中最為抽象和最具一般性的一種形態(tài)。抽象工廠模式是指當有多個抽象角色時，使用的一種工廠模式。抽象工廠模式可以向客戶端提供一個接口，使客戶端在不必指定產品的具體的情況下，創(chuàng)建多個產品族中的產品對象。為創(chuàng)建一組相關或相互依賴的對象提供一個接口，而且無需指定他們的具體類。2023/2/1軟件工程專業(yè)394.3工廠模式的分類抽象工廠模式（續(xù)）抽象工廠模式的用意為：給客戶端提供一個接口，可以創(chuàng)建多個產品族中的產品對象，而且使用抽象工廠模式還要滿足一下條件：系統中有多個產品族，而系統一次只可能消費其中一族產品。同屬于同一個產品族的產品以其使用。2023/2/1軟件工程專業(yè)404.3工廠模式的分類抽象工廠模式（續(xù)）該模式中包含的角色及其職責抽象工廠(Creator)角色具體工廠(ConcreteCreator)角色抽象產品(Product)角色具體產品(ConcreteProduct)角色2023/2/1軟件工程專業(yè)414.3工廠模式的分類抽象工廠模式（續(xù)）UML類圖2023/2/1軟件工程專業(yè)42第5章單例模式5.1單例模式問題幾乎所有面向對象的程序中，總有一些類的對象需要是唯一的。例如，通過數據庫句柄到數據庫的連接是獨占的。2023/2/1軟件工程專業(yè)44模式問題：怎樣確保一個特殊類的實例是獨一無二的（它是這個類的唯一實例），并且這個實例易于被訪問呢？5.2單例模式的解決方案舉個例子有一個成語叫“獨一無二”，以表示事物的珍貴在中國古代，就有“國無二主”的說法，也就是說一個國家只有一個皇帝。2023/2/1軟件工程專業(yè)455.2單例模式的解決方案一個全局變量使得一個對象可以被訪問，但它不能防止你實例化多個對象。因為你的任何代碼都能修改全局變量，這將不可避免的引起更多調試的意外。換句話說，全局變量的狀態(tài)總是會出現一些問題的。讓類自身負責保存它的唯一實例(靜態(tài)變量)。這個類可以保證沒有其他實例可以被創(chuàng)建（通過截取創(chuàng)建新對象的請求），并且它可以提供一個訪問該實例的方法（靜態(tài)方法）。2023/2/1軟件工程專業(yè)465.2單例模式的解決方案

單例模式定義：“一個類有且僅有一個實例，并且自行實例化向整個系統提供。”2023/2/1軟件工程專業(yè)475.3單例模式結構模式的結構中只包括一個角色單件類（Singleton）單例模式有兩種形式餓漢單例,也就是,類被加載的時候就已經創(chuàng)建好了單例。懶漢單例,也就是第一次調用的時候被創(chuàng)建。2023/2/1軟件工程專業(yè)485.3單例模式結構UML類圖2023/2/1軟件工程專業(yè)49第6章原型模式6.1原型模式問題在軟件系統中，客戶希望創(chuàng)建一個類對象（產品）時，可能有三種情況：知道產品具體型號(使用new運算符創(chuàng)建)不知道型號，知道特定的需求(使用工廠模式)不知道需求，但想要一個。和已知對象相同的對象。2023/2/1軟件工程專業(yè)516.1原型模式問題模式問題：當對象的構造函數非常復雜，在生成新對象的時候非常耗時間、耗資源的情況？我們是怎么來創(chuàng)建呢？2023/2/1軟件工程專業(yè)526.1原型模式解決方案舉個例子：例子1：孫悟空拔下一嘬猴毛，輕輕一吹就會變出好多的孫悟空來。例子2：寄個快遞下面是一個郵寄快遞的場景：“給我寄個快遞?！鳖櫩驼f?！凹耐裁吹胤?？寄給……？”你問。“和上次差不多一樣，只是郵寄給另外一個地址，這里是郵寄地址……”顧客一邊說一邊把寫有郵寄地址的紙條給你?！昂?！”你愉快地答應，因為你保存了用戶的以前郵寄信息，只要復制這些數據，然后通過簡單的修改就可以快速地創(chuàng)建新的快遞數據了。

2023/2/1軟件工程專業(yè)536.2原型模式解決方案通過復制（克隆、拷貝）一個指定類型的對象來創(chuàng)建更多同類型的對象。這個指定的對象可被稱為“原型”對象，也就是通過復制原型對象來得到更多同類型的對象。用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這些原型創(chuàng)建新的對象的模式稱為原型模式。原型模式是從一個對象出發(fā)得到一個和自己有相同狀態(tài)的新對象的成熟模式，該模式的關鍵是將一個對象定義為原型，并為其提供復制自己的方法。2023/2/1軟件工程專業(yè)546.2原型模式解決方案2023/2/1軟件工程專業(yè)556.2原型模式解決方案淺拷貝指被拷貝對象的所有變量都含有與原對象相同的值，而且對其他對象的引用仍然是指向原來的對象。即淺拷貝只負責當前對象實例，對引用的對象不做拷貝。2023/2/1軟件工程專業(yè)566.2原型模式解決方案深拷貝指被拷貝對象的所有的變量都含有與原來對象相同的值，除了那些引用其他對象的變量。那些引用其他對象的變量將指向一個被拷貝的新對象，而不再是原有那些被引用對象。即深拷貝把要拷貝的對象所引用的對象也都拷貝了一次，而這種對被引用到的對象拷貝叫做間接拷貝。2023/2/1軟件工程專業(yè)576.3原型模式的結構模式的結構中包括兩種角色：抽象原型（Prototype）具體原型（ConcretePrototype）2023/2/1軟件工程專業(yè)586.3原型模式的結構UML類圖2023/2/1軟件工程專業(yè)59第7章外觀模式7.1外觀模式問題我們通過外觀的包裝，使應用程序只能看到外觀對象，而不會看到具體的細節(jié)對象，這樣無疑會降低應用程序的復雜度，并且提高了程序的可維護性。2023/2/1軟件工程專業(yè)61模式問題：為了降低復雜性，常常將系統劃分為若干個子系統。但是如何做到各個系統之間的通信和相互依賴關系達到最小呢？7.2模式的解決方案舉個例子一個電源總開關可以控制四盞燈、一個風扇、一臺空調和一臺電視機的啟動和關閉。該電源總開關可以同時控制上述所有電器設備。2023/2/1軟件工程專業(yè)627.2模式的解決方案2023/2/1軟件工程專業(yè)637.2模式的解決方案2023/2/1軟件工程專業(yè)647.2模式的解決方案外觀模式為系統中的一組接口提供一個一致的界面，Fa?ade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。外觀模式的關鍵是為子系統提供一個稱作外觀的類，該外觀類的實例負責和子系統中類的實例打交道當用戶想要和子系統中的若干個類的實例打交道時，可以代替地和子系統的外觀類的實例打交道。2023/2/1軟件工程專業(yè)657.3外觀模式的結構模式的結構中包括兩種角色子系統（Subsystem）外觀（Facade）2023/2/1軟件工程專業(yè)667.3外觀模式的結構UML類圖2023/2/1軟件工程專業(yè)67第8章裝飾模式8.1裝飾模式的問題若你從事過面向對象開發(fā)，實現給一個類或對象增加行為，使用繼承機制，這是所有面向對象語言的一個基本特性。如果已經存在的一個類缺少某些方法，或者須要給方法添加更多的功能（魅力），你也許會僅僅繼承這個類來產生一個新類—這建立在額外的代碼上。通過繼承一個現有類可以使得子類在擁有自身方法的同時還擁有父類的方法。但是這種方法是靜態(tài)的，用戶不能控制增加行為的方式和時機。2023/2/1軟件工程專業(yè)698.1裝飾模式的問題模式問題：你如何組織你的代碼使其可以容易的添加基本的或者一些很少用到的特性，而不是直接將額外的代碼寫在你的類的內部？2023/2/1軟件工程專業(yè)708.2裝飾模式的解決方案舉個例子一個鳥只能飛100米，如果讓它飛行150米，就必須給它裝一個電子翅膀，就可以實現飛行更遠的距離。2023/2/1軟件工程專業(yè)718.2裝飾模式的解決方案裝飾模式是在不必改變原類文件和使用繼承的情況下，動態(tài)地擴展一個對象的功能。它是通過創(chuàng)建一個包裝對象，也就是裝飾來包裹真實的對象。裝飾模式動態(tài)地給一個對象添加一些額外的職責或者行為。就增加功能來說，裝飾模式相比生成子類更為靈活。裝飾器模式提供了改變子類的靈活方案。裝飾器模式在不必改變原類文件和使用繼承的情況下，動態(tài)的擴展一個對象的功能。它是通過創(chuàng)建一個包裝對象，也就是裝飾來包裹真實的對象。2023/2/1軟件工程專業(yè)728.3裝飾模式的結構裝飾模式的結構中包括四種角色：抽象組件（Component）具體組件（ConcreteComponent）裝飾（Decorator）具體裝飾（ConcreteDecotator）2023/2/1軟件工程專業(yè)738.3裝飾模式的結構UML類圖2023/2/1軟件工程專業(yè)74第9章橋接模式9.1橋接模式的問題在軟件系統中，某些類型由于自身的邏輯，它具有兩個或多個維度的變化，那么如何應對這種“多維度的變化”？如何利用面向對象的技術來使得該類型能夠輕松的沿著多個方向進行變化，而又不引入額外的復雜度？2023/2/1軟件工程專業(yè)769.2橋接模式的解決方案舉個例子例子1：設想如果要繪制矩形、圓形、橢圓、正方形，我們至少需要4個形狀類，但是如果繪制的圖形需要具有不同的顏色，如紅色、綠色、藍色等，此時至少有如下兩種設計方案：?第一種設計方案是為每一種形狀都提供一套各種顏色的版本。?第二種設計方案是根據實際需要對形狀和顏色進行組合。2023/2/1軟件工程專業(yè)779.2橋接模式的解決方案橋接模式將抽象部分與它的實現部分分離，使得它們都可以獨立地變化。將抽象化與實現化脫耦，使得二者可以獨立地變化抽象化就是忽略一些信息，把不同的實體當作同樣的實體對待。在面向對象中，將對象的共同性質抽取出來形成類的過程即為抽象化的過程。針對抽象化給出的具體實現，就是實現化，抽象化與實現化是一對互逆的概念，實現化產生的對象比抽象化更具體，是對抽象化事物的進一步具體化的產物2023/2/1軟件工程專業(yè)789.2橋接模式的解決方案將抽象化與實現化脫耦，使得二者可以獨立地變化脫耦就是將抽象化和實現化之間的耦合解脫開，或者說是將它們之間的強關聯改換成弱關聯，將兩個角色之間的繼承關系改為關聯關系。橋接模式中的所謂脫耦，就是指在一個軟件系統的抽象化和實現化之間使用關聯關系（組合或者聚合關系）而不是繼承關系，從而使兩者可以相對獨立地變化，這就是橋接模式的用意。2023/2/1軟件工程專業(yè)799.3橋接模式的結構模式的結構中包括四種角色抽象（Abstraction）實現者（Implementor）細化抽象（RefinedAbstraction）具體實現者（ConcreteImplementor）2023/2/1軟件工程專業(yè)809.3橋接模式的結構UML類圖2023/2/1軟件工程專業(yè)81第10章命令模式10.1命令模式的問題在軟件設計中，我們經常需要向某些對象發(fā)送請求，但是并不知道請求的接收者是誰，也不知道被請求的操作是哪個。我們只需在程序運行時指定具體的請求接收者即可在軟件系統中，“行為請求者”與“行為實現者”通常呈現一種“緊耦合”。在這種情況下，如何將“行為請求者”與“行為實現者”解耦？2023/2/1軟件工程專業(yè)8310.2命令模式的解決方案舉個例子電視機遙控器:遙控器是請求的發(fā)送者，電視機是請求的接收者，遙控器上有一些按鈕如開，關,換頻道等按鈕就是具體命令，不同的按鈕對應電視機的不同操作。2023/2/1軟件工程專業(yè)8410.2命令模式的解決方案命令模式(CommandPattern)：將將一個請求封裝為一個對象，從而使我們可用不同的請求對客戶進行參數化；對請求排隊或者記錄請求日志，以及支持可撤銷的操作。2023/2/1軟件工程專業(yè)8510.3命令模式的結構模式的結構中包括四種角色：接收者（Receiver）命令(Command)接口具體命令（ConcreteCommand）請求者（Invoker）2023/2/1軟件工程專業(yè)8610.3命令模式的結構UML類圖2023/2/1軟件工程專業(yè)87第11章觀察者模式11.1觀察者模式的問題一些面向對象的編程方式，提供了一種構建對象間復雜網絡互連的能力。當對象們連接在一起時，它們就可以相互提供服務和信息。通常來說，當某個對象的狀態(tài)發(fā)生改變時，你仍然需要對象之間能互相通信。當一個對象的狀態(tài)發(fā)生改變時，你如何通知其他對象？是否需要一個動態(tài)方案――一個就像允許腳本的執(zhí)行一樣，允許自由連接的方案？2023/2/1軟件工程專業(yè)8911.2觀察者模式的解決方案舉個例子用戶界面可以作為一個觀察者，業(yè)務數據是被觀察者，用戶界面觀察業(yè)務數據的變化，發(fā)現數據變化后，就顯示在界面上。2023/2/1軟件工程專業(yè)9011.2觀察者模式的解決方案定義對象間的一種一對多的依賴關系,當一個對象的狀態(tài)發(fā)生改變時,所有依賴于它的對象都得到通知并被自動更新。觀察者模式允許一個對象關注其他對象的狀態(tài)，并且，觀察者模式還為被觀測者提供了一種觀測結構，或者說是一個主體和一個客體。主體，也就是被觀測者，可以用來聯系所有的觀測它的觀測者?？腕w，也就是觀測者，用來接受主體狀態(tài)的改變觀測就是一個