設(shè)計(jì)模式，是對(duì)很多已有問(wèn)題的常規(guī)處理方式田绑。大多數(shù)材料記錄了23種設(shè)計(jì)模式勤哗，但是要記在腦海里需要一定時(shí)間的代碼練習(xí)和理解。我在學(xué)習(xí)《Java設(shè)計(jì)模式及應(yīng)用案例》這本書(shū)時(shí)掩驱，將部分設(shè)計(jì)模式的代碼實(shí)現(xiàn)進(jìn)行了整理并放在Github上芒划，如有需要點(diǎn)擊該鏈接
Github-DesignMode
我喜歡將設(shè)計(jì)模式按照目的分為三類：
創(chuàng)建型模式（5種）：
工廠方法模式(Factory Method Pattern)
抽象工廠模式(Abstract Factory Pattern)
單例模式(Singleton Pattern)
建造者模式(Builder Pattern)
原型模式(Prototype Pattern)
結(jié)構(gòu)性模式（7種）
適配器模式(Adapter Pattern)
裝飾者模式(Decorator Pattern)
代理模式(Proxy Pattern）
外觀模式(Facade Pattern)
橋接模式(Bridge Pattern)
組合模式(Composite Pattern)
享元模式(Flyweight Pattern)
行為型模式（11種）
策略模式(Strategy Pattern）
模板方法模式(Template Method Pattern）
觀察者模式(Observer Pattern)
迭代器模式(Iterator Pattern)
責(zé)任鏈模式(Chain of Responsibility Pattern)
命令模式(Command Pattern)
備忘錄模式(Memento Pattern)
狀態(tài)模式(State Pattern)
訪問(wèn)者模式(Visitor Pattern)
中介者模式(Mediator Pattern)
解釋器模式(Interpreter Pattern)
設(shè)計(jì)模式六大原則
開(kāi)閉原則
開(kāi)閉原則具有兩個(gè)特性，其一是對(duì)擴(kuò)展是開(kāi)放的欧穴，其二是對(duì)于更改是封閉的民逼。這樣做的好處是對(duì)代碼可維護(hù)、可擴(kuò)展涮帘、可復(fù)用拼苍、靈活性好。同時(shí)還可以保證以前代碼的正確性调缨，因?yàn)槲覀儾](méi)有修改代碼疮鲫，所以可以保證開(kāi)發(fā)人員能夠?qū)Ｗ⒂趯⒃O(shè)計(jì)放在新擴(kuò)展的代碼上。
主要是對(duì)關(guān)鍵步驟進(jìn)行抽象化---封裝同蜻。例如setXXX 或者 getXXX里氏替換原則
這個(gè)主要是一個(gè)軟件實(shí)體如果使用一個(gè)父類的話棚点，那么一定適用于父類的子類早处。而且它覺(jué)察不出父類對(duì)象和子類對(duì)象的區(qū)別湾蔓。也就是說(shuō)，在軟件里面砌梆，把父類替換成它的子類默责。程序的行為是沒(méi)有變化。
通俗的來(lái)說(shuō)：子類是可以擴(kuò)展父類的功能咸包，但是不能改變父類原有的功能桃序。依賴倒轉(zhuǎn)原則
高層模塊不依賴底層模塊，二者都要依賴其抽象烂瘫；抽象不應(yīng)該依賴細(xì)節(jié)媒熊，細(xì)節(jié)也應(yīng)該依賴抽象。說(shuō)白了就是面向接口編程坟比。因?yàn)橄鄬?duì)于細(xì)節(jié)來(lái)說(shuō)芦鳍，抽象的東西要穩(wěn)定很多。以抽象搭建起來(lái)的架構(gòu)比細(xì)節(jié)搭建起來(lái)的架構(gòu)要穩(wěn)定的多葛账。
通俗的來(lái)說(shuō)柠衅，面向抽象編程，而不是面向細(xì)節(jié)編程
舉個(gè)例子來(lái)說(shuō)籍琳，一個(gè)團(tuán)隊(duì)菲宴，有需求組贷祈，開(kāi)發(fā)組，測(cè)試組喝峦。而開(kāi)發(fā)組和測(cè)試組面對(duì)同樣的需求势誊，做自己響應(yīng)的工作。而不是測(cè)試組按照開(kāi)發(fā)組的理解需求去做測(cè)試用例谣蠢。也就是說(shuō)開(kāi)發(fā)組和測(cè)試組是直接面向需求組工作的接口隔離原則
使用多個(gè)專門(mén)的接口键科，比使用一個(gè)單一的接口要好。因?yàn)樵谠O(shè)計(jì)中漩怎，依賴幾個(gè)專用的接口要比依賴一個(gè)單一的接口更加靈活勋颖。
通俗的來(lái)講：細(xì)化多個(gè)接口，不要建立臃腫的接口
一個(gè)接口就好比一個(gè)劇本中的角色勋锤，而這個(gè)角色在一個(gè)舞臺(tái)上的表演相當(dāng)于接口的實(shí)現(xiàn)饭玲。因此，一個(gè)接口相當(dāng)于代表一個(gè)角色叁执，而不是多個(gè)角色茄厘。如果系統(tǒng)涉及多個(gè)角色的話，那么每一個(gè)角色都應(yīng)當(dāng)由一個(gè)特定的接口代表谈宛。
這里與單一職責(zé)的區(qū)別在于次哈，單一職責(zé)原則注重的是職責(zé)，約束類吆录，其次才是接口和方法窑滞；而接口隔離原則注重的是對(duì)接口依賴的隔離，約束接口恢筝，主要針對(duì)抽象哀卫、針對(duì)整體框架的搭建。最少知道原則
這里強(qiáng)調(diào)的是類之間的松耦性撬槽，類之間的耦合性越弱此改，越有利于復(fù)用。一個(gè)處于低耦合的類被修改侄柔，不會(huì)對(duì)有關(guān)系的類造成影響共啃。也就是說(shuō)，信息的隱藏促進(jìn)了軟件的復(fù)用暂题。
通俗的來(lái)講：就是一個(gè)類對(duì)自己依賴的類知道的越少越好移剪。也就是說(shuō)，對(duì)于被依賴的類敢靡，無(wú)論邏輯多么復(fù)雜挂滓，都盡量將邏輯封裝在類的內(nèi)部。對(duì)外除了提供public方法，不對(duì)外泄露任何信息
而我們常說(shuō)的低耦合赶站、高內(nèi)聚正是由這個(gè)原則去完成的幔虏。總之一句話贝椿，一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象保持最少的了解想括。單一職責(zé)原則
在軟件編程中，我們不希望修改了一個(gè)功能導(dǎo)致其他的功能出現(xiàn)問(wèn)題烙博。而避免這個(gè)問(wèn)題的方法便是遵循單一職責(zé)原則瑟蜈。
通俗的來(lái)講：一個(gè)類負(fù)責(zé)一項(xiàng)職責(zé)，應(yīng)該僅有一個(gè)引起它變化的原因
單一職責(zé)原則的優(yōu)點(diǎn)可以提高類的可讀性渣窜，提高系統(tǒng)的可維護(hù)性铺根，變更引起的風(fēng)險(xiǎn)降低。這個(gè)原則并非只是在面向?qū)ο缶幊趟枷胨赜星撬蓿灰悄K化的程序設(shè)計(jì)位迂，都需要遵循這個(gè)原則。
