面試整理-JAVA部分-JAVA模式
1、Java部分
1.1 java基礎
1.2 JVM學習筆記
1.3 JAVA模式
1、簡單工廠模式
模式定義：
簡單工廠模式(Simple Factory Pattern)：又稱為靜態工廠方法(Static Factory Method)模式，它屬於類建立型模式。在簡單工廠模式中，可以根據引數的不同返回不同類的例項。簡單工廠模式專門定義一個類來負責建立其他類的例項，被建立的例項通常都具有共同的父類。(一個工廠生產一類產品)。
模式結構：
模式分析：
將物件的建立和物件本身業務處理分離可以降低系統的耦合度，使得兩者修改起來都相對容易。
在呼叫工廠類的工廠方法時，由於工廠方法是靜態方法，使用起來很方便，可通過類名直接呼叫，而且只需要傳入一個簡單的引數即可，在實際開發中，還可以在呼叫時將所傳入的引數儲存在XML等格式的配置檔案中，修改引數時無須修改任何原始碼。
簡單工廠模式最大的問題在於工廠類的職責相對過重，增加新的產品需要修改工廠類的判斷邏輯，這一點與開閉原則是相違背的。
簡單工廠模式的要點在於：當你需要什麼，只需要傳入一個正確的引數，就可以獲取你所需要的物件，而無須知道其建立細節。
模式優缺點：
優點：
工廠類含有必要的判斷邏輯，可以決定在什麼時候建立哪一個產品類的例項，客戶端可以免除直接建立產品物件的責任，而僅僅“消費”產品；簡單工廠模式通過這種做法實現了對責任的分割，它提供了專門的工廠類用於建立物件。
客戶端無須知道所建立的具體產品類的類名，只需要知道具體產品類所對應的引數即可，對於一些複雜的類名，通過簡單工廠模式可以減少使用者的記憶量。
通過引入配置檔案，可以在不修改任何客戶端程式碼的情況下更換和增加新的具體產品類，在一定程度上提高了系統的靈活性。
缺點：
由於工廠類集中了所有產品建立邏輯，一旦不能正常工作，整個系統都要受到影響。
使用簡單工廠模式將會增加系統中類的個數，在一定程式上增加了系統的複雜度和理解難度。
系統擴充套件困難，一旦新增新產品就不得不修改工廠邏輯，在產品型別較多時，有可能造成工廠邏輯過於複雜，不利於系統的擴充套件和維護。
簡單工廠模式由於使用了靜態工廠方法，造成工廠角色無法形成基於繼承的等級結構。
模式適用環境：
工廠類負責建立的物件比較少：由於建立的物件較少，不會造成工廠方法中的業務邏輯太過複雜。
客戶端只知道傳入工廠類的引數，對於如何建立物件不關心：客戶端既不需要關心建立細節，甚至連類名都不需要記住，只需要知道型別所對應的引數。
樣例：
2、工廠方法模式
定義：
工廠方法模式又稱為工廠模式，也叫虛擬構造器（VirtualConstructor）模式或者多型工廠模式（Polymorphic Factory），在工廠方法模式中，父類負責定義建立物件的公共介面，而子類則負責生成具體的物件，這樣做的目的是將類的例項化操作延遲到子類中完成，即由子類來決定究竟應該例項化（建立）哪一個類。（一個工廠生產一類產品）。
參與者：
抽象產品角色（Product）：定義產品的介面
具體產品角色（ConcreteProduct） ：實現介面Product的具體產品類
抽象工廠角色（Creator） ：宣告工廠方法（FactoryMethod），返回一個產品
真實的工廠（ConcreteCreator）：實現FactoryMethod工廠方法，由客戶呼叫，返回一個產品的例項
工廠模式優缺點：
優點：
在工廠方法模式中，工廠方法用來建立客戶所需要的產品，同時還向客戶隱藏了哪種具體產品類將被例項化這一細節，使用者只需要關心所需產品對應的工廠，無須關心建立細節，甚至無須知道具體產品類的類名。
基於工廠角色和產品角色的多型性設計是工廠方法模式的關鍵。它能夠使工廠可以自主確定建立何種產品物件，而如何建立這個物件的細節則完全封裝在具體工廠內部。工廠方法模式之所以又被稱為多型工廠模式，是因為所有的具體工廠類都具有同一抽象父類。
使用工廠方法模式的另一個優點是在系統中加入新產品時，無須修改抽象工廠和抽象產品提供的介面，無須修改客戶端，也無須修改其他的具體工廠和具體產品，而只要新增一個具體工廠和具體產品就可以了。這樣，系統的可擴充套件性也就變得非常好，完全符合“開閉原則”。
缺點：
在新增新產品時，需要編寫新的具體產品類，而且還要提供與之對應的具體工廠類，系統中類的個數將成對增加，在一定程度上增加了系統的複雜度，有更多的類需要編譯和執行，會給系統帶來一些額外的開銷。
由於考慮到系統的可擴充套件性，需要引入抽象層，在客戶端程式碼中均使用抽象層進行定義，增加了系統的抽象性和理解難度，且在實現時可能需要用到DOM、反射等技術，增加了系統的實現難度。
模式適用環境：
一個類不知道它所需要的物件的類：在工廠方法模式中，客戶端不需要知道具體產品類的類名，只需要知道所對應的工廠即可，具體的產品物件由具體工廠類建立；客戶端需要知道建立具體產品的工廠類。
一個類通過其子類來指定建立哪個物件：在工廠方法模式中，對於抽象工廠類只需要提供一個建立產品的介面，而由其子類來確定具體要建立的物件，利用面向物件的多型性和里氏代換原則，在程式執行時，子類物件將覆蓋父類物件，從而使得系統更容易擴充套件。
將建立物件的任務委託給多個工廠子類中的某一個，客戶端在使用時可以無須關心是哪一個工廠子類建立產品子類，需要時再動態指定，可將具體工廠類的類名儲存在配置檔案或資料庫中。
樣例：
3、抽象工廠模式
動機：
在工廠方法模式中具體工廠負責生產具體的產品，每一個具體工廠對應一種具體產品，工廠方法也具有唯一性，一般情況下，一個具體工廠中只有一個工廠方法或者一組過載的工廠方法。但是有時候我們需要一個工廠可以提供多個產品物件，而不是單一的產品物件。（一個工廠可以生產它旗下不同產品（多個產品等級結構））。
引入兩個概念：
產品等級結構：
產品等級結構即產品的繼承結構，如一個抽象類是電視機，其子類有海爾電視機、海信電視機、TCL電視機，則抽象電視機與具體品牌的電視機之間構成了一個產品等級結構，抽象電視機是父類，而具體品牌的電視機是其子類。
產品族：
在抽象工廠模式中，產品族是指由同一個工廠生產的，位於不同產品等級結構中的一組產品，如海爾電器工廠生產的海爾電視機、海爾電冰箱，海爾電視機位於電視機產品等級結構中，海爾電冰箱位於電冰箱產品等級結構中。
產品族和產品等級結構示意圖：
抽象工廠模式與工廠方法模式最大的區別在於，工廠方法模式針對的是一個產品等級結構，而抽象工廠模式則需要面對多個產品等級結構，一個工廠等級結構可以負責多個不同產品等級結構中的產品物件的建立 。當一個工廠等級結構可以創建出分屬於不同產品等級結構的一個產品族中的所有物件時，抽象工廠模式比工廠方法模式更為簡單、有效率。
定義：
抽象工廠模式(Abstract Factory Pattern)：提供一個建立一系列相關或相互依賴物件的介面，而無須指定它們具體的類。抽象工廠模式又稱為Kit模式，屬於物件建立型模式。
模式結構：
抽象工廠（Abstract Factory)：宣告生成一系列抽象產品的方法
具體工廠（Concrete Factory）：執行生成一系列抽象產品的方法，生成一系列具體的產品
抽象產品（Abstract Product）：為這一系列的某一種產品宣告介面
具體產品（Product）：定義具體工廠生成的具體產品的物件，實現產品介面
客戶（Client）：我們的應用程式客戶端（不要理解成人），使用抽象產品和抽象工廠生成物件。
抽象工廠模式的優缺點：
優點：
抽象工廠模式隔離了具體類的生成，使得客戶並不需要知道什麼被建立。由於這種隔離，更換一個具體工廠就變得相對容易。所有的具體工廠都實現了抽象工廠中定義的那些公共介面，因此只需改變具體工廠的例項，就可以在某種程度上改變整個軟體系統的行為。另外，應用抽象工廠模式可以實現高內聚低耦合的設計目的，因此抽象工廠模式得到了廣泛的應用。
當一個產品族中的多個物件被設計成一起工作時，它能夠保證客戶端始終只使用同一個產品族中的物件。這對一些需要根據當前環境來決定其行為的軟體系統來說，是一種非常實用的設計模式。
增加新的具體工廠和產品族很方便，無須修改已有系統，符合“開閉原則”。
缺點：
在新增新的產品物件時，難以擴充套件抽象工廠來生產新種類的產品，這是因為在抽象工廠角色中規定了所有可能被建立的產品集合，要支援新種類的產品就意味著要對該介面進行擴充套件，而這將涉及到對抽象工廠角色及其所有子類的修改，顯然會帶來較大的不便。
開閉原則的傾斜性（增加新的工廠和產品族容易，增加新的產品等級結構麻煩）
模式適用環境：
一個系統不應當依賴於產品類例項如何被建立、組合和表達的細節，這對於所有型別的工廠模式都是重要的。
系統中有多於一個的產品族，而每次只使用其中某一產品族。
屬於同一個產品族的產品將在一起使用，這一約束必須在系統的設計中體現出來。
系統提供一個產品類的庫，所有的產品以同樣的接口出現，從而使客戶端不依賴於具體實現。
樣例：
介紹：
微軟滑鼠 微軟鍵盤
蘋果滑鼠 蘋果鍵盤
兩個產品等級結構（鍵盤和滑鼠），兩個產品族（微軟和蘋果），怎麼設計呢？
首先兩個產品等級結構，所以有有個抽象產品類（鍵盤和滑鼠），根據不同的實現可得到四個具體類（微軟滑鼠，微軟鍵盤，蘋果滑鼠，蘋果鍵盤），同時建立一個工廠類來生產滑鼠和鍵盤，因為有兩個產品族，所以有兩個具體工廠（蘋果和微軟），分別來實現他們旗下的產品。
4、建造者模式
模式定義：
建造者模式(Builder Pattern)：將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。（使得相同的建立過程可以建立不同的產品）
建造者模式是一步一步建立一個複雜的物件，它允許使用者只通過指定複雜物件的型別和內容就可以構建它們，使用者不需要知道內部的具體構建細節。建造者模式屬於物件建立型模式。根據中文翻譯的不同，建造者模式又可以稱為生成器模式。
模式結構：
Builder：抽象建造者
ConcreteBuilder：具體建造者
Director：指揮者
Product：產品角色
建造者（Builder）角色：給出一個抽象介面，以規範產品物件的各個組成成分的建造。一般而言，此介面獨立於應用程式的商業邏輯。模式中直接建立產品物件的是具體建造者（ConcreteBuilder）角色。具體建造者類必須實現這個介面所要求的方法：一個是建造方法，另一個是結果返還方法。
具體建造者（Concrete Builder）角色：擔任這個角色的是於應用程式緊密相關的類，它們在應用程式呼叫下建立產品例項。這個角色主要完成的任務包括：
• 實現Builder角色提供的介面，一步一步完成建立產品例項的過程。
• 在建造過程完成後，提供產品的例項。
指導者（Director）角色：擔任這個角色的類呼叫具體建造者角色以建立產品物件。導演者並沒有產品類的具體知識，真正擁有產品類的具體知識的是具體建造者物件。
產品（Product）角色：產品便是建造中的複雜物件。
指導者角色是於客戶端打交道的角色。導演者角色將客戶端建立產品的請求劃分為對各個零件的建造請求，再將這些請求委派給具體建造者角色。具體建造者角色是做具體建造工作的，但卻不為客戶端所知。
建造者模式的優缺點：
優點：
在建造者模式中，客戶端不必知道產品內部組成的細節，將產品本身與產品的建立過程解耦，使得相同的建立過程可以建立不同的產品物件。
每一個具體建造者都相對獨立，而與其他的具體建造者無關，因此可以很方便地替換具體建造者或增加新的具體建造者，使用者使用不同的具體建造者即可得到不同的產品物件。
可以更加精細地控制產品的建立過程。將複雜產品的建立步驟分解在不同的方法中，使得建立過程更加清晰，也更方便使用程式來控制建立過程。
增加新的具體建造者無須修改原有類庫的程式碼，指揮者類針對抽象建造者類程式設計，系統擴充套件方便，符合“開閉原則”。
缺點：
建造者模式所建立的產品一般具有較多的共同點，其組成部分相似，如果產品之間的差異性很大，則不適合使用建造者模式，因此其使用範圍受到一定的限制。
如果產品的內部變化複雜，可能會導致需要定義很多具體建造者類來實現這種變化，導致系統變得很龐大。
場景：
需要生成的產品物件有複雜的內部結構，這些產品物件具備共性；
隔離複雜物件的建立和使用，並使得相同的建立過程可以建立不同的產品。
樣例：
5、單例模式
定義：
單例模式(Singleton Pattern)：單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項，這個類稱為單例類，它提供全域性訪問的方法。
單例模式的要點有三個：一是某個類只能有一個例項；二是它必須自行建立這個例項；三是它必須自行向整個系統提供這個例項。
模式分析：
單例模式的目的是保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。單例模式包含的角色只有一個，就是單例類——Singleton。單例類擁有一個私有建構函式，確保使用者無法通過new關鍵字直接例項化它。除此之外，該模式中包含一個靜態私有成員變數與靜態公有的工廠方法，該工廠方法負責檢驗例項的存在性並例項化自己，然後儲存在靜態成員變數中，以確保只有一個例項被建立。
在單例模式的實現過程中，需要注意如下三點：
單例類的建構函式為私有；
提供一個自身的靜態私有成員變數；
提供一個公有的靜態工廠方法。
單例模式的優缺點：
優點：
提供了對唯一例項的受控訪問。因為單例類封裝了它的唯一例項，所以它可以嚴格控制客戶怎樣以及何時訪問它，併為設計及開發團隊提供了共享的概念。
由於在系統記憶體中只存在一個物件，因此可以節約系統資源，對於一些需要頻繁建立和銷燬的物件，單例模式無疑可以提高系統的效能。
允許可變數目的例項。我們可以基於單例模式進行擴充套件，使用與單例控制相似的方法來獲得指定個數的物件例項。
缺點：
由於單例模式中沒有抽象層，因此單例類的擴充套件有很大的困難。
單例類的職責過重，在一定程度上違背了“單一職責原則”。因為單例類既充當了工廠角色，提供了工廠方法，同時又充當了產品角色，包含一些業務方法，將產品的建立和產品的本身的功能融合到一起。
濫用單例將帶來一些負面問題，如為了節省資源將資料庫連線池物件設計為單例類，可能會導致共享連線池物件的程式過多而出現連線池溢位；現在很多面向物件語言(如Java、C#)的執行環境都提供了自動垃圾回收的技術，因此，如果例項化的物件長時間不被利用，系統會認為它是垃圾，會自動銷燬並回收資源，下次利用時又將重新例項化，這將導致物件狀態的丟失。
模式的適用環境：
系統只需要一個例項物件，如系統要求提供一個唯一的序列號生成器，或者需要考慮資源消耗太大而只允許建立一個物件。
客戶呼叫類的單個例項只允許使用一個公共訪問點，除了該公共訪問點，不能通過其他途徑訪問該例項。
在一個系統中要求一個類只有一個例項時才應當使用單例模式。反過來，如果一個類可以有幾個例項共存，就需要對單例模式進行改進，使之成為多例模式。
樣例：
懶漢式模式：
解決執行緒安全：
餓漢式模式：
登記式模式（可忽略）
6、介面卡模式
模式定義：
將類的介面轉換成客戶希望的另一個介面。
1、類介面卡
原理：通過繼承來實現介面卡功能。
當我們要訪問的介面A中沒有我們想要的方法 ，卻在另一個介面B中發現了合適的方法，我們又不能改變訪問介面A，在這種情況下，我們可以定義一個介面卡p來進行中轉，這個介面卡p要實現我們訪問的介面A，這樣我們就能繼續訪問當前介面A中的方法（雖然它目前不是我們的菜），然後再繼承介面B的實現類BB，這樣我們可以在介面卡P中訪問介面B的方法了，這時我們在介面卡P中的介面A方法中直接引用BB中的合適方法，這樣就完成了一個簡單的類介面卡。
2、物件介面卡
原理：通過組合來實現介面卡功能。
當我們要訪問的介面A中沒有我們想要的方法 ，卻在另一個介面B中發現了合適的方法，我們又不能改變訪問介面A，在這種情況下，我們可以定義一個介面卡p來進行中轉，這個介面卡p要實現我們訪問的介面A，這樣我們就能繼續訪問當前介面A中的方法（雖然它目前不是我們的菜），然後在介面卡P中定義私有變數C（物件）（B介面指向變數名），再定義一個帶引數的構造器用來為物件C賦值，再在A介面的方法實現中使用物件C呼叫其來源於B介面的方法。
3、介面介面卡
原理：通過抽象類來實現適配。
當存在這樣一個介面，其中定義了N多的方法，而我們現在卻只想使用其中的一個到幾個方法，如果我們直接實現介面，那麼我們要對所有的方法進行實現，哪怕我們僅僅是對不需要的方法進行置空（只寫一對大括號，不做具體方法實現）也會導致這個類變得臃腫，呼叫也不方便，這時我們可以使用一個抽象類作為中介軟體，即介面卡，用這個抽象類實現介面，而在抽象類中所有的方法都進行置空，那麼我們在建立抽象類的繼承類，而且重寫我們需要使用的那幾個方法即可。
模式優缺點：
將目標類和適配者類解耦，通過引入一個介面卡類來重用現有的適配者類，而無須修改原有程式碼。
增加了類的透明性和複用性，將具體的實現封裝在適配者類中，對於客戶端類來說是透明的，而且提高了適配者的複用性。
靈活性和擴充套件性都非常好，通過使用配置檔案，可以很方便地更換介面卡，也可以在不修改原有程式碼的基礎上增加新的介面卡類，完全符合“開閉原則”。
類介面卡模式還具有如下優點：
由於介面卡類是適配者類的子類，因此可以在介面卡類中置換一些適配者的方法，使得介面卡的靈活性更強。
類介面卡模式的缺點如下：
對於Java、C#等不支援多重繼承的語言，一次最多隻能適配一個適配者類，而且目標抽象類只能為抽象類，不能為具體類，其使用有一定的侷限性，不能將一個適配者類和它的子類都適配到目標介面。
物件介面卡模式還具有如下優點：
一個物件介面卡可以把多個不同的適配者適配到同一個目標，也就是說，同一個介面卡可以把適配者類和它的子類都適配到目標介面。
物件介面卡模式的缺點如下：
與類介面卡模式相比，要想置換適配者類的方法就不容易。如果一定要置換掉適配者類的一個或多個方法，就只好先做一個適配者類的子類，將適配者類的方法置換掉，然後再把適配者類的子類當做真正的適配者進行適配，實現過程較為複雜。
模式適用環境：
系統需要使用現有的類，而這些類的介面不符合系統的需要。
想要建立一個可以重複使用的類，用於與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作。
7、代理模式
模式定義：
代理模式(Proxy Pattern) ：給某一個物件提供一個代理，並由代理物件控制對原物件的引用。代理模式的英文叫做Proxy或Surrogate，它是一種物件結構型模式。
模式結構：
Subject: 抽象主題角色
Proxy: 代理主題角色
RealSubject: 真實主題角色
模式分析：
代理類和實現類實現的是同一個介面，代理類將實現類的引用作為代理類的引數，實際代理類中的是對實現類的呼叫。
樣例：
模式優缺點：
優點：
代理模式能夠協調呼叫者和被呼叫者，在一定程度上降低了系統的耦合度。
遠端代理使得客戶端可以訪問在遠端機器上的物件，遠端機器可能具有更好的計算效能與處理速度，可以快速響應並處理客戶端請求。
虛擬代理通過使用一個小物件來代表一個大物件，可以減少系統資源的消耗，對系統進行優化並提高執行速度。
保護代理可以控制對真實物件的使用許可權。
代理模式的缺點：
由於在客戶端和真實主題之間增加了代理物件，因此有些型別的代理模式可能會造成請求的處理速度變慢。
實現代理模式需要額外的工作，有些代理模式的實現非常複雜。
適用環境：
遠端(Remote)代理：為一個位於不同的地址空間的物件提供一個本地的代理物件，這個不同的地址空間可以是在同一臺主機中，也可是在另一臺主機中，遠端代理又叫做大使(Ambassador)。
虛擬(Virtual)代理：如果需要建立一個資源消耗較大的物件，先建立一個消耗相對較小的物件來表示，真實物件只在需要時才會被真正建立。
Copy-on-Write代理：它是虛擬代理的一種，把複製（克隆）操作延遲到只有在客戶端真正需要時才執行。一般來說，物件的深克隆是一個開銷較大的操作，Copy-on-Write代理可以讓這個操作延遲，只有物件被用到的時候才被克隆。
保護(Protect or Access)代理：控制對一個物件的訪問，可以給不同的使用者提供不同級別的使用許可權。
緩衝(Cache)代理：為某一個目標操作的結果提供臨時的儲存空間，以便多個客戶端可以共享這些結果。
防火牆(Firewall)代理：保護目標不讓惡意使用者接近。
同步化(Synchronization)代理：使幾個使用者能夠同時使用一個物件而沒有衝突。
智慧引用(Smart Reference)代理：當一個物件被引用時，提供一些額外的操作，如將此物件被呼叫的次數記錄下來等。
8、責任鏈模式
模式定義：
職責鏈模式(Chain of Responsibility Pattern)：避免請求傳送者與接收者耦合在一起，讓多個物件都有可能接收請求，將這些物件連線成一條鏈，並且沿著這條鏈傳遞請求，直到有物件處理它為止。
模式結構：
Handler: 抽象處理者
ConcreteHandler: 具體處理者
Client: 客戶類
在職責鏈模式裡，很多物件由每一個物件對其下家的引用而連線起來形成一條鏈。
請求在這條鏈上傳遞，直到鏈上的某一個物件處理此請求為止。
發出這個請求的客戶端並不知道鏈上的哪一個物件最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重樣例：
模式優缺點：
優點：
降低耦合度 可簡化物件的相互連線 增強給物件指派職責的靈活性 增加新的請求處理類很方便
缺點：
不能保證請求一定被接收。 系統性能將受到一定影響，而且在進行程式碼除錯時不太方便；可能會造成迴圈呼叫。
適用環境：
有多個物件可以處理同一個請求，具體哪個物件處理該請求由執行時刻自動確定。 在不明確指定接收者的情況下，向多個物件中的一個提交一個請求。 動態指定一組物件處理請求。
9、觀察者模式
定義：
定義物件間的一種一對多依賴關係，使得每當一個物件狀態發生改變時，其相關依賴物件皆得到通知並被自動更新。
模式結構：
Subject: 目標 ConcreteSubject: 具體目標 Observer: 觀察者 ConcreteObserver: 具體觀察者
模式分析：
觀察者模式描述瞭如何建立物件與物件之間的依賴關係，如何構造滿足這種需求的系統。
這一模式中的關鍵物件是觀察目標和觀察者，一個目標可以有任意數目的與之相依賴的觀察者，一旦目標的狀態發生改變，所有的觀察者都將得到通知。
作為對這個通知的響應，每個觀察者都將即時更新自己的狀態，以與目標狀態同步，這種互動也稱為釋出-訂閱(publish-subscribe)。目標是通知的釋出者，它發出通知時並不需要知道誰是它的觀察者，可以有任意數目的觀察者訂閱它並接收通知。
樣例：
模式優缺點：
優點：
觀察者模式可以實現表示層和資料邏輯層的分離，並定義了穩定的訊息更新傳遞機制，抽象了更新介面，使得可以有各種各樣不同的表示層作為具體觀察者角色。 觀察者模式在觀察目標和觀察者之間建立一個抽象的耦合。 觀察者模式支援廣播通訊。 觀察者模式符合“開閉原則”的要求。
缺點：
如果一個觀察目標物件有很多直接和間接的觀察者的話，將所有的觀察者都通知到會花費很多時間。 如果在觀察者和觀察目標之間有迴圈依賴的話，觀察目標會觸發它們之間進行迴圈呼叫，可能導致系統崩潰。 觀察者模式沒有相應的機制讓觀察者知道所觀察的目標物件是怎麼發生變化的，而僅僅只是知道觀察目標發生了變化。
適用環境：
一個抽象模型有兩個方面，其中一個方面依賴於另一個方面。將這些方面封裝在獨立的物件中使它們可以各自獨立地改變和複用。 一個物件的改變將導致其他一個或多個物件也發生改變，而不知道具體有多少物件將發生改變，可以降低物件之間的耦合度。 一個物件必須通知其他物件，而並不知道這些物件是誰。 需要在系統中建立一個觸發鏈，A物件的行為將影響B物件，B物件的行為將影響C物件……，可以使用觀察者模式建立一種鏈式觸發機制。
