設計模式 裝飾者模式

裝飾者模式：動態的將新功能附加到物件上，在物件的功能拓展方面，它比繼承更有彈性，裝飾者模式也體現了ocp原則

1.裝飾物件和真實物件有相同的介面。這樣客戶端物件就能以和真實物件相同的方式和裝飾物件互動

2.裝飾物件包含乙個真實物件的引用

3.裝飾物件接受所有來自客戶端的請求。它把這些請求**給真實的物件。

4.裝飾物件可以在**這些請求以前或以後增加一些附加功能。這樣就確保了在執行時，不用修改給定物件的結構就可以在外部增加附加的功能。在物件導向的設計中，通常是通過繼承來實現對給定類的功能擴充套件

每個類的角色請參考上面的裝飾者類圖來理解

component（抽象類）:

public

abstract
class
drink
public
void
setdes
(string des)
public
float
getprice()
public
void
setprice
(float price)
//計算費用的抽象方法
//子類來實現
public
abstract
float
cost()
;}

public

class
decorator
extends
drink
@override
public
float
cost()
@override
public string getdes()
}

//具體的decorator， 這裡就是調味品

public
class
chocolate
extends
decorator
}

public

class
coffee
extends
drink
}public
class
decaf
extends
coffee
}

public

class
coffeebar
}

仔細分析以上**，當我們需要新增新的咖啡種類只需要繼承component或者已有的coffee

當我們需要新增調料的時候，我們只需繼承deractor，這樣極大了方便了程式設計，符合了ocp原則，可以動態的新增新的功能，

當計算總的**的時候，我們也可以動態的通過裝飾者包裝，就可以計算**。

裝飾者和被裝飾者之間必須是一樣的型別,也就是要有共同的超類。在這裡應用繼承並不是實現方法的複製,而是實現型別的匹配。因為裝飾者和被裝飾者是同乙個型別,因此裝飾者可以取代被裝飾者,這樣就使被裝飾者擁有了裝飾者獨有的行為。根據裝飾者模式的理念,我們可以在任何時候,實現新的裝飾者增加新的行為。如果是用繼承,每當需要增加新的行為時,就要修改原程式了。

io中，filterinputstream就是乙個裝飾者，請大家檢視原始碼分析。

設計模式 裝飾者模式

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 角色 定義乙個將要接收附...