java基礎總結(三十三)--二十三種設計模式
來自:https://www.cnblogs.com/geek6/p/3951677.html
一、設計模式的分類
總體來說設計模式分為三大類:
建立型模式,共五種:工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式,共七種:介面卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式,共十一種:策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。
其實還有兩類:併發型模式和執行緒池模式。用一個圖片來整體描述一下:
二、設計模式的六大原則
總原則:開閉原則(Open Close Principle)
開閉原則就是說對擴充套件開放,對修改關閉。在程式需要進行拓展的時候,不能去修改原有的程式碼,而是要擴充套件原有程式碼,實現一個熱插拔的效果。所以一句話概括就是:為了使程式的擴充套件性好,易於維護和升級。想要達到這樣的效果,我們需要使用介面和抽象類等,後面的具體設計中我們會提到這點。
1、單一職責原則
不要存在多於一個導致類變更的原因,也就是說每個類應該實現單一的職責,如若不然,就應該把類拆分。
2、里氏替換原則(Liskov Substitution Principle)
里氏代換原則(Liskov Substitution Principle LSP)面向物件設計的基本原則之一。 里氏代換原則中說,任何基類可以出現的地方,子類一定可以出現。 LSP是繼承複用的基石,只有當衍生類可以替換掉基類,軟體單位的功能不受到影響時,基類才能真正被複用,而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現,所以里氏代換原則是對實現抽象化的具體步驟的規範。—— From Baidu 百科
歷史替換原則中,子類對父類的方法儘量不要重寫和過載。因為父類代表了定義好的結構,通過這個規範的介面與外界互動,子類不應該隨便破壞它。
3、依賴倒轉原則(Dependence Inversion Principle)
這個是開閉原則的基礎,具體內容:面向介面程式設計,依賴於抽象而不依賴於具體。寫程式碼時用到具體類時,不與具體類互動,而與具體類的上層介面互動。
4、介面隔離原則(Interface Segregation Principle)
這個原則的意思是:每個介面中不存在子類用不到卻必須實現的方法,如果不然,就要將介面拆分。使用多個隔離的介面,比使用單個介面(多個介面方法集合到一個的介面)要好。
5、迪米特法則(最少知道原則)(Demeter Principle)
就是說:一個類對自己依賴的類知道的越少越好。也就是說無論被依賴的類多麼複雜,都應該將邏輯封裝在方法的內部,通過public方法提供給外部。這樣當被依賴的類變化時,才能最小的影響該類。
最少知道原則的另一個表達方式是:只與直接的朋友通訊。類之間只要有耦合關係,就叫朋友關係。耦合分為依賴、關聯、聚合、組合等。我們稱出現為成員變數、方法引數、方法返回值中的類為直接朋友。區域性變數、臨時變數則不是直接的朋友。我們要求陌生的類不要作為區域性變量出現在類中。
6、合成複用原則(Composite Reuse Principle)
原則是儘量首先使用合成/聚合的方式,而不是使用繼承。
三、Java的23中設計模式
A、建立模式
從這一塊開始,我們詳細介紹Java中23種設計模式的概念,應用場景等情況,並結合他們的特點及設計模式的原則進行分析。
首先,簡單工廠模式不屬於23中涉及模式,簡單工廠一般分為:普通簡單工廠、多方法簡單工廠、靜態方法簡單工廠。
0、簡單工廠模式
簡單工廠模式模式分為三種:
就是建立一個工廠類,對實現了同一介面的一些類進行例項的建立。首先看下關係圖:
舉例如下:(我們舉一個傳送郵件和簡訊的例子)
首先,建立二者的共同介面:
[java] view plaincopy
- public interface Sender {
- public void Send();
- }
其次,建立實現類:
[java] view plaincopy
- public class MailSender implements Sender {
- @Override
- public void Send() {
- System.out.println("this is mailsender!");
- }
- }
[java] view plaincopy
- public class SmsSender implements Sender {
- @Override
- public void Send() {
- System.out.println("this is sms sender!");
- }
- }
最後,建工廠類:
[java] view plaincopy
- public class SendFactory {
- public Sender produce(String type) {
- if ("mail".equals(type)) {
- return new MailSender();
- } else if ("sms".equals(type)) {
- return new SmsSender();
- } else {
- System.out.println("請輸入正確的型別!");
- return null;
- }
- }
- }
我們來測試下:
- public class FactoryTest {
- public static void main(String[] args) {
- SendFactory factory = new SendFactory();
- Sender sender = factory.produce("sms");
- sender.Send();
- }
- }
輸出:this is sms sender!
是對普通工廠方法模式的改進,在普通工廠方法模式中,如果傳遞的字串出錯,則不能正確建立物件,而多個工廠方法模式是提供多個工廠方法,分別建立物件。關係圖:
將上面的程式碼做下修改,改動下SendFactory類就行,如下:
[java] view plaincopypublic class SendFactory {
public Sender produceMail(){
- return new MailSender();
- }
- public Sender produceSms(){
- return new SmsSender();
- }
- }
測試類如下:
[java] view plaincopy
- public class FactoryTest {
- public static void main(String[] args) {
- SendFactory factory = new SendFactory();
- Sender sender = factory.produceMail();
- sender.Send();
- }
- }
輸出:this is mailsender!
將上面的多個工廠方法模式裡的方法置為靜態的,不需要建立例項,直接呼叫即可。
[java] view plaincopy
- public class SendFactory {
- public static Sender produceMail(){
- return new MailSender();
- }
- public static Sender produceSms(){
- return new SmsSender();
- }
- }
[java] view plaincopy
- public class FactoryTest {
- public static void main(String[] args) {
- Sender sender = SendFactory.produceMail();
- sender.Send();
- }
- }
輸出:this is mailsender!
總體來說,工廠模式適合:凡是出現了大量的產品需要建立,並且具有共同的介面時,可以通過工廠方法模式進行建立。在以上的三種模式中,第一種如果傳入的字串有誤,不能正確建立物件,第三種相對於第二種,不需要例項化工廠類,所以,大多數情況下,我們會選用第三種——靜態工廠方法模式。
1、工廠方法模式(Factory Method)
簡單工廠模式有一個問題就是,類的建立依賴工廠類,也就是說,如果想要拓展程式,必須對工廠類進行修改,這違背了閉包原則,所以,從設計角度考慮,有一定的問題,如何解決?就用到工廠方法模式,建立一個工廠介面和建立多個工廠實現類,這樣一旦需要增加新的功能,直接增加新的工廠類就可以了,不需要修改之前的程式碼。
請看例子:
[java] view plaincopy
- public interface Sender {
- public void Send();
- }
兩個實現類:
[java] view plaincopy
- public class MailSender implements Sender {
- @Override
- public void Send() {
- System.out.println("this is mailsender!");
- }
- }
[java] view plaincopy
- public class SmsSender implements Sender {
- @Override
- public void Send() {
- System.out.println("this is sms sender!");
- }
- }
兩個工廠類:
[java] view plaincopy
- public class SendMailFactory implements Provider {
- @Override
- public Sender produce(){
- return new MailSender();
- }
- }
[java] view plaincopy
- public class SendSmsFactory implements Provider{
- @Override
- public Sender produce() {
- return new SmsSender();
- }
- }
在提供一個介面:
[java] view plaincopy
- public interface Provider {
- public Sender produce();
- }
測試類:
[java] view plaincopy
- public class Test {
- public static void main(String[] args) {
- Provider provider = new SendMailFactory();
- Sender sender = provider.produce();
- sender.Send();
- }
- }
其實這個模式的好處就是,如果你現在想增加一個功能:發及時資訊,則只需做一個實現類,實現Sender介面,同時做一個工廠類,實現Provider介面,就OK了,無需去改動現成的程式碼。這樣做,拓展性較好!
2、抽象工廠模式
工廠方法模式和抽象工廠模式不好分清楚,他們的區別如下:
工廠方法模式: 一個抽象產品類,可以派生出多個具體產品類。 一個抽象工廠類,可以派生出多個具體工廠類。 每個具體工廠類只能建立一個具體產品類的例項。 抽象工廠模式: 多個抽象產品類,每個抽象產品類可以派生出多個具體產品類。 一個抽象工廠類,可以派生出多個具體工廠類。 每個具體工廠類可以建立多個具體產品類的例項,也就是建立的是一個產品線下的多個產品。 區別: 工廠方法模式只有一個抽象產品類,而抽象工廠模式有多個。 工廠方法模式的具體工廠類只能建立一個具體產品類的例項,而抽象工廠模式可以建立多個。
工廠方法建立 "一種" 產品,他的著重點在於"怎麼建立",也就是說如果你開發,你的大量程式碼很可能圍繞著這種產品的構造,初始化這些細節上面。也因為如此,類似的產品之間有很多可以複用的特徵,所以會和模版方法相隨。 抽象工廠需要建立一些列產品,著重點在於"建立哪些"產品上,也就是說,如果你開發,你的主要任務是劃分不同差異的產品線,並且儘量保持每條產品線介面一致,從而可以從同一個抽象工廠繼承。
對於java來說,你能見到的大部分抽象工廠模式都是這樣的: ---它的裡面是一堆工廠方法,每個工廠方法返回某種型別的物件。 比如說工廠可以生產滑鼠和鍵盤。那麼抽象工廠的實現類(它的某個具體子類)的物件都可以生產滑鼠和鍵盤,但可能工廠A生產的是羅技的鍵盤和滑鼠,工廠B是微軟的。 這樣A和B就是工廠,對應於抽象工廠; 每個工廠生產的滑鼠和鍵盤就是產品,對應於工廠方法; 用了工廠方法模式,你替換生成鍵盤的工廠方法,就可以把鍵盤從羅技換到微軟。但是用了抽象工廠模式,你只要換家工廠,就可以同時替換滑鼠和鍵盤一套。如果你要的產品有幾十個,當然用抽象工廠模式一次替換全部最方便(這個工廠會替你用相應的工廠方法) 所以說抽象工廠就像工廠,而工廠方法則像是工廠的一種產品生產線
3、單例模式(Singleton)
單例物件(Singleton)是一種常用的設計模式。在Java應用中,單例物件能保證在一個JVM中,該物件只有一個例項存在。這樣的模式有幾個好處:
1、某些類建立比較頻繁,對於一些大型的物件,這是一筆很大的系統開銷。
2、省去了new操作符,降低了系統記憶體的使用頻率,減輕GC壓力。
3、有些類如交易所的核心交易引擎,控制著交易流程,如果該類可以建立多個的話,系統完全亂了。(比如一個軍隊出現了多個司令員同時指揮,肯定會亂成一團),所以只有使用單例模式,才能保證核心交易伺服器獨立控制整個流程。
首先我們寫一個簡單的單例類:
[java] view plaincopy
- public class Singleton {
- /* 持有私有靜態例項,防止被引用,此處賦值為null,目的是實現延遲載入 */
- private static Singleton instance = null;
- /* 私有構造方法,防止被例項化 */
- private Singleton() {
- }
- /* 靜態工程方法,建立例項 */
- public static Singleton getInstance() {
- if (instance == null) {
- instance = new Singleton();
- }
- return instance;
- }
- /* 如果該物件被用於序列化,可以保證物件在序列化前後保持一致 */
- public Object readResolve() {
- return instance;
- }
- }
這個類可以滿足基本要求,但是,像這樣毫無執行緒安全保護的類,如果我們把它放入多執行緒的環境下,肯定就會出現問題了,如何解決?我們首先會想到對getInstance方法加synchronized關鍵字,如下:
[java] view plaincopy
- public static synchronized Singleton getInstance() {
- if (instance == null) {
- instance = new Singleton();
- }
- return instance;
- }
但是,synchronized關鍵字鎖住的是這個物件,這樣的用法,在效能上會有所下降,因為每次呼叫getInstance(),都要對物件上鎖,事實上,只有在第一次建立物件的時候需要加鎖,之後就不需要了,所以,這個地方需要改進。我們改成下面這個:
[java] view plaincopy
- public static Singleton getInstance() {
- if (instance == null) {
- synchronized (instance) {
- if (instance == null) {
- instance = new Singleton();
- }
- }
- }
- return instance;
- }
似乎解決了之前提到的問題,將synchronized關鍵字加在了內部,也就是說當呼叫的時候是不需要加鎖的,只有在instance為null,並建立物件的時候才需要加鎖,效能有一定的提升。但是,這樣的情況,還是有可能有問題的,看下面的情況:在Java指令中建立物件和賦值操作是分開進行的,也就是說instance = new Singleton();語句是分兩步執行的。但是JVM並不保證這兩個操作的先後順序,也就是說有可能JVM會為新的Singleton例項分配空間,然後直接賦值給instance成員,然後再去初始化這個Singleton例項。這樣就可能出錯了,我們以A、B兩個執行緒為例:
a>A、B執行緒同時進入了第一個if判斷
b>A首先進入synchronized塊,由於instance為null,所以它執行instance = new Singleton();
c>由於JVM內部的優化機制,JVM先畫出了一些分配給Singleton例項的空白記憶體,並賦值給instance成員(注意此時JVM沒有開始初始化這個例項),然後A離開了synchronized塊。
d>B進入synchronized塊,由於instance此時不是null,因此它馬上離開了synchronized塊並將結果返回給呼叫該方法的程式。
e>此時B執行緒打算使用Singleton例項,卻發現它沒有被初始化,於是錯誤發生了。
所以程式還是有可能發生錯誤,其實程式在執行過程是很複雜的,從這點我們就可以看出,尤其是在寫多執行緒環境下的程式更有難度,有挑戰性。我們對該程式做進一步優化:
[java] view plaincopy
- private static class SingletonFactory{
- private static Singleton instance = new Singleton();
- }
- public static Singleton getInstance(){
- return SingletonFactory.instance;
- }
實際情況是,單例模式使用內部類來維護單例的實現,JVM內部的機制能夠保證當一個類被載入的時候,這個類的載入過程是執行緒互斥的。這樣當我們第一次呼叫getInstance的時候,JVM能夠幫我們保證instance只被建立一次,並且會保證把賦值給instance的記憶體初始化完畢,這樣我們就不用擔心上面的問題。同時該方法也只會在第一次呼叫的時候使用互斥機制,這樣就解決了低效能問題。這樣我們暫時總結一個完美的單例模式:
[java] view plaincopy
- public class Singleton {
- /* 私有構造方法,防止被例項化 */
- private Singleton() {
- }
- /* 此處使用一個內部類來維護單例 */
- private static class SingletonFactory {
- private static Singleton instance = new Singleton();
- }
- /* 獲取例項 */
- public static Singleton getInstance() {
- return SingletonFactory.instance;
- }
- /* 如果該物件被用於序列化,可以保證物件在序列化前後保持一致 */
- public Object readResolve() {
- return getInstance();
- }
- }
其實說它完美,也不一定,如果在建構函式中丟擲異常,例項將永遠得不到建立,也會出錯。所以說,十分完美的東西是沒有的,我們只能根據實際情況,選擇最適合自己應用場景的實現方法。也有人這樣實現:因為我們只需要在建立類的時候進行同步,所以只要將建立和getInstance()分開,單獨為建立加synchronized關鍵字,也是可以的:
[java] view plaincopy
- public class SingletonTest {
- private static SingletonTest instance = null;
- private SingletonTest() {
- }
- private static synchronized void syncInit() {
- if (instance == null) {
- instance = new SingletonTest();
- }
- }
- public static SingletonTest getInstance() {
- if (instance == null) {
- syncInit();
- }
- return instance;
- }
- }
考慮效能的話,整個程式只需建立一次例項,所以效能也不會有什麼影響。
補充:採用"影子例項"的辦法為單例物件的屬性同步更新
[java] view plaincopy
- public class SingletonTest {
- private static SingletonTest instance = null;
- private Vector properties = null;
- public Vector getProperties() {
- return properties;
- }
- private SingletonTest() {
- }
- private static synchronized void syncInit() {
- if (instance == null) {
- instance = new SingletonTest();
- }
- }
- public static SingletonTest getInstance() {
- if (instance == null) {
- syncInit();
- }
- return instance;
- }
- public void updateProperties() {
- SingletonTest shadow = new SingletonTest();
- properties = shadow.getProperties();
- }
- }
通過單例模式的學習告訴我們:
1、單例模式理解起來簡單,但是具體實現起來還是有一定的難度。
2、synchronized關鍵字鎖定的是物件,在用的時候,一定要在恰當的地方使用(注意需要使用鎖的物件和過程,可能有的時候並不是整個物件及整個過程都需要鎖)。
到這兒,單例模式基本已經講完了,結尾處,筆者突然想到另一個問題,就是採用類的靜態方法,實現單例模式的效果,也是可行的,此處二者有什麼不同?
首先,靜態類不能實現介面。(從類的角度說是可以的,但是那樣就破壞了靜態了。因為介面中不允許有static修飾的方法,所以即使實現了也是非靜態的)
其次,單例可以被延遲初始化,靜態類一般在第一次載入是初始化。之所以延遲載入,是因為有些類比較龐大,所以延遲載入有助於提升效能。
再次,單例類可以被繼承,他的方法可以被覆寫。但是靜態類內部方法都是static,無法被覆寫。
最後一點,單例類比較靈活,畢竟從實現上只是一個普通的Java類,只要滿足單例的基本需求,你可以在裡面隨心所欲的實現一些其它功能,但是靜態類不行。從上面這些概括中,基本可以看出二者的區別,但是,從另一方面講,我們上面最後實現的那個單例模式,內部就是用一個靜態類來實現的,所以,二者有很大的關聯,只是我們考慮問題的層面不同罷了。兩種思想的結合,才能造就出完美的解決方案,就像HashMap採用陣列+連結串列來實現一樣,其實生活中很多事情都是這樣,單用不同的方法來處理問題,總是有優點也有缺點,最完美的方法是,結合各個方法的優點,才能最好的解決問題!
4、建造者模式(Builder)
5、原型模式(Prototype)
原型模式雖然是建立型的模式,但是與工程模式沒有關係,從名字即可看出,該模式的思想就是將一個物件作為原型,對其進行復制、克隆,產生一個和原物件類似的新物件。本小結會通過物件的複製,進行講解。在Java中,複製物件是通過clone()實現的,先建立一個原型類:
[java] view plaincopy
- public class Prototype implements Cloneable {
- public Object clone() throws CloneNotSupportedException {
- Prototype proto = (Prototype) super.clone();
- return proto;
- }
- }
很簡單,一個原型類,只需要實現Cloneable介面,覆寫clone方法,此處clone方法可以改成任意的名稱,因為Cloneable介面是個空介面,你可以任意定義實現類的方法名,如cloneA或者cloneB,因為此處的重點是super.clone()這句話,super.clone()呼叫的是Object的clone()方法,而在Object類中,clone()是native的,具體怎麼實現,我會在另一篇文章中,關於解讀Java中本地方法的呼叫,此處不再深究。在這兒,我將結合物件的淺複製和深複製來說一下,首先需要了解物件深、淺複製的概念:
淺複製:將一個物件複製後,基本資料型別的變數都會重新建立,而引用型別,指向的還是原物件所指向的。
深複製:將一個物件複製後,不論是基本資料型別還有引用型別,都是重新建立的。簡單來說,就是深複製進行了完全徹底的複製,而淺複製不徹底。
此處,寫一個深淺複製的例子:
[java] view plaincopy
- public class Prototype implements Cloneable, Serializable {
- private static final long serialVersionUID = 1L;
- private String string;
- private SerializableObject obj;
- /* 淺複製 */
- public Object clone() throws CloneNotSupportedException {
- Prototype proto = (Prototype) super.clone();
- return proto;
- }
- /* 深複製 */
- public Object deepClone() throws IOException, ClassNotFoundException {
- /* 寫入當前物件的二進位制流 */
- ByteArrayOutputStream bos = new ByteArrayOutputStream();
- ObjectOutputStream oos = new ObjectOutputStream(bos);
- oos.writeObject(this);
- /* 讀出二進位制流產生的新物件 */
- ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
- ObjectInputStream ois = new ObjectInputStream(bis);
- return ois.readObject();
- }
- public String getString() {
- return string;
- }
- public void setString(String string) {
- this.string = string;
- }
- public SerializableObject getObj() {
- return obj;
- }
- public void setObj(SerializableObject obj) {
- this.obj = obj;
- }
- }
- class SerializableObject implements Serializable {
- private static final long serialVersionUID = 1L;
- }
要實現深複製,需要採用流的形式讀入當前物件的二進位制輸入,再寫出二進位制資料對應的物件。
B、結構模式(7種)
我們接著討論設計模式,上篇文章我講完了5種建立型模式,這章開始,我將講下7種結構型模式:介面卡模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。其中物件的介面卡模式是各種模式的起源,我們看下面的圖:
6、介面卡模式
介面卡模式將某個類的介面轉換成客戶端期望的另一個介面表示,目的是消除由於介面不匹配所造成的類的相容性問題。主要分為三類:類的介面卡模式、物件的介面卡模式、介面的介面卡模式。
核心思想就是:有一個Source類,擁有一個方法,待適配,目標介面是Targetable,通過Adapter類,將Source的功能擴充套件到Targetable裡,看程式碼:
[java] view plaincopy
- public class Source {
- public void method1() {
- System.out.println("this is original method!");
- }
- }
[java] view plaincopy
- public interface Targetable {
- /* 與原類中的方法相同 */
- public void method1();
- /* 新類的方法 */
- public void method2();
- }
[java] view plaincopy
- public class Adapter extends Source implements Targetable {
- @Override
- public void method2() {
- System.out.println("this is the targetable method!");
- }
- }
Adapter類繼承Source類,實現Targetable介面,下面是測試類:
[java] view plaincopy
- public class AdapterTest {
- public static void main(String[] args) {
- Targetable target = new Adapter();
- target.method1();
- target.method2();
- }
- }
輸出:
this is original method!
this is the targetable method!
這樣Targetable介面的實現類就具有了Source類的功能。
基本思路和類的介面卡模式相同,只是將Adapter類作修改,這次不繼承Source類,而是持有Source類的例項,以達到解決相容性的問題。看圖:
只需要修改Adapter類的原始碼即可:
[java] view plaincopy
- public class Wrapper implements Targetable {
- private Source source;
- public Wrapper(Source source){
- super();
- this.source = source;
- }
- @Override
- public void method2() {
- System.out.println("this is the targetable method!");
- }
- @Override
- public void method1() {
- source.method1();
- }
- }
測試類:
[java] view plaincopy
- public class AdapterTest {
- public static void main(String[] args) {
- Source source = new Source();
- Targetable target = new Wrapper(source);
- target.method1();
- target.method2();
- }
- }
輸出與第一種一樣,只是適配的方法不同而已。
第三種介面卡模式是介面的介面卡模式,介面的介面卡是這樣的:有時我們寫的一個介面中有多個抽象方法,當我們寫該介面的實現類時,必須實現該介面的所有方法,這明顯有時比較浪費,因為並不是所有的方法都是我們需要的,有時只需要某一些,此處為了解決這個問題,我們引入了介面的介面卡模式,藉助於一個抽象類,該抽象類實現了該介面,實現了所有的方法,而我們不和原始的介面打交道,只和該抽象類取得聯絡,所以我們寫一個類,繼承該抽象類,重寫我們需要的方法就行。看一下類圖:
這個很好理解,在實際開發中,我們也常會遇到這種介面中定義了太多的方法,以致於有時我們在一些實現類中並不是都需要。看程式碼:
[java] view plaincopy
- public interface Sourceable {
- public void method1();
- public void method2();
- }
抽象類Wrapper2:
[java] view plaincopy
- public abstract class Wrapper2 implements Sourceable{
- public void method1(){}
- public void method2(){}
- }
[java] view plaincopy
- public class SourceSub1 extends Wrapper2 {
- public void method1(){
- System.out.println("the sourceable interface's first Sub1!");
- }
- }
[java] view plaincopy
- public class SourceSub2 extends Wrapper2 {
- public void method2(){
- System.out.println("the sourceable interface's second Sub2!");
- }
- }
[java] view plaincopy
- public class WrapperTest {
- public static void main(String[] args) {
- Sourceable source1 = new SourceSub1();
- Sourceable source2 = new SourceSub2();
- source1.method1();
- source1.method2();
- source2.method1();
- source2.method2();
- }
- }
測試輸出:
the sourceable interface's first Sub1!
the sourceable interface's second Sub2!
達到了我們的效果!
講了這麼多,總結一下三種介面卡模式的應用場景:
類的介面卡模式:當希望將一個類轉換成滿足另一個新介面的類時,可以使用類的介面卡模式,建立一個新類,繼承原有的類,實現新的介面即可。
物件的介面卡模式:當希望將一個物件轉換成滿足另一個新介面的物件時,可以建立一個Wrapper類,持有原類的一個例項,在Wrapper類的方法中,呼叫例項的方法就行。
介面的介面卡模式:當不希望實現一個介面中所有的方法時,可以建立一個抽象類Wrapper,實現所有方法,我們寫別的類的時候,繼承抽象類即可。
7、裝飾模式(Decorator)
顧名思義,裝飾模式就是給一個物件增加一些新的功能,而且是動態的,要求裝飾物件和被裝飾物件實