PS:首先咱們要帶着問題讀文章html
設計模式是一套被反覆使用的、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問,設計模式於己於他人於系統都是多贏的,設計模式使代碼編制真正工程化,設計模式是軟件工程的基石,如同大廈的一塊塊磚石同樣。項目中合理地運用設計模式能夠完美地解決不少問題,每種模式在現實中都有相應的原理來與之對應,每種模式都描述了一個在咱們周圍不斷重複發生的問題,以及該問題的核心解決方案,這也是設計模式能被普遍應用的緣由。java
該篇文章主要寫的是(介紹沒有順序)設計模式
意圖:將一個類的接口轉換成客戶但願的另一個接口。適配器模式使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做。安全
主要解決:主要解決在軟件系統中,經常要將一些"現存的對象"放到新的環境中,而新環境要求的接口是現對象不能知足的。ide
官方給出:this
優勢: 一、可讓任何兩個沒有關聯的類一塊兒運行。 二、提升了類的複用。 三、增長了類的透明度。 四、靈活性好。設計
缺點: 一、過多地使用適配器,會讓系統很是零亂,不易總體進行把握。好比,明明看到調用的是 A 接口,其實內部被適配成了 B 接口的實現,一個系統若是太多出現這種狀況,無異於一場災難。所以若是不是頗有必要,能夠不使用適配器,而是直接對系統進行重構。 2.因爲 JAVA 至多繼承一個類,因此至多隻能適配一個適配者類,並且目標類必須是抽象類。代理
示例:這裏我簡單寫一個關於兩個接口的例子,來調用裏面的方法來看看效果這兩個接口咱們能夠理解成充電器,一個是蘋果lighting口,一個安卓充電器,咱們都知道這兩個充電器接口是不同的,可是淘寶上有賣轉換頭的,能夠在蘋果頭上套一個轉換器就能夠衝安卓手機裏,這中間的轉換頭就是咱們所說的適配器,我再配張圖(中間一頭是方形一頭是圓形就是適配器)htm
好,廢話很少說,開始對象
(1)首先寫一個A蘋果接口,一個B安卓接口而後實現該接口裏的方法,開始工做
//實現A class PowerA { public void workA(){} } class PowerAiml extends PowerA{ public void workA(){ System.out.println("我是A,我要開始工做了"); } } //實現B class PowerB { public void workB(){} } class PowerBiml extends PowerB{ public void workB(){ System.out.println("我是B,我要開始工做了"); } }
(2)寫一個方法只有A(蘋果)接口能夠用。
public static void work(PowerA a){ System.out.println("開始-------"); a.workA(); System.out.println("結束-------"); }
(3)調用查看效果
PowerA pa=new PowerAiml(); work(pa);
這樣使用是沒有任何問題的,由於參數就是PowerA a,只要是傳入實現PowerA接口的class均可以調用該方法,可是,問題來了,若是我想讓使用PowerB怎麼辦呢,有兩個方法,一個是再寫一個work2(PowerB b),另外一個是用適配器的方法,顯然第一種方法對於這個例子是最簡單的,可是在一個軟件編寫的過程當中不光是這一點代碼,代碼有不少,難道都要再寫方法嗎,那樣子就太麻煩了,如今就用適配器的方法
(4)適配器
想要使用A方法,就要假裝成A,把適配器實現PowerA
//適配器: class Adapter1 extends PowerA{ public PowerB b; public Adapter1(PowerB b){ this.b=b; } //當調用A的時候,就自動調用B裏的方法。 public void workA(){ b.workB(); } }
調用的時候是,一頭與B關聯,一頭與A關聯
PowerB b=new PowerBiml(); Adapter1 adapter=new Adapter1(b); work(adapter);
解釋一下:在Adapter1中傳入的b,而後把adapter傳入work,雖然調用的都是workA,可是關鍵來了,在workA方法中又調用了b.workB();就是這麼一個思路。
這是一個很是簡單的例子,在開發過程當中,真正要用到適配器要比這個看似複雜點,原理都是同樣的,畢竟小孩子的性格是天真的,大人的性格就變化莫測了。
意圖:爲其餘對象提供一種代理以控制對這個對象的訪問。
主要解決:在直接訪問對象時帶來的問題,好比說:要訪問的對象在遠程的機器上。在面向對象系統中,有些對象因爲某些緣由(好比對象建立開銷很大,或者某些操做須要安全控制,或者須要進程外的訪問),直接訪問會給使用者或者系統結構帶來不少麻煩,咱們能夠在訪問此對象時加上一個對此對象的訪問層。
什麼時候使用:想在訪問一個類時作一些控制。
如何解決:增長中間層。
靜態代理模式,說白了就是委託,將全部的事情都委託給別人幫你完成,你所要作的,就是給代理一些東西,接下來全部的事情都是代理幫你完成,你徹底不用去關心內部是如何實現的。舉個例子簡單的說一下,一我的買衣服,能夠去實體店也能夠去網上,買火車票的時候,你就知道售票員就會給你 你想要的票,並且你只須要給他錢和身份證以及地點就能夠了,他會通過處理,最後把票給你,他就處於一個代理模式。下面我簡單寫一個例子
好比說我只想要水,我就給你送水的公司打電話讓他們送一桶水,而後我就在家等着就能夠,在這期間誰送水,怎麼送,須要多久,什麼樣的水等一切我都不須要知道,這都被送水公司代理了。OK
(1)先寫一個要水的類和接口
class Action{ public void work(){} } class MyAction extends Action{ public void work(){ //在這期間可能會有我不想作的事,但仍是要有,好比說一共耗時,打水結果要的是水,但必須要拿水桶等。 //這些東西都是可讓代理給作了, System.out.println("得到水"); } }
(2)寫代理類
若是不寫代理類的話,也能夠直接調用work方法,可是就至關於本身去搬水,而不是用代理。
/** * 代理類 * 控制,在方法前或後所要作的類。 * */ class DaiLiAction extends Action{ private Action action; public DaiLiAction(Action action){ this.action=action; } public void work(){ System.out.println("我是送水公司"); System.out.println("代理正在處理中。。。"); System.out.println("代理處理完了返回給你結果"); action.work(); } }
(3)調用便可
Action ac=new MyAction(); //把對象給代理類,工做是由代理完成。 DaiLiAction dai=new DaiLiAction(ac); dai.work();
http://www.cnblogs.com/cmusketeer/p/8016550.html
意圖:定義一個建立對象的接口,讓其子類本身決定實例化哪個工廠類,工廠模式使其建立過程延遲到子類進行。
主要解決:主要解決接口選擇的問題。
什麼時候使用:咱們明確地計劃不一樣條件下建立不一樣實例時。
如何解決:讓其子類實現工廠接口,返回的也是一個抽象的產品。
/** * 工廠接口 * */ interface Factory1{ public void create(); } /** * 手機 * */ class Phone implements Factory1{ @Override public void create() { System.out.println("我是造--手機--的"); } } /** * 電腦 * */ class Computer implements Factory1{ @Override public void create() { System.out.println("我是造--電腦--的"); } }
(2)建立工廠控制類FactoryControl
/** * 工廠控制類 * */ class FactoryControl{ public static Factory1 getGood(String good){ if(good.equalsIgnoreCase("phone")){ return new Phone(); }else if(good.equalsIgnoreCase("computer")){ return new Computer(); } return null; } }
(3)調用和效果
Factory1 factory=FactoryControl.getGood("phone"); factory.create(); factory=FactoryControl.getGood("computer"); factory.create();
固然,也能夠不通過FactoryControl(工廠類),也是能夠調用的,可是若是是大工程,使用該模式能夠下降使用者和被使用者之間的依賴。這裏就算你傳入一個耳機,沒有這個功能,它也不會報錯,返回null。
好了,下一篇就會繼續寫剩下的19個設計模式,例子都是簡單易懂的,只要理解了,慢慢的再寫複雜的代碼就輕鬆了,只要有了思想,寫代碼就簡單了,能夠告別有能力但總以爲無處施展的尷尬。