1. 程式人生 > >裝飾器模式(講解+應用)

裝飾器模式(講解+應用)

目錄

  1. 裝飾器模式

  2. 為什麼使用裝飾器模式

  3. 應用例項

裝飾器模式

看到裝飾器是在看《Thinking in Java》一書的時候,看到檔案讀寫那邊的時候,有提到裝飾器模式,同時在檔案讀寫的那一部分,對於各種讀入,寫出的方式,程式碼組織結構感覺也是比較怪的,怪的總是吸引人的。

裝飾器模式:在不必改變原類檔案和使用繼承的情況下,動態地擴充套件一個物件的功能。它是通過建立一個包裝物件,也就是裝飾來包裹真實的物件。

通過使用裝飾器模式,我們可以實現關閉原有程式碼,開放現有程式碼的方式來實現更多的功能。通過減少對原有程式碼的改變,來降低犯錯誤的機率。不改變妹子的三圍,通過裝飾不同的制服,實現一個動態擴充套件,我們就會看到教師,護士,,,其本質功能還是未改變的,只是體驗更上一層樓。。。

為什麼使用裝飾器模式

繼續上面的需求來舉例子吧,現在我們要針對該服務場所制定一個訂單系統,當客戶來選擇的時候,點一項服務,我們需要向訂單中加入一項,然後最後計算一個總和,由於young woman,student,nurse等基礎價格是不同的,假設在其基礎之上的單項服務價格是相同的,首先我們想到的可能是根據不同的型別繼承自一個基類,建立一個類,然後每個作為一個例項,將各項服務作為一個全域性變數,然後各項服務有一個set方法,用來改變這些服務的狀態,兩次呼叫可以取消該服務,預設各項服務的狀態是關閉的,然後最後通過一個cost方法判斷各種服務的來計算總價格,當然感覺這是一個很不錯的方法。但是由於某種服務的特殊性原因,能提供該服務的人減少,所以該服務價格上漲,或者是在某種服務在一個不小心中誕生,因此,我們需要開啟原始碼進行新增一些服務,然後需要新增set方法,同時,我們需要對cost進行修改,隨著人民思路不斷開闊,冒險精神日益增強,各種服務如雨後春筍,我們的維護工作將變得比工作人員還要辛苦了。這個時候,就要引出我們的裝飾器模式,我們將所有需要付費的拿出來,因為我們在後期的維護上,就是價格導致的變化給我們帶來了困擾,所以如果將這些變化的價格拿出來,單獨維護,我們的工作量將會減少。如下結構

//基礎抽象類
public abstract class SexService{
    String description = "Best Service";
    public String getDescription(){
        return description;
    }
    public abstract int cost();
} 
//繼承自抽象類的本體
public class Nurse extends SexService{
    public Nurse(){
        description = "You konw";
    }
    public
int cost()
{ return 150; } } //繼承自基礎類的用來修飾本體的類 public class PlayXiao extends SexService{ SexService service; public PlayXiao(SexService service){ this.service = service; } public String getDescription(){ return service.getDescription+"PlayXiao"; } public int cost(){ return service.cost+50; } }

呼叫方式

Nurse sweetHeart = new Nurse();
sweetHeart = new PlayXiao(sweetHeart);

首先我們建立一個本體類,然後將其作為一個例項通過建構函式注入到一個裝飾類,在裝飾類內部通過委託的形式獲得當前的價格和描述,同時由於本體類和裝飾類繼承自同一個基類,所以可以用來繼續向下傳遞。
基礎抽象類,通過建構函式進行例項注入,通過委託實現狀態,資料更新,從而實現關閉原有程式碼,開放現有程式碼。

應用例項

言歸正傳,回到正題上來,講一下其在我們平常開發中的例子
開始也提到了一點關於Java,io庫的問題
java I/O庫具有兩個對稱性,它們分別是:

  1. 輸入-輸出對稱:比如InputStream 和OutputStream 各自佔據Byte流的輸入和輸出的兩個平行的等級結構的根部;而Reader和Writer各自佔據Char流的輸入和輸出的兩個平行的等級結構的根部。

  2. byte-char對稱:InputStream和Reader的子類分別負責byte和Char流的輸入;OutputStream和Writer的子類分別負責byte和Char流的輸出

這些作為根類,如果我們想通過緩衝,位元組,或者是管道,這個時候我們就需要使用裝飾器來進行裝飾,然後通過裝飾器來實現相應的操作,根類具有read方法,對於裝飾類,通過建構函式將基類的一個例項注入進去,然後通過委託模式,首先通過基類的read方法獲取位元組流,然後根據相應的操作,實現位元組讀取等。

InputStreamReader input = new InputStreamReader(System.in);
BufferedReader reader = new BufferedReader(input);
String line = reader.readLine();

相關推薦

裝飾模式講解+應用

目錄裝飾器模式為什麼使用裝飾器模式應用例項裝飾器模式看到裝飾器是在看《Thinking in Java》一書的時候,看到檔案讀寫那邊的時候,有提到裝飾器模式,同時在檔案讀寫的那一部分,對於各種讀入,寫出的方式,程式碼組織結構感覺也是比較怪的,怪的總是吸引人的。裝飾器模式:在不

設計模式 —— 裝飾模式Decorator Pattern

trac 價格 div desc number one 添加 imp esc 裝飾器模式(Decorator Pattern) 概念 裝飾器模式 允許向一個現有的對象添加新的功能,同時又不改變其結構。裝飾者可以在所委托被裝飾者的行為之前或之後加上自己的行為,以達到特定

重走Java設計模式——裝飾模式Decorator Pattern

裝飾器模式 定義 裝飾器模式(Decorator Pattern)允許向一個現有的物件新增新的功能,同時又不改變其結構。這種型別的設計模式屬於結構型模式,它是作為現有的類的一個包裝。 這種模式建立了一個裝飾類,用來包裝原有的類,並在保持類方法簽名完整性的前提下,提供了額外

裝飾模式Decorator Pattern:簡單&粗暴解析

1.前言 在之前的文章設計模式(Design pattern):簡單&粗暴解析中已經為大家深入淺出解析了 設計模式 的 七大原則、三大型別。 本文為大家解析三大型別中 結構型 裡其中的 裝飾器模式。 文章中例項 linhaojian的Github

設計模式裝飾模式java實現

裝飾器模式(Decorator):結構型設計模式,為了實現類在不修改原始類的基礎上進行動態的覆蓋或者增加方法,該實現保持了跟原有類的層級關係。這種設計模式允許向一個現有的物件新增新的功能,同時又不改變其結構。算是一種非常特殊的介面卡模式。 在實際業務中,有時候我們會建立了多層子類,但如果當子

裝飾模式Decorator Pattern:簡單&粗暴解析

1.前言 2.目錄 3.含義 為一個現有物件新增額外的功能。就增加物件功能來說,裝飾模式比生成子類實現更為靈活。 4.解決 1.在一個類在擴充套件功能時,如果通過繼承的方式擴充套件,隨著功能增加越來越多時,就會導致子類爆炸。 5.原理 通

設計模式裝飾模式decorator pattern

裝飾器模式主要對現有的類物件進行包裹和封裝,以期望在不改變類物件及其類定義的情況下,為物件新增額外功能。是一種物件結構型模式。需要注意的是,該過程是通過呼叫被包裹之後的物件完成功能新增的,而不是直接修改現有物件的行為,相當於增加了中間層。類似於python中的@裝飾器。 下面還是按照老規矩,先來了解一下該模

結構型模式————裝飾模式3.1

什麼是裝飾器模式? 【先吃三顆栗子:】 1.PC=主機+顯示器+鍵盤+滑鼠+滑鼠墊 主機是核心,而其他的組成部分都是裝飾。 2.手抓餅=餅+雞蛋+培根+黃瓜 餅是核心,雞蛋,培根是可選的,可以理解為裝飾。 3.咖啡=咖啡+牛奶+冰+方糖 咖啡是核心,牛奶等可選。 比喻雖然形象生動,但是與實際或多或少

C#設計模式-裝飾模式Decorator Pattern

引言 當我們完成一個軟體產品開發後就需要對其進行各種測試,適配快速迭代下質量的保障。當有一個完善的產品的物件後,如果我們想要給他新增一個測試功能,那麼我們可以用一個新的類去裝飾它來實現對原有物件職責的擴充套件。新的類稱為“裝飾者”,原有的物件稱為“被裝飾者”。這

設計模式- 結構型模式裝飾模式5

bject 語法 函數 IT 裝飾 gof body 能夠 color 無論何時我們想對一個對象添加額外的功能,都有下面這些不同的可選方法。? 如果合理,可以直接將功能添加到對象所屬的類(例如,添加一個新的方法)? 使用組合? 使用繼承與繼承相比,通常應該優先選擇組合,因為

Decorator裝飾模式C++

簡而言之,它提供了一種對被裝飾者透明的方法; 例如:一篇文章本身無需知道自己的頁首和頁尾;使用者可以很方便的新增不同的頁首與頁尾 對比Strategy模式:物件需要知道使用的是哪個演算法,該方式對元件不可見,但是呼叫者可以任意數量新增裝飾。 不足:每次裝飾都會引入一個新

javascript設計模式裝飾模式結構型模式

javascript設計模式之裝飾器模式 js的設計模式分為建立型模式,結構型模式和行為模式 結構模式描述瞭如何組合物件以提供新的功能。 裝飾器模式是一種常見的結構型模式,我們可以以一個基礎物件為基礎,來給它加上若干個裝飾物件以拓展其功能。 下面是示

裝飾模式Decorator

裝飾器模式 動態地給物件新增行為(職責) 假設我們要裝飾 Text這個類: class Text(val text: String) { fun draw(){

不一樣的裝飾模式設計模式

前言 我是一名部落格園的博主,目前排名第199675位,雖然排名稍稍落後,但這並不影響我向大家學習然後自己吹水。 在常見的設計模式中,每個專案或者說產品可以說裝飾器幾乎必用。 裝飾器是decorator,別名wrapper,也稱為包裝器,是建立型、結構型、行為型分類的結構型,具體有什麼用呢? 說有什麼用,不如

PHP設計模式裝飾模式Decorator

# PHP設計模式之裝飾器模式(Decorator) # 裝飾器模式 > 裝飾器模式允許我們給一個類新增新的功能,而不改變其原有的結構。這種型別的類屬於結構類,它是作為現有的類的一個包裝 # 裝飾器模式的應用場景 當我們要畫一個圓形時候,我們建立一個圓形類,正方形又建立一個類,橢圓、長方形。。。。,而

7,裝飾模式Decorator Pattern動態的給一個對象添加一些額外的職責。就增加功能來說,此模式比生成子類更為靈活。繼承關系的一個替換方案。

做到 活性 splay .com 重新 裝飾 run play 情況 裝飾( Decorator )模式又叫做包裝模式。通過一種對客戶端透明的方式來擴展對象的功能,是繼承關系的一個替換方案。 裝飾模式就是把要添加的附加功能分別放在單獨的類中,並讓這個

C#設計模式之二十三解釋模式Interpreter Pattern【行為型】

要求 ict string 技術 get protect dict site 關鍵字 原文:C#設計模式之二十三解釋器模式(Interpreter Pattern)【行為型】一、引言 今天我們開始講“行為型”設計模式的第十一個模式,也是面向對象設計模式的最後一個模式,先

設計模式-14裝飾模式 swift版

實現 info 有一個 istview listview 接口 tor true lis 一,概念   裝飾者模式(Decorator):動態地為一個對象添加一些額外的職責,若要擴展一個對象的功能,裝飾者提供了比繼承更有彈性的替代方案。   多組合,少繼承 二,UML圖

C#設計模式(9)——裝飾模式Decorator Pattern

pre 現在 接受 () spa 對象 如何 缺點 重寫 一、引言 在軟件開發中,我們經常想要對一類對象添加不同的功能,例如要給手機添加貼膜,手機掛件,手機外殼等,如果此時利用繼承來實現的話,就需要定義無數的類,如StickerPhone(貼膜是手機類)、Accessori

重走Java設計模式——迭代模式Iterator Pattern

迭代器模式 定義 提供一種方法順序訪問一個聚合物件中各個元素, 而又無須暴露該物件的內部表示。 模式結構 1.抽象容器:一般是一個介面,提供一個iterator()方法,例如java中的Collection介面,List介面,Set介面等。 2.具體