軟件體系結構

軟件體系結構

質量屬性：

開發期質量:可擴展性，可複用性，可維護性等；

運行期質量：正確性，健壯性，性能，可靠性，容錯性，易用性，安全性，可移植性，兼容性。

 

 

設計原則：

1. 面向接口編程（Program to interfaces, not to implementations）
2. 多用組合，少用繼承（Favor composition over inheritance）
3. Principle of Least Knowledge(Law of Demeter)
4. 單一職責原則（Single Responsibility Principle）：就一個類而言，應該僅有一個引發它變化的緣由。
5. 開閉原則（Open-Closed Principle）：軟件實體對擴展是開放的，但對修改是關閉的，即在不修改一個軟件實體的基礎上去擴展其功能。抽象化是開閉原則的關鍵
6. 里氏代換原則（Liskov Substitution Principle）：在軟件系統中，一個能夠接受基類對象的地方必然能夠接受一個子類對象。里氏代換原則是實現開閉原則的重要方法之一。
7. 依賴倒置原則（Dependency Inversion Principle）：要針對抽象層編程，而不要針對具體類編程。實現開閉原則的關鍵是抽象化，而且從抽象導出具體化實現，若是說開閉原則是面向對象設計的目標的話，那麼依賴倒置原則就是面向對象設計的主要手段。依賴注入：構造注入，設置注入，接口注入
8. 接口隔離原則（Interface Segregation Principle）：使用多個專門的接口來取代一個統一的接口。
9. 分離關注點（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架構的主要原則：

1. 網絡上的全部事情都被抽象爲資源
2. 每一個資源都有一個惟一的資源標識符
3. 同一個資源具備多種表現形式（xml，json等）
4. 對資源的各類操做不會改變資源標識符
5. 全部的操做都是無狀態的
6. 符合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）

1. 應該能夠很容易地定位到哪個地方須要變化。It should be easy to locate the place where a change is needed
2. 若是要改變單一製品的話，應當只在一處地方進行修改。A change to a single artifact in a program should be made in just one place
3. 改變單一製品的話，不該當在其餘地方進行改變。A change to an artifact should require no (or minimal) changes to the rest of the program
4. 錯誤應當只出如今被改變的地方。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）:

1. （識別程序中變化的部分）Identify the part of the program that changes(algorithm, state, method, constructor, etc)
2. （將變化的部分封裝成一個類）Encapsulate that functionality into a class
3. （經過其餘的類進行實例化）Make instances of the new class components(instance variables) of other classes.