裝飾器模式

裝飾器模式說白了很簡單，先來一張圖

component：元件物件的介面，可以給這些物件動態的新增職責；

concretecomponent：具體的元件物件，實現了元件介面。該物件通常就是被裝飾器裝飾的原始物件，可以給這個物件新增職責；

decorator：所有裝飾器的父類，需要定義乙個與元件介面一致的介面(主要是為了實現裝飾器功能的復用，即具體的裝飾器a可以裝飾另外乙個具體的裝飾器b，因為裝飾器類也是乙個component)，並持有乙個component物件，該物件其實就是被裝飾的物件。如果不繼承元件介面類，則只能為某個元件新增單一的功能，即裝飾器物件不能在裝飾其他的裝飾器物件。

concretedecorator：具體的裝飾器類，實現具體要向被裝飾物件新增的功能。用來裝飾具體的元件物件或者另外乙個具體的裝飾器物件。

——————————華麗的分割線————————————

別看上面東西挺多，其實說白了也沒幾句話，就是給原來的東西套上乙個殼，沒必要定的那麼死，這個一定要介面那個一定要實現類什麼的，我舉個例子

public
class person
}public
class japanese
//日本人吃飯
public
void
japaneseeating()
}

說白了裝飾器模式就是拓展原有的類，讓他實現更多的功能

那麼問題來了，我用繼承的方法不是也能做到上面的效果麼？我重寫乙個japanese類繼承person類再重寫一下eat方法不也可以？確實上面這個例子是可以，但是想一想你繼承通常是用來幹什麼的，你繼承一般都在哪用。我認為繼承是需要統一行為的類的時候用的，子類不能有父類沒有的特性。我現在再舉乙個例子

//裝備飛行器的人
class personwithaerocraft
public
void
eat()
public
void
fly()
}

你看，現在這個人能飛了。你還能用繼承或者實現介面來滿足這個情況麼？由此你也可以知道，裝飾器的功能之一就是描述事物的狀態（其實這也是我剛剛才想到的……）。比如上面這個穿了飛行器的人，這個時候他是可以飛的，你總不能給person類加個方法讓全人類都能飛吧。更扯得是你想一下，如果你的person是個介面呢？在實際專案中你根本不能輕易的去改這些介面，因為你一改介面，所有實現介面的類都要重新修改，乙個兩個檔案還好說，如果專案比較大，成百上千個類需要你去改那怎麼辦。所以很多時候你需要額外新增乙個裝飾器類來拓展你原有類的功能。當然，你也可以做乙個裝飾器介面。

繼承不能當成裝飾器來用，裝飾器也同樣不能當作繼承，我們不說裝飾器不能像繼承那樣父類 a=new 子類()這種形式建立，你要想實現原本類方法還得自己重新寫，比如人能吃喝拉撒睡，戴著飛行器的人也能，但你想讓裝飾器類實現這個方法就得自己重新再寫。當然你也可以直接用***.person.***x()，就是對其他人不怎麼友好

你看，說了半天其實上面都是些廢話。實際上這裝飾器就是乙個類裡有那麼乙個成員變數，然後再利用這個成員變數提供幾個自己需要用的方法。優點就是不用修改原有**就可以新增功能

裝飾器模式

裝飾器模式

裝飾器模式

裝飾器模式

相關推薦