justin寫了一篇關於decorator模式很好的文章來杯咖啡-裝飾者模式(decorator),詳細地闡述了這一模式,**並茂非常爽心悅目.
關於他舉的".net框架裡的應用" tooltip一例個人卻有著不同的意見.意見的最大問題可能在於:對於decorator的定義上.
體現了動態新增功能的就是decorator嗎?每個模式是不是應該有個本質的點,decorator模式的本質又在**?
大致摘錄下justin給我回覆的幾個觀點.
1. tooltip動態增加了button的功能.裝飾者模式的作用是動態擴充套件物件的職責，這個職責裡除了物件原來就有的職責，應該也包括物件原來不存在的功能。
2.tooltip和button在icomponent上應該是介面統一的，這似乎有點象裝飾者模式的類圖結構
3.說某個實現是xx模式，不是因為這個實現跟xx模式的官方定義的類圖完全一樣，而是因為這個實現解決的問題跟xx模式要解決的問題完全一樣，那麼就可以說某個實現是xx模式
個人的理解如下:
1. 所有設計模式的實現手段無非就是 繼承+組合,所以"tooltip和button在icomponent上應該是介面統一的"不能說明什麼問題
2. tooltip為button動態新增了功能.弱弱地問,dp中只有decorate可以動態新增功能嗎?這應該是果,而非因
3"裝飾者模式的重點在於相互裝飾", 我要表達的是"可以互相裝飾".如何a和b都是decorator的話,a可以裝飾b,b也可以裝飾a,並且是動態的.所以為什麼在gof的uml圖中有注釋強調了 呼叫傳入的decorator同一operation方法,不這樣我想沒法互相裝飾,沒法透明
public override void operation()
在我fcl(4):: arraylist & list (2)一文,henry liang同學在回覆裡說syncarraylist類裡使用了decorator.syncarraylist是為arraylist增加了同步的功能,但其沒有體現動態,沒體現互相裝飾,所以我覺得這仍然不是decorator模式.也許我的這一觀點偏激,因為我覺得它沒有體現了decorator精髓的地方.
4.對於justin的觀點3,非常贊同.類圖確實不需要完全一樣.但個人認為每個模式都有乙個本質點,本質點必須一樣.
那麼本質在**. 在於
public override void operation() 在於
abstract class decorator : component
protected component actualcomponent;
只有透明只有可互相裝飾,才能可以解決某種情況下子類數目呈**性增長的問題.不至於出現那麼多的beverage子類,做簡單重複的勞動.
5.退一步
decorator為什麼要繼承自component.這樣做是為了透明,為讓decorator能夠透明代替concretecomponet. 而decorator為什麼要在operation()裡擴充concretecomponent的目的也在於此,提供統一的介面.那麼tooltip繼承自icomponent是出於這個目的嗎?
歸根結底:decorator的意圖為:動態地給乙個物件新增一些額外的職責.
那麼動態地給乙個物件新增一些額外的職責是不是一定就是decorator
關於Decorator模式
關於decorator模式 decorator用於動態地給物件新增一些額外的職責，注意 此處是給物件，而不是給類，這正式該模式靈活的地方。你可以給乙個物件巢狀乙個或人乙個多個decorator。下面我們主要要看一下decorator和strategy的區別。decorator模式僅從外部改變組建，因...
設計模式 decorator模式
裝飾者模式體現了 敏捷開發思想中的 對類要 開放擴充套件,關閉修改.例子 乙個person主類 若干裝飾品類 紅衣服,藍衣服,藍鞋子,紅鞋子 測試 new乙個person 給他穿上紅衣服藍鞋子 code person介面 public inte ce ipersonperson類 package c...
設計模式 decorator模式
兩點 目的 在不改變被裝飾類功能的前提下增加新功能 特點 繼承是子類和父類強耦合，橋接是低耦合 例子 class print 抽象介面 virtual int getcolumns virtual int getrows virtual string getrowcontent int row el...