裝飾者模式是在不必改變原類檔案和使用繼承的情況下，動態地擴充套件乙個物件的功能。它是通過建立乙個包裝物件，也就是裝飾來包裹真實的物件。
現給出以下需求：某個類a其中的方法m1裡面的功能不夠用，需要公升級，也就是擴充套件;
怎樣在不改變a類功能的前提下實現功能的擴充套件？
1.通過繼承實現
重新定義乙個類b,讓類b繼承類a，然後重寫a中的方法，在保證a類功能的前提下，增加擴充套件功能
注意：該方法雖然能實現在不更改a類功能的前提下擴充套件a類的功能，但是這樣的話必須新定義的類繼承a類，從而使得**之間的耦合度變高，這樣很不好,因此不建議使用
2.通過裝飾者模式實現
定義乙個介面,讓裝飾者類和被裝飾者類都實現這一介面,而且在裝飾者中必須要有被裝飾者的引用
在下面的示例中：a為被裝飾者,b為裝飾者,c為介面
優點：decorator模式與繼承關係的目的都是要擴充套件物件的功能，但是decorator可以提供比繼承更多的靈活性,而且**之間的耦合度低
下面先演示通過繼承實現功能的擴充套件：
類a
public
class a
}
/*
*通過繼承實現功能的擴充套件
*/public
class
bextends
a}
public
class test
}
定義乙個介面
public
inte***ce c
public
class
aimplements
c}
public
class
bimplements
c @override
public
void
m1()
}
public
class test
}
由圖可知，這兩種方法都實現了功能的擴充套件，雖然通過繼承也能實現，但是該方法使得各模組的耦合度變高，因此不推薦使用
總結：裝飾者模式的要求：
1.定義乙個介面，且裝飾者和被裝飾者都要實現該介面
2.裝飾者中含有被裝飾者的引用
設計模式 裝飾者模式
public abstract class beverage public abstract double cost public abstract class condimentdecorator extends beverage public class darkroast extends be...
設計模式 裝飾者模式
沒什麼特別的，之前看懂了，這次自己再複述一下。畢竟把別人講懂了才是真的懂了。主要參考了head first 設計模式。例子講述的是在為星巴克咖啡的製作訂單的情況，比如客人點了飲料，那麼系統會自動算出 不知道是我沒有體會到，還是這個例子不太合適，算出 那麼簡單的事還需要用到類？不過不影響我們思考裝飾者...
設計模式 裝飾者模式
好幾天沒出部落格了，在學習android的一些新控制項的時候，用到了乙個模式，叫裝飾者模式，所以在此講講這個模式。模式，包含以下四個角色 1 抽象構件 component 角色 給出乙個抽象介面，以規範準備接收附加責任的物件。2 具體構件 concretecomponent 角色 定義乙個將要接收附...