軟件體系結構
質量屬性：
開發期質量:可擴展性，可復用性，可維護性等；
運行期質量：正確性，健壯性，性能，可靠性，容錯性，易用性，安全性，可移植性，兼容性。
設計原則：
-
面向接口編程（Program to interfaces, not to implementations）
-
多用組合，少用繼承（Favor composition over inheritance）
-
Principle of Least Knowledge(Law of Demeter)
-
單一職責原則（Single Responsibility Principle）：就一個類而言，應該僅有一個引起它變化的原因。
-
開閉原則（Open-Closed Principle）：軟件實體對擴展是開放的，但對修改是關閉的，即在不修改一個軟件實體的基礎上去擴展其功能。抽象化是開閉原則的關鍵
-
里氏代換原則（Liskov Substitution Principle）：在軟件系統中，一個可以接受基類對象的地方必然可以接受一個子類對象。里氏代換原則是實現開閉原則的重要方法之一。
-
依賴倒置原則（Dependency Inversion Principle）：要針對抽象層編程，而不要針對具體類編程。實現開閉原則的關鍵是抽象化，並且從抽象導出具體化實現，如果說開閉原則是面向對象設計的目標的話，那么依賴倒置原則就是面向對象設計的主要手段。依賴注入：構造注入，設置注入，接口注入
-
接口隔離原則（Interface Segregation Principle）：使用多個專門的接口來取代一個統一的接口。
-
分離關注點（Principle of Separation of Concerns）:"Organize software into separate components(pieces) that are as independent as possible."
軟件風格：
Model-View-Controller(pattern)
MVC模式（Model-view-controller）是軟件工程中的一種軟件架構模式，把軟件系統分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）
MCV模式的目的是實現一種動態的程序設計，使后續對程序的修改和擴展簡化，並且使程序某一部分的重復利用成為可能。
控制器（Controller）：負責轉發請求，對請求進行處理。
試圖（View）：界面設計人員進行圖形界面設計。
模型（Model）：程序員編寫程序應有的功能（實現算法等等）、數據專家進行數據管理和數據庫設計（可以實現具體的功能）
將應用程序划分為三種組件，模型-試圖-控制器（MVC）設計定義它們之間的相互作用。
模型（Model）：用於封裝與應用程序的業務邏輯相關的數據以及數據的處理方法。"Model"有對數據直接訪問的權利，例如對數據庫的訪問。"Model"不依賴"View"和"Controller"，也就是說，Model不關心它會被如何顯示或是如何被操作。但是Model中數據的變化一般會通過一種刷新機制被公布。為了實現這種機制，那些勇於監視此Model的View必須事前在此Model上注冊，從而，View可以了解在數據Model上發生的改變。
視圖（View）能夠實現數據有目的的顯示（理論上，這不是必需的）。在View中一般沒有程序上的邏輯。為了實現View上的刷新功能，View需要訪問它監視的數據模型（Model），因此應該事前在被它監視的數據那里注冊。
控制器（Controller）起到了額不同層面間的組織作用，用於控制應用程序的流程。它處理事件並作出響應。"事件"包括用戶的行為和數據Model上的改變。
實例Java平台上實現的MVC模型
視圖（View）
在J2EE應用程序中，視圖（View）可能由Java Server Page（JSP）擔任。生成View的代碼則可能是一個servlet的一部分，特別是在客戶端服務端交換的時候。
控制器（Controller）
J2EE應用中，Controller可能是一個servlet。除了可直接以J2EE來撰寫外，亦可用其他框架來撰寫，常見的有Struts2,Spring Framework…等等。
模型（Model）
Model則是由一個實體Bean來實現。
C/S(Client-Server)
C/S軟件是基於資源不對等，且為實現共享而提出來的。C/S體系結構主要有三個主要組成部分：數據庫、服務器、客戶應用程序和網絡。優點：具有強大的數據操作和事務處理能力；對於軟件和硬件的變化顯示出強大的適應性和靈活性；將大的應用處理任務分到許多通過網絡連接的低成本計算機上。缺點：開發成本高；客戶端程序設計復雜；軟件維護和升級困難。
管道過濾器風格（Pipe-and-Filter）
每一個組件都有一組輸入和輸出，組件讀輸入的數據流，經過內部處理，然后產生輸出的數據流。過濾器風格的連接件就像是數據流傳輸的管道，將一個過濾器的輸出傳到另一個過濾器的輸入。
分層系統（Layered/Tiered Architecture）
組織成一個層次結構，每一層都為上一層提供了相應的服務，並且接受下一層的服務。在分層系統的一些層次中構件實現了虛擬機的功能。實例:分層的操作系統
端到端（Peer-to-Peer）
黑板系統/倉庫系統（Blackboard/Repository）
組件：中心數據結構（倉庫）和一些獨立構件的集合。
倉庫和在系統中很重要的外部組件之間的相互作用
實例：需要使用一些復雜表征的信號處理系統
基於事件的隱式調用（Event-Based Architecture(PubSub)）
組件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其他組件中的過程在一個或多個事件中祖冊，當一個事件被觸發，系統自動調動這個事件中注冊的所有過程。這種風格的組件是一個模塊，這些模塊可以是一些過程，又可以是一些事件的集合。不變量：事件的觸發者並不知道哪些組件會被這些事件影響（觀察者模式-Observer）
實例：數據庫管理系統，用戶界面。
SOA(Service-Oriented Architecture)
面向服務的體系結構是一個組件模型，它將應用的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。阿里的dubbox是國內現在應用最多的用來實現SOA的框架。它將服務注冊到企業服務總線上，當某個系統需要調用其他系統中數據的時候直接從企業服務總線上獲取，而不是端到端的獲取，從而減少了系統的復雜度。
RESTF(representational state transfer)表述性狀態轉移
Rest是web服務的一種架構風格；使用HTTP,URI,XML,JSON,HTML等廣泛流行的標准和協議；輕量級，跨平台，跨語言的架構設計。它是一種設計風格，不是一種標准，是一種思想。
Rest架構的主要原則：
-
網絡上的所有事情都被抽象為資源
-
每個資源都有一個唯一的資源標識符
-
同一個資源具有多種表現形式（xml，json等）
-
對資源的各種操作不會改變資源標識符
-
所有的操作都是無狀態的
-
符合REST原則的框架方式即可成為RESTful
什么是Restful：
對應的中文是rest式的；Restful web service是一種常見的rest的應用，是遵守了rest風格的web服務；rest式的web服務是一種ROA(The Resource-Oriented Architecture)(面向資源的架構)
為什么會出現Restful
在Restful之前的操作：
http://127.0.0.1/user/query/1 GET 根據用戶id查詢用戶數據
http://127.0.0.1/user/save POST 新增用戶
http://127.0.0.1/user/update POST 修改用戶信息
http://127.0.0.1/user/delete GET/POST 刪除用戶信息
RESTful用法：
http://127.0.0.1/user/1 GET 根據用戶id查詢用戶數據
http://127.0.0.1/user POST 新增用戶
http://127.0.0.1/user PUT 修改用戶信息
http://127.0.0.1/user DELETE 刪除用戶信息
之前的操作是沒有問題的，大神認為是有問題的，有什么問題呢?你每次請求的接口或者地址，都在做描述，例如查詢的時候用了query,新增的時候用了save，其實完全沒有這個必要，我使用了get請求，就是查詢，使用post請求，就是新增的請求，我的意圖很明顯，完全沒有必要做描述，這就是為什么有了restful
如何使用
總結：restful就是舊技術，新風格。
大泥球風格（big ball of mud）：大泥球風格就是沒有任何清楚的結構，雜亂無章、錯綜復雜，邋遢不堪、隨意拼貼的大堆代碼。
控制反轉與依賴注入
什么是控制？如下圖所示，我們看到了軟件系統中對象的高耦合現象。全體齒輪的轉動由一個對象來控制，如類B
什么是控制反轉？是用來對對象進行解耦。借助第三方實現具有依賴關系的對象之間的解耦。這個第三方就是ioc容器。引入了ioc容器后，對象A、B、C、D之間沒有了依賴關系，全體齒輪轉動的控制權交給容器。這時候齒輪轉動控制權不屬於任何對象，而屬於ioc容器，所以控制權反轉了，從某個對象轉到了ioc容器。
什么是依賴注入？
什么是依賴？依賴是指一種關系，如果在類A中創建了類B的實例，我們說類A依賴類B。下面有一個例子：
出現的問題（problems）：
問題1：如果現在要改變類B生成方式，如需要new B(string name)初始化 B，需要修改類A中的源代碼；
問題2：如果想測試不同B對象對A的影響很困難，因為B的初始化被寫死在了A的構造函數中；
問題3：如果要對類B的實例進行調試時，就必須在類A中對類B的實例進行測試，增加了測試的難度和復雜度；因為當出現問題時，不知道是類A的問題還是類B的問題。
解決方法：
依賴注入定義：將B對象實例作為類A的構造器參數進行傳入，在調用類A構造器之前，類B實例已經別初始化好了。像這種非自己主動初始化依賴，而通過外部傳入依賴對象的方式，我們就稱為依賴注入。
依賴反轉
根據依賴注入的定義：被依賴者對象並不是依賴自己主動初始化，而是通過外部傳入被依賴者的方式，那么背依賴者對象類型可以是其本身，也可以使其實現類或繼承子類；
所以，經過分析，被依賴者的對象類型，並不是依賴者自身可以決定的，（當然傳統的程序設計方式是依賴者決定的），而是由外部創建者決定的，所以被依賴者類型的決定權反轉了。對於spring來說，就是由spring容器決定的；
依賴反轉定義：被依賴者的對象類型並不是由依賴者自身可以決定的，而是由外部創建者決定的，外部傳入什么類型的對象就是什么類型的對象，依賴者對其一無所知；
框架與庫
有一個基本的特征是框架一般指的是會調用你的代碼，控制權從你寫的程序手中轉移到框架中，而庫一般是用來被你調用。
庫和框架都是一種有別於軟件、面向程序開發者的產品形式。正因為如此，也有很多人誤認為庫就是框架，或者認為指定語言的庫就是框架。
庫的英文單詞為Library(簡稱為Lib)，框架的英文為Framework。
庫是將代碼集合成一個產品，供程序員調用。面向對象的代碼組織形式而成的庫也叫類庫。面向過程的代碼組織形式而成的庫也叫函數庫。在函數庫中的可以直接使用的函數叫庫函數。開發者在使用庫的使用，只需要使用庫的一部分類或函數，然后繼續實現自己的功能。
框架則是為解決一個（一類）問題而開發的產品，框架用戶一般只需要使用框架提供的類或函數，即可實現全部功能。可以說，框架是庫的升級版。
開發者在使用框架的時候，必須使用這個框架的全部代碼。
框架和庫的比較可以想象為：
假如我們要買一台電腦。框架為我們提供了已經裝好的電腦，我們只要買回來就能用，但你必須把整個電腦買回來。這樣用戶自然輕松許多，但會導致很多人用一樣的電腦，或你想自定義某個部件將需要修改這個框架。而庫就如自己組裝的電腦。庫為我們提供了很多部件，我們需要自己組裝，如果某個部件未提供，我們也可以自己做。庫的使用非常靈活，但沒有框架方便。
體系結構中的模型
To help reason and communicate about the design of complex software as a whole.
（為了幫助理解與溝通復雜軟件作為一個整體的設計）
Canonical Model Structure（規范化模型結構）
Domain Model（領域模型）: The facts about the world（真實世界的事實）
Design Model（設計模型）: The design decisions made about the software.（軟件開發中的設計決策）
Code Model（代碼模型）: The source code implementation of a system.（實現系統的源代碼）
領域模型：領域模型表達了與系統相關的現實世界的不變事實。就Yinzer系統而言，這些相關事實包括如廣告(Ads)和聯系方式（Contacts）等重要類型的定義、類型之間的關系，以及描述類型與關系如何因時而變的行為。通常，無法控制領域模型，例如，無法決定一周只能擁有6天，或者要求每周舉行生日宴會。
設計模型：相反，設計模型主要是在設計者控制下。需要構建的系統不僅會顯示在領域模型中，還會在設計模型中出現。設計模型是設計承若的一部分。這就是說，可以推遲實現那些未曾決策而又事關設計的某些細節（通常出於更低層次），直到獲得代碼模型。設計模型由遞歸嵌套的邊界模型和內部模型組成。邊界模型與內部模型描述了相同的內容（就像組件或模塊），但邊界模型只涉及公共的可見接口，而內部模型還介紹了內部設計。
代碼模型：代碼模型既是系統的源代碼實現，又相當於一個模型。它可以是實際的Java代碼，或通過運行工具將代碼轉換為UML的結果。關鍵還在於它包含了完整的對設計的承若。
設計模型往往會忽略對低風險部分的描述，只要開發者理解了整個設計和架構，設計就是充分的。然而，設計模型對設計的承若是不完整的，代碼模型則不然，至少它對設計的承若完整到足以在機器上運行。
4+1視圖模型
邏輯視圖：分析，設計（結構）
實現視圖：編程（軟件開發）
過程視圖：系統集成（性能，吞吐量，可擴展性）
部署視圖：系統工程（系統拓撲，分發與安裝，通信）
用例視圖：用來描述功能
軟件體系結構
軟件體系結構包組件（Component）、連接件（Connector）和約束（Constraint）三大要素。
組件：可以是一組代碼，如程序的模塊；也可以是一個獨立的程序，如數據庫服務器。連接件可以是過程調用，管道，遠程調用等，用於表示組件之間的相互作用。一個軟件體系結構還包括某些約束，約束一般對象連接時的規則或指明連接的勢態和條件。軟件體系結構是設計過程的一個層次，它處理那些超越算法和數據結構的設計，研究整體設計和描述方法。
模塊(module)
模塊（module）是實現制品的集合，例如，源代碼（類、函數、過程、規則等）、配置文件、數據庫模式定義。
模塊可以把相關的代碼進行分組，只暴露接口而隱藏實現。在這一點上，模塊和類相似，由於模塊常常包含很多類和其他的制品，其規模比類要大。模塊的接口和內部的那些接口是不同的。模塊可以依賴（depend）於另一個模塊。一個模塊可以被包含在另一個模塊內，這個關系稱為嵌套（nesting）,也可以稱為包含。
端口（Ports）
所有進出組件的通信都是通過組件上的端口（ports）來完成的。一個組件支持的所有公開可用的方法，以及要響應的所有公開事件，都會在組件端口中進行規定。如果一個組件要給另一個組件發送消息，要寫數據庫，要獲取互聯網上的信息，就必須通過端口。端口通過操作來透露行為。客戶端常常必須以一種特定的次序或者協議來調用操作。端口可以是有狀態的，這尤其便於跟蹤協議的狀態。
適應變化（Adapting to Change）
-
應該可以很容易地定位到哪一個地方需要變化。It should be easy to locate the place where a change is needed
-
如果要改變單一制品的話，應當只在一處地方進行修改。A change to a single artifact in a program should be made in just one place
-
改變單一制品的話，不應當在其他地方進行改變。A change to an artifact should require no (or minimal) changes to the rest of the program
-
錯誤應當只出現在被改變的地方。An error introduced by the change should only affect the thing being changed
設計模式
To help reason about complex software's code
Strategy(behavioral)
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use if.
策略模式（Strategy Pattern）
定義：
定義一系列算法，將每一個算法封裝起來，並讓它們可以相互替換。策略模式讓算法獨立於使用它的客戶而變化，也稱為政策模式(Policy)。策略模式是一種對象行為型模式。
Strategy Pattern:Define a family of algorithms,encapsulate each one,and make them interchangeable.Strategy lets the algorithm vary independently from clients that use it.
優缺點：
策略模式主要有點在於對"開閉原則"的完美支持，在不修改原有系統的基礎上可以更換算法或者增加新的算法，它很好地管理算法族，提高了代碼的復用性，是一種替換繼承、避免多重條件轉移語句的實現方式；其缺點在於客戶端必須知道所有的策略類，並理解其區別，同時在一定程度上增加了系統中類的個數，可能會存在很多策略類。
適合的場景：
在一個系統里面有許多類，他們之間的區別僅在於它們的行為，使用策略模式可以動態地讓一個對象在許多行為中選擇一種行為；一個系統需要動態地在幾種算法中選擇一種；避免使用難以維護的多重條件選擇語句；希望在具體策略類中封裝算法和與相關的數據結構。
類圖：
Decorator(structural)
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
裝飾模式（Decorator Pattern）
定義：動態地給一個對象增加一些額外的職責（Responsibility）,就增加對象功能來說，裝飾模式比生成子類實現更為靈活。其別名有可以成為包裝器（Wrapper），與適配器模式的別名相同，但它們適用於不同的場合。根據翻譯的不同，裝飾模型也有人稱之為"油漆工模式"，它是一種對象結構型模式。
適用環境：在不影響其他對象的情況下，以動態、透明的方式給的單個對象添加職責。需要動態地給一個對象增加功能，這些功能也可以動態地被撤銷。當不能采用繼承的方式對系統進行擴充或者采用繼承不利於系統擴展和維護時。
Composite(structural)
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
組合模式（Composite Pattern）
定義：組合多個對象形成樹型結構以表示"整體-部分"的結構層次。組合模式對單個對象（即葉子對象）和組合對象（即容器對象）的使用具有一致性。
Composite Pattern:Compose objects into tress structures to represent part-whole hierarchies.Composite lets clients treat individual objects and compositions of objects uniformly.
優缺點：
組合模式的主要優點在於可以方便地對層次結構進行控制，客戶端調用簡單，客戶端可以一致的使用組合結構或其中單個對象，用戶就不必關心自己處理的是單個對象還是整個組合結構，簡化了客戶端代碼；其缺點在於使設計變得更加抽象，且增加新構件時可能會產生一些問題，而且很難對容器中的構件類型進行限制。
適用場景：
需要表示一個對象整體或部分層次；讓客戶能夠忽略不同對象層次的變化，客戶端可以針對抽象構件編程，無需關心對象層次結構的細節；對象的結構是動態的並且復雜程度不一樣，但客戶需要一致地處理它們。
類圖：
Simple Factory(idiom)
Lets a separate class (or method) decide what object to instantiate.
簡單工廠模式(Simple Factory Pattern)
定義：又稱為靜態工廠方法(Static Factory Method)模式，它屬於創建型模式。在簡單工廠模式中，可以根據參數的不同返回不同類的實例。簡單工廠模式專門定義一個類來負責創建其他類的實例，被創建的實例通常都具有相同的父類。
優缺點：
優點：
簡單工廠模式最大的優點在於實現對象的創建和對象的使用分離，將對象的創建交給專門的工廠類負責，但是其最大的缺點在於工廠類不夠靈活，增加新的具體產品需要修改工廠類的判斷邏輯代碼，而且產品較多時，工廠方法代碼將會非常復雜。
適用場景：
工廠類負責創建的對象比較少
客戶端只知道傳入工廠類的參數，對於如何創建對象不關心。
類圖
Factory Method(creational)
Define an interface for creating an object, but let subclasses decide which class to instantiate. Lets a class defer instantiation to subclass.
工廠方法模式(Factory Method Pattern)
定義:工廠方法模式(Factory Method Pattern)又稱為工廠模板，也叫虛擬構造器(Virtual Constructor)模式或多態工廠(Polymorphic Factory)模式，它屬於創建類型模式。在工廠方法模式中，工廠父類負責定義創建產品對象的公共接口，而工廠子類負責生成具體的產品對象，這樣做的目的是將產品類的實例化操作延遲到工廠子類中完成，即通過工廠子類來確定究竟應該實例化哪一個具體產品類。
Factory Method Pattern: Define an interface for creating an object,but let subclasses decide which class to instantiate.Factory Method lets a class defer instantiation to subclasses.
優缺點：
工廠方法模式主要優點是增加新的產品類時無需修改現有系統，並封裝了產品對象的創建細節，系統具有良好的靈活性和可擴展性；其缺點在於增加新產品的同時需要增加新的工廠，導致系統類的個數成對增加，在一定程度上增加了系統的復雜度。
使用場景：一個類不知道它所需要的對象的類；一個類通過其子類來指定創建哪個對象；將創建對象的任務委托給多個工廠子類中的某一個，客戶端在使用時可以無須關心是哪一個工廠子創建產品子類，需要時再動態指定。
類圖：
Abstract Factory(creational)
Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
抽象工廠模式(Abstract Factory Pattern)
定義：提供一個創建一系列相關或相互依賴對象接口，而無須指定它們具體的類。抽象工廠模式又稱為Kit模式，屬於對象創建型模式。
Abstract Factory Pattern:Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
優缺點：
抽象工廠模式的主要有點是隔離了具體類的生成，使得客戶並不需要知道什么被創建，而且每次可以通過具體工廠類創建一個產品族中的多個對象，增加或者替換產品族比較方便，增加新的具體工廠和產品族很方便；主要缺點在於增加新的產品等級結構很復雜，需要修改抽象工廠和所有的具體工廠類，對"開閉原則"的支持呈現傾斜性。
適用場景：
一個系統不應當依賴於產品類實例如何被創建、組合和表達的細節；系統中有多於一個的產品族，而每次只使用其中某一產品族；屬於同一個產品族的產品將在一起使用；系統提供一個產品類的庫，所有的產品以同樣的接口出現，從而使客戶端不依賴與具體實現。
類圖：
State(behavioral)
A monolithic object's behavor is a function of its state, and it must change its behavior at run-time depending on that state.
狀態模式（state Pattern）
定義：允許一個對象在其內部狀態改變時改變它的行為，對象看起來似乎修改了它的類。其別名為狀態對象（Objects for States）,狀態模式是一種對象行為型模式。
適用場景：對象的行為依賴於它的狀態（屬性）並且可以根據它的狀態改變而改變它的相關行為。代碼中包含大量與對象狀態有關的條件語句，這些條件語句的出現，會導致代碼的可維護性和靈活性變差，不能方便地增加和刪除狀態，使客戶類與類庫之間的耦合增強。在這些條件語句包含了對象的行為，而且這些條件對應於對象的各種狀態。
例子：
Observer(behavioral)
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
觀察者模式(Observer Pattern)
定義：
定義對象間的一種一對多依賴關系，使得每當一個對象狀態發生改變時，其相關依賴對象皆得到通知並被自動更新。觀察者模式又叫做發布-訂閱模式(Publish/Subscribe)，模式-視圖模式(Modle/View)，源-監聽器(Source/Listener)模式或從屬者(Dependents)模式。觀察者模式是一種對象行為型模式
Observer Pattern:Define a one-to-many dependency between objects so that when one object changes state,all its dependents are notified and updated automatically.
優缺點：
觀察者模式的主要優點在於可以實現表示層和數據邏輯層的分離，並在觀察目標和觀察者之間建立一個抽象的耦合，支持廣播通信；其主要缺點在於如果一個觀察目標對象有很多直接和間接的觀察者的話，將所有的觀察者都通知到回花費很多時間，而且如果在觀察者和觀察目標之間有循環依賴的話，觀察目標會觸發它們之進行循環調用，可能導致系統崩潰。
使用場景：
一個抽象模型有兩個方面，其中一個方面依賴於另一個方面；一個對象的改變將導致其他一個或多個對象也發生改變，而不知道具體有多少對象將發生改變；一個對象必須通知其他對象，而並不知道這些對象是誰；需要在系統中創建一個觸發鏈。
類圖：
Singleton(Creational; anti-pattern)
Ensures a class has only instance, and provides a global point of access to it.
單例模式(Singleton Pattern)
定義:
單例模式確保某一個類只有一個實例，而且自行實例化並向整個系統提供這個實例，這個類稱為單例類，它提供全局訪問的方法。
Singleton Pattern:Ensure a class has only one instance and provide a global point of access to it.
優缺點:
單例模式的主要優點在於提供了對唯一實例的受控訪問並可以節約系統資源；其主要的缺點在於因為缺少抽象層而難以擴展，且單例類職責過重。
適用場景：
系統只需要一個實例對象；客戶調用類的單個實例只允許使用一個公共訪問點。
類圖：
Adapter(structural)
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
適配器模式(Adapter Pattern)
定義：
將一個接口轉換成客戶希望的另一個接口，適配器模式使接口不兼容的那些類可以一起工作，其別名為包裝器(Wrapper)。適配器模式既可以作為類結構型模式，也可以作為對象結構型模式。
Adapter Pattern:convert the interface of a class into another interface clients expect.Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
優缺點：
適配器模式的主要優點是將目標類和適配者類解耦，增加了類的透明性和復用性，同時系統的靈活性和擴展性都非常方便，符合"開閉原則"；類適配器模式的缺點是適配器在很多編程語言中不能同時適配多個適配者類，對象適配器模式的缺點是很難置換適配者類的方法。
適用場景：
系統需要使用現有的類，而這寫類的接口不符合系統道德需要；想要建議一個可以重復使用的類，用於與一些彼此之間沒有太大關聯的一些類一起工作。
類圖
類適配器
對象適配器
Façade(structural)
Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
外觀模式(Façade Pattern)
外部與一個子系統的通信必須通過一個統一的外觀對象進行，為子系統中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。外觀模式又稱為門面模式，它是一種對象結構型模式。
Façade Pattern:Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.
優缺點：
外觀模式主要優點在於對客戶屏蔽子系統組件，減少了客戶處理的對象數目並使得子系統使用起來更加容易，它實現了子系統與客戶之間的松耦合關系，並降低了大型軟件系統中的編譯依賴性，簡化了系統在不同平台之間的移植過程；其缺點在於不能很好地限制客戶使用子系統類，而且在不引入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或客戶端的源代碼，違背了"開閉原則"。
適用場景：要為一個復雜子系統提供一個簡單接口；客戶程序與多個子系統之間存在很大的依賴性；在層次化結構中，需要定義系統中每一層的入口，使得層與層之間不直接產生聯系。
類圖：
Proxy(structural)
Provide a surrogate or placeholder for another object to control access to it.
代理模式(Proxy Pattern)
給某一個對象提供一個代理，並由代理對象控制對原對象的引用。代理模式的英文叫做Proxy或Surrogate，它是一種對象結構型模式。
Proxy Pattern:Provide a surrogate or placeholder for another object to control access to it.
優缺點：
代理模式的優點在於能夠協調調用者和被調用者，在一定程度上降低了系統的耦合度；其缺點在於由於在客戶端和真實主題之間增加了代理對象，因此有些類型的代理模式可能會造成請求的處理速度變慢，並且實現代理模式需要額外的工作，有些代理模式的實現非常復雜。
適用場景：
遠程代理為一個位於不同的地址空間的對象提供一個本地的代表對象，它使得客戶端可以訪問在遠程機器上的對象，遠程機器可能具有更好的計算性能與處理速度，可以快速響應並處理客戶端請求。
如果需要創建一個資源消耗較大的對象，先創建一個消耗相對較小的對象來表示，真實對象只在需要時才會被真正創建，這個小對象稱為虛擬代理。虛擬代理通過使用一個小對象來代表一個大對象，可以減少系統資源的消耗，對系統進行優化並提高運行速度。
保護代理可以控制對一個對象的訪問，可以給不同的用戶提供不同級別的使用權限。
類圖
大部分的設計模型都有如下的通用規則。（Most design patterns work by following the same general process）:
-
（識別程序中變化的部分）Identify the part of the program that changes(algorithm, state, method, constructor, etc)
-
（將變化的部分封裝成一個類）Encapsulate that functionality into a class
-
（通過其他的類進行實例化）Make instances of the new class components(instance variables) of other classes.