2017-05-25 41 views
2

從C#中果殼: enter image description here裝飾者流是否也作爲流實例的適配器或其他設計模式實現?

  1. 流適配器實現爲流實例的適配器。

    是裝飾流也實現爲流 實例的適配器?他們實施了哪些設計模式?

  2. 注意,裝飾機流被實現爲 System.Stream或由其派生的類派生的類,而流適配器 並不(但可通過組合物,其我猜)。所以我想知道是否可以通過組合或繼承來實現適配器 模式?

    • 正在適配器始終組成,而不是繼承方面實現的(這樣他們可以從 處理不同類型的輸入,他們適應的)?
    • 正在裝修總是繼承權實現,以代替成分(使他們能夠始終以同樣的方式作爲 他們裝點一個使用)?

感謝。

回答

1

適配器通常更改界面,裝修一般不用。

這就是爲什麼在你的圖中的「裝飾流」的消費者能替代任何類對方。代碼不會改變它是緩衝流還是加密流。在另一方面,讀者和作家(您的流適配器)的

消費者期待一個非常特殊的接口,是高度定製和適配器變化很大,以適配器。一個返回XML節點,另一個可能是原始類型。他們不能彼此交換。

(而且還有一個「裝飾」的格局直出GoF的書,「設計模式」的)。

+0

謝謝。適配器是否總是以組合而不是繼承的方式實現(以便他們可以處理來自他們所適應的不同類型的輸入)?裝飾器總是以繼承的方式實現而不是組合(這樣它們總是可以像裝飾的一樣使用)? – Tim

+0

沒有這樣的事情一如既往。對於你的具體問題,雖然你的「裝飾者流」需要從共同的祖先繼承或實現,但他們大多數情況下在包裝「Backing Store Streams」時使用構圖。這就是爲什麼你沒有看到GzipMemroyStream類和GzipFileStream類或任何其他排列。這會導致具體的類爆炸。 – tcarvin