熟練掌握各種設計模式，并能在實際編程開發(fā)中靈活運用它們博烂，不僅能使代碼更規(guī)范香椎，重用性更高，同時也能保證代碼的可靠性禽篱，提高開發(fā)效率畜伐。這段時間又系統(tǒng)看了設計模式的相關內容，整理學習總結如下躺率，文中內容如有表達有誤的地方玛界，還請指出，共同交流學習悼吱。
一慎框、概述
二、7個設計原則
三后添、創(chuàng)建型模式(5種)
四鲤脏、結構型模式(7種)
五、行為型模式(11種)
六吕朵、總結
一猎醇、概述
面向對象編程有七大原則，即經常提到的Design Pattern努溃，提倡它的根本原因是為了代碼復用硫嘶，增加可維護性。設計模式就是實現(xiàn)了這些原則梧税，從而達到了代碼復用沦疾、增加可維護性的目的。
七大設計原則
設計模式是一套被反復使用的第队、多數(shù)人知曉的哮塞、經過分類編目的、代碼設計經驗的總結凳谦。使用設計模式是為了重用代碼忆畅、讓代碼更容易被他人理解、保證代碼可靠性尸执。 毫無疑問家凯，設計模式于己于他人于系統(tǒng)都是多贏的缓醋，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石绊诲，如同大廈的一塊塊磚石一樣送粱。
設計模式
二、7個設計原則
因為設計模式就是基于這些原則的實現(xiàn)掂之，所以很有必要了解這些原則抗俄，下面主要對面向對象編程的幾個原則進行簡單介紹。
1世舰、單一職責原則 ( SRP )
英文全稱是Single Responsibility Principle橄镜，定義是一個類，應該只有一個引起它變化的原因冯乘。類變化的原因就是職責洽胶，如果一個類承擔的職責過多，就等于把這些職責耦合在一起了裆馒。一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力姊氓。這種耦合會導致脆弱的設計，當發(fā)生變化時喷好，設計會遭受到意想不到的破壞翔横。而如果想要避免這種現(xiàn)象的發(fā)生，就要盡可能的遵守單一職責原則梗搅。此原則的核心就是解耦和增強內聚性禾唁。
2、開閉原則 ( OCP )
英文全稱是Open Close Principle无切，定義是軟件實體（包括類荡短、模塊 、函數(shù)等）應該對于擴展時開放的哆键，對于修改是封閉的掘托。開閉原則是是面向對象設計中最重要的原則之一，其它很多的設計原則都是實現(xiàn)開閉原則的一種手段籍嘹。
3闪盔、里氏替換原則 ( LSP )
英文全稱是Liskov Substitution Principle，是面向對象設計的基本原則之一辱士。 定義是任何基類可以出現(xiàn)的地方泪掀，子類一定可以出現(xiàn)。LSP 是繼承復用的基石颂碘，只有當派生類可以替換掉基類异赫，且軟件單位的功能不受到影響時，基類才能真正被復用，而派生類也能夠在基類的基礎上增加新的行為祝辣。里氏替換原則是對開閉原則的補充贴妻。實現(xiàn)開閉原則的關鍵步驟就是抽象化切油，而基類與子類的繼承關系就是抽象化的具體實現(xiàn)蝙斜，所以里氏替換原則是對實現(xiàn)抽象化的具體步驟的規(guī)范。
4澎胡、依賴倒置原則 ( DIP )
英文全稱是Dependence Inversion Principle孕荠，這個原則是開閉原則的基礎，依賴倒置原則就是要求調用者和被調用者都依賴抽象攻谁，這樣兩者沒有直接的關聯(lián)和接觸稚伍，在變動的時候，一方的變動不會影響另一方的變動戚宦。依賴倒置強調了抽象的重要性个曙，針對接口編程，依賴于抽象而不依賴于具體受楼。點擊查看更多
5垦搬、接口隔離原則 ( ISP )
英文全稱是Interface Segregation Principle，這個原則的意思是使用多個隔離的接口艳汽，比使用單個接口要好猴贰。目的就是降低類之間的耦合度，便于軟件升級和維護河狐。
6米绕、最少知道原則(迪米特原則)
一個實體應當盡量少地與其他實體之間發(fā)生相互作用，使得系統(tǒng)功能模塊相對獨立馋艺。通俗地說就是不要和陌生人說話栅干，即一個對象應對其他對象有盡可能少的了解。迪米特法則的初衷在于降低類之間的耦合捐祠。由于每個類盡量減少對其他類的依賴非驮，因此，很容易使得系統(tǒng)的功能模塊功能獨立雏赦，相互之間不存在（或很少有）依賴關系劫笙。
7、合成/聚合復用（CARP）
英文全稱是Composite Reuse Principle星岗，合成/聚合復用原則經常又叫做合成復用原則填大。合成/聚合復用原則的潛臺詞是：我只是用你的方法，我們不一定是同類俏橘。繼承的耦合性更大允华，比如一個父類后來添加實現(xiàn)一個接口或者去掉一個接口，那子類可能會遭到毀滅性的編譯錯誤，但如果只是組合聚合靴寂，只是引用類的方法磷蜀，就不會有這種巨大的風險，同時也實現(xiàn)了復用百炬。
三褐隆、創(chuàng)建型模式 ( 5種 )
創(chuàng)建型模式是指這些設計模式提供了一種在創(chuàng)建對象的同時隱藏創(chuàng)建邏輯的方式，而不是使用新的運算符直接實例化對象剖踊。這使得程序在判斷針對某個給定實例需要創(chuàng)建哪些對象時更加靈活庶弃。
創(chuàng)建型模式
1.單例模式
定義
確保某一個類只有一個實例，并自行實例化向整個系統(tǒng)提供這個實例德澈。
簡介
單例模式理解起來不難歇攻，典型例子有一個公司只能有一個CEO。它主要是為了保證一個類僅有一個實例梆造，這個類中自己提供一個返回實例的方法缴守，方法中先判斷系統(tǒng)是否已經有這個單例，如果有則返回镇辉，如果沒有則創(chuàng)建屡穗。如果創(chuàng)建多個實例會消耗過多的資源或者某種類型的對象只應該有且只有一個時，應該考慮使用單例模式摊聋。
實現(xiàn)
單例模式理解起來不難鸡捐，重要的是需要掌握它的幾種常見寫法。
寫法一麻裁、懶漢式寫法
public class Singleton {
? ? private static Singleton instance;
? ? //構造函數(shù)私有
? ? private Singleton (){
? ? }?
? ? public static synchronized Singleton getInstance() {
? ? ? ? if (instance == null) {?
? ? ? ? ? ? instance = new Singleton();?
? ? ? ? }?
? ? ? ? return instance;?
? ? }?
}?
寫法二箍镜、DCL（Double Check Lock） 雙重校驗鎖
public class Singleton {?
? ? private volatile static Singleton singleton;?
? ? private Singleton (){
? ? }?
? ? public static Singleton getSingleton() {?
? ? ? ? if (singleton == null) {?
? ? ? ? ? ? synchronized (Singleton.class) {?
? ? ? ? ? ? if (singleton == null) {?
? ? ? ? ? ? ? ? singleton = new Singleton();?
? ? ? ? ? ? }?
? ? ? ? ? }?
? ? ? ? }?
? ? ? ? return singleton;?
? ? }?
}?
寫法三、靜態(tài)內部類單例模式
public class Singleton {?
? ? private Singleton (){
? ? }?
? ? public static final Singleton getInstance() {?
? ? ? ? ? return SingletonHolder.INSTANCE;?
? ? }?
? ? private static class SingletonHolder {?
? ? ? ? private static final Singleton INSTANCE = new Singleton();?
? ? }
}?
上面只列出了單例模式常見的三種寫法煎源，單例模式還有好幾種別的寫法色迂，這里就不全部列出了。上面的第一種懶漢式寫法做到了延遲創(chuàng)建和線程安全手销，缺點是每次調用getInstance()時都必須進行同步歇僧，效率不佳。第二種DCL方式比較常見锋拖，兩次判空诈悍，第一次判空避免了不必要的同步，第二次保證了單例創(chuàng)建兽埃，這種方式比較不錯侥钳，但是在高并發(fā)環(huán)境下有時會出現(xiàn)問題。第三種方法最被推薦柄错，線程安全也保證了實例唯一舷夺。
2.工廠方法模式
定義
定義一個用于創(chuàng)建對象的接口苦酱，讓子類決定實例化哪一個類。
舉例
工廠方法模式的典型例子给猾，自行車分為山地自行車和公路自行車等疫萤，當需要買自行車時，我們直接去自行車廠里告訴廠長我們需要的自行車即可敢伸。
例子
1扯饶、定義一個接口自行車，Bike详拙。
public interface Bike{
? ? void ride();
}
2帝际、定義實現(xiàn)類山地自行車蔓同，MBike
public class MBike implements Bike{
? ? @Override
? ? public void draw() {
? ? ? ? ? System.out.println("MBike Rides... ");
? ? }
}
3饶辙、定義實現(xiàn)類公路自行車，RBike
public class RBike implements Bike{
? ? @Override
? ? public void draw() {
? ? ? ? ? System.out.println("RBike Rides... ");
? ? }
}
4斑粱、工廠類弃揽，負責創(chuàng)建對象
public class BikeFactory {
? //使用 getShape 方法獲取形狀類型的對象
? public Bike getBike(String bikeType){
? ? ? if(bikeType == null){
? ? ? ? return null;
? ? ? }? ?
? ? ? if(bikeType.equalsIgnoreCase("MBike")){
? ? ? ? return new MBike();
? ? ? }else if(shapeType.equalsIgnoreCase("RBike")){
? ? ? ? return new RBike();
? ? ? }
? ? ? return null;
? }
}
5、子類決定實例化哪一個類
public class FactoryPatternDemo {
? public static void main(String[] args) {
? ? ? BikeFactory bikeFactory = new BikeFactory();
? ? ? Bike bike1 = bikeFactory.getBike("MBike");
? ? ? bike1.ride();
? ? ? Bike bike2= bikeFactory.getBike("RBike");
? ? ? bike2.ride();
? }
}
3.抽象工廠模式
定義
提供一個創(chuàng)建一系列相關或相互依賴對象的接口则北，而無需指定它們具體的類矿微。
簡介
抽象工廠模式主要解決接口選擇的問題，典型例子是手機和電腦問題尚揣，假設抽象產品1是手機涌矢，具體產品是Android手機和iOS手機，抽象產品2是電腦快骗，具體產品是Windows電腦和Mac電腦娜庇，抽象工廠是同時生產手機和電腦的公司，具體工廠是聯(lián)想公司和蘋果公司方篮。
抽象工廠的優(yōu)點是當一個產品族中的多個對象被設計成一起工作時名秀，它能保證客戶端始終只使用同一個產品族中的對象。缺點是產品族擴展非常困難藕溅，要增加一個系列的某一產品匕得，既要在抽象工廠里加代碼，又要在具體工廠里加代碼巾表。點擊查看更多
4.建造者模式
定義
將一個復雜的構建與其表示相分離汁掠，使得同樣的構建過程可以創(chuàng)建不同的表示。
簡介
建造者模式主要解決在軟件系統(tǒng)中一個復雜對象的創(chuàng)建工作集币。通常一個復雜對象是由各個部分的子對象用一定的算法構成考阱，由于需求的變化，這個復雜對象的各個部分經常面臨著劇烈的變化惠猿，但是將它們組合在一起的算法卻相對穩(wěn)定羔砾。
建造者模式的一個典型例子是Android中的AlertDialog的構建過程负间。還有個例子是計算機的組裝，計算機是個復雜的對象姜凄，它是有很多零件組裝而成政溃，顯示器、操作系統(tǒng)态秧，鼠標等董虱，通過創(chuàng)建Builder接口來控制零件的組裝過程，這樣當組件發(fā)生變化時申鱼，雖然經過同樣的構建過程愤诱，但是最后得到的結果不同。點擊查看更多
5.原型模式
定義
用原型實例指定創(chuàng)建對象的種類捐友，并且通過拷貝這些原型創(chuàng)建新的對象淫半。
簡介
原型模式不難理解，它主要是用在實例創(chuàng)建的時候匣砖，因為有的時候我們通過new創(chuàng)建一個對象時可能成本過高科吭，這時我們可以考慮直接通過直接克隆實例快速創(chuàng)建對象『秭辏克隆后的實例與原實例內部屬性一致对人。原型模式需要注意一個深拷貝和淺拷貝的問題。點擊查看更多
四拂共、結構型模式(7種)
結構型模式關注類和對象的組合牺弄。繼承的概念被用來組合接口和定義組合對象獲得新功能的方式。
結構型模式
1.適配器模式
定義
將一個類的接口轉換成另外一個客戶希望的接口宜狐。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作势告。
簡介
適配器模式包括兩種類型，類適配器模式和對象適配器模式肌厨。這里主要介紹對象適配器模式培慌，因為它更靈活。適配器模式中主要有三個部分柑爸，Target吵护、Adapter和Adaptee，其中Target是目標角色表鳍，Adaptee是需要被轉換的對象馅而，Adapter就是適配器。例如譬圣，現(xiàn)在有個手機充電電壓是5v瓮恭，而插座電壓是220v，這時我們可以把充電器看成是Adapter厘熟，它將電壓進行轉化最后得到結果屯蹦。點擊查看更多
例子
// Target 目標接口
public interface Volt5 {
? ? public int getVolt5();
}
// Adaptee 需要被轉換的對象
public class Volt220 {
? ? public int getVolt220() {
? ? ? ? return 220;
? ? }
}
//Adapter 適配器
public class VoltAdapter implements Volt5 {
? ? Volt220 mVolt220;
? ? public VoltAdapter(Volt220 adaptee) {
? ? ? ? mVolt220 = adaptee;
? ? }
? ? public int getVolt220() {
? ? ? ? return 220;
? ? }
? ? @Override
? ? public int getVolt5() {
? ? ? ? return 5;
? ? }
}
2.橋接模式
定義
將抽象部分與實現(xiàn)部分分離维哈，使它們都可以獨立的變化。
-簡介
在軟件系統(tǒng)中登澜，某些類型由于自身的邏輯阔挠，它具有兩個或多個維度的變化，那么如何應對這種“多維度的變化”脑蠕？這就要使用橋接模式购撼。橋接模式需要重點理解的抽象部分，實現(xiàn)部分谴仙，脫耦迂求。一個典型的例子是咖啡加糖問題，抽象部分有Coffee晃跺，其下有LargeCoffee揩局，SmallCoffee，實現(xiàn)部分是CoffeeAdd哼审，其下有Sugar谐腰，Normal孕豹，抽象類Coffee中引用CoffeeAdd涩盾，這樣CoffeeAdd其實就是一個橋接。點擊查看更多
3.裝飾模式
定義
動態(tài)地給一個對象添加一些額外的職責励背。就增加功能來說春霍，Decorator模式相比生成子類更為靈活。
簡介
裝飾模式是作為現(xiàn)有的類的一個包裝叶眉，它允許向一個現(xiàn)有的對象添加新的功能址儒，同時又不改變其結構。這種模式創(chuàng)建了一個裝飾類衅疙，用來包裝原有的類莲趣，并在保持類方法簽名完整性的前提下，提供了額外的功能饱溢。裝飾模式主要是裝飾器類Decorator的設計喧伞，它對指定對象進行裝飾。點擊查看更多
4.組合模式
定義
將對象組合成樹形結構以表示“部分-整體”的層次結構绩郎，使得用戶對單個對象和組合對象的使用具有一致性潘鲫。
簡介
組合模式理解起來相對簡單，典型的例子就是假設公司A肋杖，里面有不同的部門溉仑，不同的部分下有不同的員工，這樣一個部門下的所有員工組合成了一個部門状植，所有部門組合成了整個公司浊竟。
5.外觀模式
定義
為子系統(tǒng)中的一組接口提供一個一致的界面怨喘，外觀模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用振定。
簡介
外觀模式的一個典型例子是去醫(yī)院看病哲思，掛號、門診吩案、劃價棚赔、取藥，讓患者或患者家屬覺得很復雜徘郭，如果有提供接待人員靠益，只讓接待人員來處理，就很方便残揉。點擊查看更多
6.享元模式
定義
運用共享技術有效地支持大量細粒度的對象胧后。
簡介
在有大量對象時，有可能會造成內存溢出抱环，我們把其中共同的部分抽象出來壳快，如果有相同的業(yè)務請求，直接返回在內存中已有的對象镇草，避免重新創(chuàng)建眶痰。點擊查看更多
7.代理模式
定義
為其他對象提供一種代理以控制對這個對象的訪問。
簡介
代理模式主要解決在直接訪問對象時帶來的問題梯啤。舉個例子竖伯，豬八戒去找高翠蘭結果是孫悟空變的，可以這樣理解：把高翠蘭的外貌抽象出來因宇，高翠蘭本人和孫悟空都實現(xiàn)了這個接口七婴，豬八戒訪問高翠蘭的時候看不出來這個是孫悟空，所以說孫悟空是高翠蘭代理類察滑。點擊查看更多
五打厘、行為型模式 ( 11種 )
這些設計模式特別關注對象之間的通信。
行為型模式
1.模板方法模式
定義
一個操作中的算法的框架贺辰，而將一些步驟延遲到子類中户盯，使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
例子
模板方法模式一個典型例子就是Android中的異步任務類AsyncTask魂爪，它對異步任務的執(zhí)行進行了流程封裝先舷，子類繼承它時，只需在指定的流程中實現(xiàn)具體的操作即可滓侍。點擊查看更多關于模板方法模式的介紹
2.命令模式
定義
將一個請求封裝為一個對象蒋川，從而可用不同的請求對客戶進行參數(shù)化；對請求排隊或記錄請求日志撩笆，以及支持可取消的操作
簡介
命令模式主要是通過調用者調用接受者執(zhí)行命令捺球，這個模式中需要理解的是三個角色：(1) Receiver 真正的命令執(zhí)行對象 (2) Command 持有一個對Receiver的引用吼渡，調用Receiver的相關方法隅肥。(3) Invoker 請求者眉踱，持有一個對Command的引用抱慌，調用Command的方法執(zhí)行具體命令。點擊查看更多關于命令模式的介紹
3.迭代器模式
定義
提供一種方法順序訪問一個聚合對象中各個元素, 而又不需暴露該對象的內部表示泣栈。
簡介
在Java集合框架中我們知道對于一個指定的集合類卜高，我們可以使用一個特定的Iterator迭代器來對集合中的所有元素進行遍歷。這樣結合來看南片，迭代器模式很好理解了掺涛。點擊查看更多
4.觀察者模式
定義
定義對象間的一種一對多的依賴關系，當一個對象的狀態(tài)發(fā)生改變時疼进，所有依賴于它的對象都得到通知并被自動更新薪缆。
簡介
觀察者模式可以結合Android中的ListView來理解，ListView關聯(lián)的適配器Adapter在數(shù)據(jù)發(fā)生變化時會通過notifyDataSetChanged()方法來通知界面刷新伞广。點擊查看更多介紹
5.中介者模式
定義
用一個中介對象來封裝一系列的對象交互拣帽。中介者使各對象不需要顯式地相互引用，從而使其耦合松散嚼锄，而且可以獨立地改變它們之間的交互减拭。
簡介
中介者模式的典型例子就是未加入 WTO 之前各個國家相互貿易，結構復雜灾票，大家都加入WTO后是各個國家通過 WTO 來互相貿易峡谊，變得規(guī)范。點擊查看更多介紹
6.備忘錄模式
定義
在不破壞封裝性的前提下刊苍，捕獲一個對象的內部狀態(tài)，并在該對象之外保存這個狀態(tài)濒析。這樣以后就可將該對象恢復到保存的狀態(tài)正什。
簡介
備忘錄模式的典型例子就是git版本管理工具，它幫我們保存了每次提交后的項目狀態(tài)号杏，在必要的時候我們可以回退到指定的版本中婴氮。點擊查看更多
7.解釋器模式
定義
給定一個語言，定義它的文法的一種表示盾致，并定義一個解釋器主经，這個解釋器使用該表示來解釋語言中的句子。
簡介
解釋器的典型例子是在編譯原理中的應用庭惜，如果一種特定類型的問題發(fā)生的頻率足夠高罩驻，那么可能就值得將該問題的各個實例表述為一個簡單語言中的句子。這樣就可以構建一個解釋器护赊，該解釋器通過解釋這些句子來解決該問題惠遏。點擊查看更多
8.狀態(tài)模式
定義
允許一個對象在其內部狀態(tài)改變時改變它的行為砾跃。對象看起來似乎修改了它的類。
簡介
狀態(tài)模式主要解決對象的行為依賴于它的狀態(tài)（屬性）节吮，并且可以根據(jù)它的狀態(tài)改變而改變它的相關行為抽高。典型的例子是一個人在不同的狀態(tài)下完成一件事的結果可能是不同的。點擊查看更多
9.策略模式
定義
定義一系列的算法,把它們一個個封裝起來, 并且使它們可相互替換透绩。本模式使得算法可獨立于使用它的客戶而變化翘骂。
簡介
從策略模式的定義可以看到它主要是將算法和客戶獨立開，一個典型的例子是排序算法帚豪，我們給定一個數(shù)組雏胃，輸出排序后的結果，但是過程中我們可以采取不同的排序算法志鞍，這些算法其實就是策略瞭亮。點擊查看更多
10.責任鏈模式
定義
使多個對象都有機會處理請求，從而避免請求的發(fā)送者和接收者之間的耦合關系固棚。將這些對象連成一條鏈统翩，并沿著這條鏈傳遞該請求，直到有一個對象處理它為止此洲。
簡介
責任鏈模式厂汗，避免請求發(fā)送者與接收者耦合在一起，讓多個對象都有可能接收請求呜师，將這些對象連接成一條鏈娶桦，并且沿著這條鏈傳遞請求，直到有對象處理它為止汁汗。點擊查看更多
11.訪問者模式
定義
封裝一些作用于某種數(shù)據(jù)結構中的各元素的操作衷畦。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。
簡介
訪問者模式是一種將數(shù)據(jù)操作和數(shù)據(jù)結構分離的設計模式知牌，它通常使用在對象結構比較穩(wěn)定祈争，但是經常需要在此對象結構上定義新的操作，或者需要對一個對象結構中的對象進行很多不同的并且不相關的操作角寸，而需要避免讓這些操作"污染"這些對象的類菩混，使用訪問者模式將這些封裝到類中。點擊查看更多
六扁藕、總結
到這里沮峡，Java設計模式的學習總結就結束了，因為篇幅關系亿柑，有些模式只是簡單介紹了一下邢疙，想要進一步學習的話還是要靠大家自己去查閱相關資料學習。熟練地掌握設計模式，還需多多的實踐秘症，路漫漫其修遠兮照卦，吾將上下而求索，加油乡摹！
小編已經整理出來了 就等各位同學前來免費領取 私聊小編回復“資料”就可以獲得免費資料
40閱讀
搜索
一分鐘記住設計模式
java23種設計模式列表
23種設計模式全解析
圖解23種設計模式
設計模式圖譜
23種設計模式結構圖
