2. 程式人生 > >《Java設計模式》之裝飾模式

《Java設計模式》之裝飾模式

阿新 • • 發佈：2017-06-04
情況 -s 抽象接口 output 就會 ati ack hba ensure

裝飾模式(Decorator)

1. 裝飾模式(Decorator)的定義：又名包裝(Wrapper)模式。裝飾模式以對client透明的方式擴展對象的功能，是繼承關系的一個替代方案。

2. 裝飾模式以對client透明的方式動態的給一個對象附加上很多其它的責任。換言之client並不會覺的對象在裝飾前和裝飾後有什麽差別。

3. 裝飾模式能夠在不創造很多其它的子類的模式下，將對象的功能加以擴展。

4. 裝飾模式與類繼承的差別：

1) 裝飾模式是一種動態行為，對已經存在類進行任意組合，而類的繼承是一種靜態的行為。一個類定義成什麽樣的，該類的對象便具有什麽樣的功能。無法動態的改變。

2) 裝飾模式擴展的是對象的功能。不須要添加類的數量。而類繼承擴展是類的功能。在繼承的關系中，假設我們想添加一個對象的功能。我們僅僅能通過繼承關系，在子類中添加兩個方法。

3) 裝飾與繼承比較圖：

4) 裝飾模式是在不改變原類文件和使用繼承的情況下，動態的擴展一個對象的功能，它是通過創建一個包裝對象。也就是裝飾來包裹真是的對象。

5. 裝飾模式把對client的調用委派給被裝飾的類，裝飾模式的關鍵在於這樣的擴展全然透明的。

6. 裝飾模式的構成：

1) 抽象構建角色(Component):給出一個抽象的接口，以規範準備接受附加責任的對象。

相當於i/o流裏面InputStream/OutputStream

和Reader/Writer。

2) 詳細的構建角色(ConcreteComponent)：定義一個將要接受附加責任的類。

相當於i/o裏面的FileOutputStream和FileInputStream。

3) 裝飾角色(Docorator):持有一個抽象構建(Component)角色的引用。並定義一個與抽象構件一致的接口。

相當於i/o裏面的FilerOutputStream和FilterInputStream。

4) 詳細的裝飾角色(ConcreteDecorator):負責給構建對象“貼上”附加的責任。

相當於i/o流裏面的BufferedOutputStream和BufferedInputStream

以及DataOutputStream和DataInputSrtream。

7. 裝飾模式的特點：

1) 裝飾對象和真實對象具有同樣的接口。這樣client對象就能夠以真實對象的同樣的方式和裝飾對象交互。

2) 裝飾對象包括一個真實對象的引用(reference).

3) 裝飾對象接受全部來自client的請求，它把這些請求轉發給真實的對象。

4) 裝飾對象能夠在轉發這些請求曾經或者以後添加一些附加的功能。這樣就能確保在執行時，不用改動給定對象結構就能夠在外部添加附加的功能。在面向對象的程序設計中，一般是使用繼承的關系來擴展給定類的功能。

裝飾模式的結構

　　裝飾模式以對客戶透明的方式動態地給一個對象附加上很多其它的責任。換言之。client並不會認為對象在裝飾前和裝飾後有什麽不同。裝飾模式能夠在不使用創造很多其它子類的情況下，將對象的功能加以擴展。

　　裝飾模式的類圖例如以下：

技術分享

　　在裝飾模式中的角色有：

　　●　　抽象構件(Component)角色：給出一個抽象接口，以規範準備接收附加責任的對象。

　　●　　詳細構件(ConcreteComponent)角色：定義一個將要接收附加責任的類。

　　●　　裝飾(Decorator)角色：持有一個構件(Component)對象的實例，並定義一個與抽象構件接口一致的接口。

　　●　　詳細裝飾(ConcreteDecorator)角色：負責給構件對象“貼上”附加的責任。

源碼

　　抽象構件角色

  1. package com.bankht.Decorator;
  3. /**
  4. * @author: 特種兵—AK47
  5. * @創建時間：2012-6-26 上午09:21:22
  6. *
  7. * @類說明 ：抽象構件角色
  8. */
  9. public interface Component {
  11. public void sampleOperation();
  13. }

　詳細構件角色

  1. package com.bankht.Decorator;
  3. /**
  4. * @author: 特種兵—AK47
  5. * @創建時間：2012-6-26 上午09:22:05
  6. *
  7. * @類說明 ：詳細構件角色
  8. */
  9. public class ConcreteComponent implements Component {
  11. @Override
  12. public void sampleOperation() {
  13. // TODO Auto-generated method stub
  14. // 寫相關的業務代碼
  15. }
  18. }

　　裝飾角色

package com.bankht.Decorator;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:23:03
  5. *
  6. * @類說明 ：裝飾角色
  7. */
  8. public class Decorator implements Component {
  9. private Component component;
  11. public Decorator(Component component) {
  12. this.component = component;
  13. }
  15. @Override
  16. public void sampleOperation() {
  17. // 委派給構件
  18. component.sampleOperation();
  19. }
  21. }

　　詳細裝飾角色

package com.bankht.Decorator;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:23:34
  5. *
  6. * @類說明 ：詳細裝飾角色
  7. */
  8. public class ConcreteDecoratorA extends Decorator {
  10. public ConcreteDecoratorA(Component component) {
  11. super(component);
  12. }
  14. @Override
  15. public void sampleOperation() {
  16. super.sampleOperation();
  17. // 寫相關的業務代碼
  18. }
  19. }


package com.bankht.Decorator;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:23:34
  5. *
  6. * @類說明 ：詳細裝飾角色
  7. */
  8. public class ConcreteDecoratorB extends Decorator {
  10. public ConcreteDecoratorB(Component component) {
  11. super(component);
  12. }
  14. @Override
  15. public void sampleOperation() {
  16. super.sampleOperation();
  17. // 寫相關的業務代碼
  18. }
  19. }

齊天大聖的樣例

　　孫悟空有七十二般變化，他的每一種變化都給他帶來一種附加的本領。他變成魚兒時。就能夠到水裏遊泳；他變成鳥兒時，就能夠在天上飛行。

　　本例中，Component的角色便由鼎鼎大名的齊天大聖扮演；ConcreteComponent的角色屬於大聖的本尊。就是猢猻本人；Decorator的角色由大聖的七十二變扮演。而ConcreteDecorator的角色便是魚兒、鳥兒等七十二般變化。

技術分享

源碼

　　抽象構件角色“齊天大聖”接口定義了一個move()方法，這是全部的詳細構件類和裝飾類必須實現的。

package com.bankht.Decorator.wukong;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:28:23
  5. *
  6. * @類說明 ：抽象構件角色“齊天大聖”接口定義了一個move()方法，這是全部的詳細構件類和裝飾類必須實現的。

  7. */
  8. // 大聖的尊號
  9. public interface TheGreatestSage {
  11. public void move();
  12. }


　　詳細構件角色“大聖本尊”猢猻類

package com.bankht.Decorator.wukong;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:28:50
  5. *
  6. * @類說明 ：詳細構件角色“大聖本尊”猢猻類
  7. */
  8. public class Monkey implements TheGreatestSage {
  10. @Override
  11. public void move() {
  12. // 代碼
  13. System.out.println("Monkey Move");
  14. }
  16. }

　　抽象裝飾角色“七十二變”

package com.bankht.Decorator.wukong;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:29:24
  5. *
  6. * @類說明 ：抽象裝飾角色“七十二變”
  7. */
  8. public class Change implements TheGreatestSage {
  9. private TheGreatestSage sage;
  11. public Change(TheGreatestSage sage) {
  12. this.sage = sage;
  13. }
  15. @Override
  16. public void move() {
  17. // 代碼
  18. sage.move();
  19. }
  21. }

　　詳細裝飾角色“魚兒”

package com.bankht.Decorator.wukong;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:29:47
  5. *
  6. * @類說明 ：詳細裝飾角色“魚兒”
  7. */
  8. public class Fish extends Change {
  10. public Fish(TheGreatestSage sage) {
  11. super(sage);
  12. }
  14. @Override
  15. public void move() {
  16. // 代碼
  17. System.out.println("Fish Move");
  18. }
  19. }

　　詳細裝飾角色“鳥兒”

package com.bankht.Decorator.wukong;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:30:11
  5. *
  6. * @類說明 ：詳細裝飾角色“鳥兒”
  7. */
  8. public class Bird extends Change {
  10. public Bird(TheGreatestSage sage) {
  11. super(sage);
  12. }
  14. @Override
  15. public void move() {
  16. // 代碼
  17. System.out.println("Bird Move");
  18. }
  19. }

　client類

package com.bankht.Decorator.wukong;
  2. /**
  3. * @author: 特種兵—AK47
  4. * @創建時間：2012-6-26 上午09:30:32
  5. *
  6. * @類說明 ：client類
  7. */
  8. public class Client {
  10. public static void main(String[] args) {
  11. TheGreatestSage sage = new Monkey();
  12. // 第一種寫法
  13. TheGreatestSage bird = new Bird(sage);
  14. TheGreatestSage fish = new Fish(bird);
  15. // 另外一種寫法
  16. // TheGreatestSage fish = new Fish(new Bird(sage));
  17. fish.move();
  18. bird.move();
  19. }
  21. }


　　“大聖本尊”是ConcreteComponent類，而“鳥兒”、“魚兒”是裝飾類。

要裝飾的是“大聖本尊”，也即“猢猻”實例。

　　上面的樣例中，系統把大聖從一僅僅猢猻裝飾成了一僅僅鳥兒（把鳥兒的功能加到了猢猻身上），然後又把鳥兒裝飾成了一條魚兒（把魚兒的功能加到了猢猻+鳥兒身上，得到了猢猻+鳥兒+魚兒）。

技術分享

　　如上圖所看到的，大聖的變化首先將鳥兒的功能附加到了猢猻身上。然後又將魚兒的功能附加到猢猻+鳥兒身上。

　　

裝飾模式的簡化

　　大多數情況下。裝飾模式的實現都要比上面給出的示意性樣例要簡單。

　　假設僅僅有一個ConcreteComponent類，那麽能夠考慮去掉抽象的Component類（接口），把Decorator作為一個ConcreteComponent子類。例如以下圖所看到的：

技術分享

　　假設僅僅有一個ConcreteDecorator類。那麽就沒有必要建立一個單獨的Decorator類，而能夠把Decorator和ConcreteDecorator的責任合並成一個類。甚至在僅僅有兩個ConcreteDecorator類的情況下，都能夠這樣做。例如以下圖所看到的：

技術分享

透明性的要求

　　裝飾模式對client的透明性要求程序不要聲明一個ConcreteComponent類型的變量，而應當聲明一個Component類型的變量。

　　用孫悟空的樣例來說，必須永遠把孫悟空的全部變化都當成孫悟空來對待。而假設把老孫變成的魚兒當成魚兒，而不是老孫。那就被老孫騙了，而這時不應當發生的。

以下的做法是對的：

TheGreatestSage sage = new Monkey();
  1. TheGreatestSage bird = new Bird(sage);


　　而以下的做法是不正確的：


Monkey sage = new Monkey();
  1. Bird bird = new Bird(sage);


半透明的裝飾模式

　　然而。純粹的裝飾模式非常難找到。裝飾模式的用意是在不改變接口的前提下，增強所考慮的類的性能。在增強性能的時候。往往須要建立新的公開的方法。即便是在孫大聖的系統裏，也須要新的方法。比方齊天大聖類並沒有飛行的能力。而鳥兒有。這就意味著鳥兒應當有一個新的fly()方法。

再比方，齊天大聖類並沒有遊泳的能力。而魚兒有，這就意味著在魚兒類裏應當有一個新的swim()方法。

　　這就導致了大多數的裝飾模式的實現都是“半透明”的，而不是全然透明的。換言之，同意裝飾模式改變接口，添加新的方法。這意味著client能夠聲明ConcreteDecorator類型的變量，從而能夠調用ConcreteDecorator類中才有的方法：

TheGreatestSage sage = new Monkey();
  1. Bird bird = new Bird(sage);
  2. bird.fly();

　　半透明的裝飾模式是介於裝飾模式和適配器模式之間的。適配器模式的用意是改變所考慮的類的接口，也能夠通過改寫一個或幾個方法，或添加新的方法來增強或改變所考慮的類的功能。大多數的裝飾模式實際上是半透明的裝飾模式，這種裝飾模式也稱做半裝飾、半適配器模式。

裝飾模式的長處

　　（1）裝飾模式與繼承關系的目的都是要擴展對象的功能，可是裝飾模式能夠提供比繼承很多其它的靈活性。裝飾模式同意系統動態決定“貼上”一個須要的“裝飾”，或者除掉一個不須要的“裝飾”。

繼承關系則不同，繼承關系是靜態的，它在系統執行前就決定了。

　　（2）通過使用不同的詳細裝飾類以及這些裝飾類的排列組合。設計師能夠創造出非常多不同行為的組合。

裝飾模式的缺點

　　因為使用裝飾模式。能夠比使用繼承關系須要較少數目的類。

使用較少的類，當然使設計比較易於進行。可是，在還有一方面，使用裝飾模式會產生比使用繼承關系很多其它的對象。很多其它的對象會使得查錯變得困難，特別是這些對象看上去都非常相像。


設計模式在JAVA I/O庫中的應用

　　裝飾模式在Java語言中的最著名的應用莫過於Java I/O標準庫的設計了。

　　因為Java I/O庫須要非常多性能的各種組合。假設這些性能都是用繼承的方法實現的，那麽每一種組合都須要一個類。這樣就會造成大量性能反復的類出現。而假設採用裝飾模式。那麽類的數目就會大大降低。性能的反復也能夠減至最少。因此裝飾模式是Java I/O庫的基本模式。

　　Java I/O庫的對象結構圖例如以下。因為Java I/O的對象眾多，因此僅僅畫出InputStream的部分。

技術分享

　依據上圖能夠看出：

　　●　　抽象構件(Component)角色：由InputStream扮演。這是一個抽象類，為各種子類型提供統一的接口。

　　●　　詳細構件(ConcreteComponent)角色：由ByteArrayInputStream、FileInputStream、PipedInputStream、StringBufferInputStream等類扮演。它們實現了抽象構件角色所規定的接口。

　　●　　抽象裝飾(Decorator)角色：由FilterInputStream扮演。

它實現了InputStream所規定的接口。

　　●　　詳細裝飾(ConcreteDecorator)角色：由幾個類扮演，各自是BufferedInputStream、DataInputStream以及兩個不經常使用到的類LineNumberInputStream、PushbackInputStream。

半透明的裝飾模式

　　裝飾模式和適配器模式都是“包裝模式(Wrapper Pattern)”，它們都是通過封裝其它對象達到設計的目的的，可是它們的形態有非常大差別。

　　理想的裝飾模式在對被裝飾對象進行功能增強的同一時候。要求詳細構件角色、裝飾角色的接口與抽象構件角色的接口全然一致。而適配器模式則不然，一般而言，適配器模式並不要求對源對象的功能進行增強，可是會改變源對象的接口，以便和目標接口相符合。

　　裝飾模式有透明和半透明兩種。這兩種的差別就在於裝飾角色的接口與抽象構件角色的接口是否全然一致。透明的裝飾模式也就是理想的裝飾模式。要求詳細構件角色、裝飾角色的接口與抽象構件角色的接口全然一致。相反，假設裝飾角色的接口與抽象構件角色接口不一致，也就是說裝飾角色的接口比抽象構件角色的接口寬的話，裝飾角色實際上已經成了一個適配器角色，這樣的裝飾模式也是能夠接受的，稱為“半透明”的裝飾模式。例如以下圖所看到的。

技術分享

　　在適配器模式裏面，適配器類的接口一般會與目標類的接口重疊，但往往並不全然同樣。

換言之。適配器類的接口會比被裝飾的目標類接口寬。

　　顯然，半透明的裝飾模式實際上就是處於適配器模式與裝飾模式之間的灰色地帶。假設將裝飾模式與適配器模式合並成為一個“包裝模式”的話。那麽半透明的裝飾模式倒能夠成為這樣的合並後的“包裝模式”的代表。

InputStream類型中的裝飾模式

　　InputStream類型中的裝飾模式是半透明的。為了說明這一點，最好還是看一看作裝飾模式的抽象構件角色的InputStream的源碼。這個抽象類聲明了九個方法，並給出了當中八個的實現，另外一個是抽象方法。須要由子類實現。

public abstract class InputStream implements Closeable {
  2. public abstract int read() throws IOException;
  5. public int read(byte b[]) throws IOException {}
  7. public int read(byte b[], int off, int len) throws IOException {}
  9. public long skip(long n) throws IOException {}
  11. public int available() throws IOException {}
  13. public void close() throws IOException {}
  15. public synchronized void mark(int readlimit) {}
  17. public synchronized void reset() throws IOException {}
  19. public boolean markSupported() {}
  21. }

　　

　　以下是作為裝飾模式的抽象裝飾角色FilterInputStream類的源碼。能夠看出，FilterInputStream的接口與InputStream的接口是全然一致的。也就是說，直到這一步。還是與裝飾模式相符合的。


public class FilterInputStream extends InputStream {
  1. protected FilterInputStream(InputStream in) {}
  3. public int read() throws IOException {}
  5. public int read(byte b[]) throws IOException {}
  7. public int read(byte b[], int off, int len) throws IOException {}
  9. public long skip(long n) throws IOException {}
  11. public int available() throws IOException {}
  13. public void close() throws IOException {}
  15. public synchronized void mark(int readlimit) {}
  17. public synchronized void reset() throws IOException {}
  19. public boolean markSupported() {}
  20. }


　以下是詳細裝飾角色PushbackInputStream的源碼。

public class PushbackInputStream extends FilterInputStream {
  1. private void ensureOpen() throws IOException {}
  3. public PushbackInputStream(InputStream in, int size) {}
  5. public PushbackInputStream(InputStream in) {}
  7. public int read() throws IOException {}
  9. public int read(byte[] b, int off, int len) throws IOException {}
  11. public void unread(int b) throws IOException {}
  13. public void unread(byte[] b, int off, int len) throws IOException {}
  15. public void unread(byte[] b) throws IOException {}
  17. public int available() throws IOException {}
  19. public long skip(long n) throws IOException {}
  21. public boolean markSupported() {}
  23. public synchronized void mark(int readlimit) {}
  25. public synchronized void reset() throws IOException {}
  27. public synchronized void close() throws IOException {}
  28. }


　　查看源代碼，你會發現，這個裝飾類提供了額外的方法unread()，這就意味著PushbackInputStream是一個半透明的裝飾類。

換言 之。它破壞了理想的裝飾模式的要求。假設client持有一個類型為InputStream對象的引用in的話，那麽假設in的真實類型是 PushbackInputStream的話，僅僅要client不須要使用unread()方法，那麽client一般沒有問題。可是假設client必須使用這種方法，就 必須進行向下類型轉換。

將in的類型轉換成為PushbackInputStream之後才可能調用這種方法。可是，這個類型轉換意味著client必須知道它 拿到的引用是指向一個類型為PushbackInputStream的對象。這就破壞了使用裝飾模式的原始用意。

　　現實世界與理論總歸是有一段差距的。純粹的裝飾模式在真實的系統中非常難找到。一般所遇到的，都是這樣的半透明的裝飾模式。

　

　以下是使用I/O流讀取文件內容的簡單操作演示樣例。

public class IOTest {
  2. public static void main(String[] args) throws IOException {
  3. // 流式讀取文件
  4. DataInputStream dis = null;
  5. try{
  6. dis = new DataInputStream(
  7. new BufferedInputStream(
  8. new FileInputStream("test.txt")
  9. )
  10. );
  11. //讀取文件內容
  12. byte[] bs = new byte[dis.available()];
  13. dis.read(bs);
  14. String content = new String(bs);
  15. System.out.println(content);
  16. }finally{
  17. dis.close();
  18. }
  19. }
  21. }


　　觀察上面的代碼。會發現最裏層是一個FileInputStream對象，然後把它傳遞給一個BufferedInputStream對象，經過BufferedInputStream處理，再把處理後的對象傳遞給了DataInputStream對象進行處理，這個過程事實上就是裝飾器的組裝過程，FileInputStream對象相當於原始的被裝飾的對象，而BufferedInputStream對象和DataInputStream對象則相當於裝飾器。





本文借鑒：

http://blog.csdn.net/m13666368773/article/details/7691871

http://www.cnblogs.com/hnrainll/archive/2012/03/23/2414180.html

http://www.cnblogs.com/java-my-life/archive/2012/04/20/2455726.html

《Java設計模式》之裝飾模式

相關推薦

Java設計模式（9）——創建型模式之裝飾模式

block 擴展 str 分享 增加 image tro col 技術 一、概述 　　動態地給一個對象添加一些額外的職責。就增加功能來說， Decorator模式相比生成子類更為靈活。該模式以對客 戶端透明的方式擴展對象的功能。 　　UML簡圖 　　 　　角

java設計模式之裝飾模式

zha tput str itl fill ext 裏的 pri use 轉載請註明出處：http://blog.csdn.net/zhaoyanjun6/article/details/56488020 前言 其實我們可以這樣理解裝飾器模式， 就拿自己舉例子

java設計模式之裝飾模式代理模式區別

初次看裝飾模式的時候首先想到了上節講的代理模式，代理模式與裝飾者模式看起來很像，都實現基礎物件實現的介面，在其自身物件中都儲存著對被代理/被裝飾者的物件引用。 各用一句話描述兩個模式應該是這樣的： 裝飾模式：以對客戶端透明的方式擴充套件物件的功能，是繼承關係的一個替代方案

大話設計模式之裝飾模式總結-java實現

注：示例來自《大話設計模式》 現有如下要求 寫一個可以給人搭配不同的服飾的系統 程式碼如下 Person類 package Test06; public class Person { private String name; pub

Java設計模式之裝飾模式趣談

JVM:”上次給我招的工人不錯啊！” oo程式設計師:”………..” JVM:”現在來我開的博物館生意越來越好了，原來”舞臺劇

設計模式之裝飾模式

裝飾模式 設計模式 包裝器模式 1、裝飾模式相關介紹： a、裝飾模式的職責： - 動態的為一個對象增加新的功能 - 裝飾模式是一種用於代替繼承的技術，無需通過繼承增加子類就能夠擴展對象的新功能。使用對象的關聯關系代替繼承關系，更加靈活，同時避免了類型體系的快速膨脹。 b

設計模式之裝飾模式的復習

裝飾 容器 cfg trac 兩個 div 添加 維護 ble 經典問題：咖啡館問題 咖啡有四種類型：HouseBlend （混合咖啡）、DarkRoast （燒烤咖啡）、Decaf （ 脫咖啡因咖啡）和espresso（濃咖啡） 調味品如：Steamed milk(清蒸調

設計模式之裝飾模式 Decorator

imp override int cor args public generate fly end 代碼實現 public interface ICar { void move(); } 抽象構建角色 //具體構件角色（真實對象，被裝飾

設計模式的藝術 結構性模式之裝飾模式

不懂使用為學過，說出用途，繪製結構為了解，不會靈活使用基本等於沒學。 前言 我們大多數時候買的新房都是毛坯房，想要入住的話無疑需要進行一次裝修自己才能高高興興的入住，雖然裝修了，但是並沒有改變房子的本質，但這樣會讓你更樂於到房子裡面去入住，在軟體設計中，也有這麼一種技術可以對已有的物件的功能

設計模式之裝飾模式（Decorator）

設計模式之裝飾模式（Decorator） 場景 普通人跑步，跳高，舉重很普通。 現在需要使用裝備變成鋼鐵俠，3項指標成倍擴大 Man介面 public interface Man { void run(); int highJump();

大話設計模式之裝飾模式

       經過了前面的設計原則和工廠三姐妹、單例設計模式的學習，我相信大家已經掌握了基本的學習方法，今天我們來總結裝飾模式，首先來看一下裝飾模式的UML圖：                         接著我們根據UML圖寫一下原始碼實現： abstract clas

面向物件設計模式之---裝飾模式(Decorator Pattern)

裝飾模式給我的感覺就有點像一個人穿衣服，或者從更專業一點的角度來說，有點像Java中檔案讀取時管道要套上一層又一層的“衣服”一樣。這是一個鏈式的過程。 裝飾模式的定義是： 動態地給一個物件新增一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。 裝飾模式

設計模式之裝飾模式（dubbo原始碼中的裝飾模式）

package org.apache.dubbo.rpc.protocol; import org.apache.dubbo.common.Constants; import org.apache.dubbo.common.URL; import org.apache.du

23種設計模式之裝飾模式

職責：動態的為一個物件增加一個新的功能 裝飾模式是一個用於代替繼承的技術，無須通過繼承增加子類就能擴充套件物件的新功能，使用物件的關聯關係代替繼承關係，更加靈活，同時避免型別體系的快速膨脹。 實

設計模式之裝飾模式和代理模式區別與聯絡

一.你在一個地方寫裝飾，大家就知道這是在增加功能，你寫代理，大家就知道是在限制      1.最常見的代理就是許可權判斷了，許可權就肯定是限制了      2.裝飾模式是指增強被包裝物件的功能        代理模式是修改被代理物件的行為      3.例子：      

設計模式之裝飾模式，學習心得。如有錯誤，請多指教，謝謝。

裝飾模式設計出來的目的就是為了更方便的對現有類進行功能的新增，同時又不改變現有類。即，我是不永恆不變的，為了現在滿足我某個功能，這個功能大多數時候我是不需要的，你讓我自己去學習這個功能，我又不常用我學它幹什麼呢？沒有必要改變自己嘛。就像為了在冬天保暖，我沒有必要長一身毛，沒有

7 結構型模式之 - 裝飾模式

oid str res bstr 子類 protected eat 同時 jea 裝飾模式介紹：裝飾模式也稱為包裝模式，是結構型模式之一，其使用一種對客戶端透明的方式來動態地擴展對象的功能，同時它也是繼承關系的一種替代方案之一。在現實生活中你也可以看見很多裝飾模式的例子，或

結構型模式之 裝飾模式

res 松耦合 行為 父類 添加 class 但是 end bsp 裝飾模式(Decorator Pattern) ：動態地給一個對象增加一些額外的職責(Responsibility)，就增加對象功能來說，裝飾模式比生成子類實現更為靈活。其別名也可以稱為包裝器(Wrappe

結構型模式之裝飾模式

活性 @override java基礎 cor span decorator 不用 解決 system 裝飾模式（Decorator Pattern）是一種比較常見的模式。 定義： 動態地給一個對象添加一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。 裝飾模

《Java設計模式》之裝飾模式

情況 -s 抽象接口 output 就會 ati ack hba ensure 裝飾模式(Decorator) 1. 裝飾模式(Decorator)的定義：又名包裝(Wrapper)模式。裝飾模式以對client透明的方式擴展對象的功能，是繼承關系的一個替代方案。