目前對裝飾者模式產生的原因理解如下：
若以人穿衣服，或是飲料店對飲料加料為例，人跟飲料可以是最上層的父類別
衣服可以有很多種，飲料要加的料也可以有很多種，若是以繼承的方式來給人穿衣服
或是給飲料加料，這樣的話：
人+一種衣服是一種子類別，飲料+一種料也是一種子類別。
這樣的話很多種衣服很多種料，就會有很多種子類別。
更不要說很多種衣服、很多種料各自還可以組合出不同子類別。
所以很明顯，子類別數量會過於龐大。
而且人+一種衣服、飲料+一種料，按照邏輯，衣服跟料都是可選擇的，順序不固定的，
若用繼承方式去擴充人和飲料的話，那就是把穿衣服跟加料的順序寫死。這就完全
不符合人類穿衣或給飲料加料的邏輯，也就是說完全不合理。
這是一個原因。
另一個原因，以麥當勞主餐配副餐，組成套餐為例。主餐配副餐形成套餐，
看似可以用繼承方式來描述，也就是主餐為父類別，套餐繼承主餐類別並加上副餐，
形成子類別。但是
主餐往往不只一種，這樣的話變成有多種主餐，套餐要繼承主餐就會變成是多重繼承。
因此在某些需求下，會變成多重繼承，這是Java程式必須避免的現象。
再來，若是堅持要以繼承來實作以上的例子，繼承可能會有很多層，例如飲料加了
很多料，其實就是子類別有好幾層，下一層類別都包含了上一層類別，這樣的話，
若是要計算「加了很多料的飲料」的價格，計算的method必須層層呼叫到最上層的類別，
取出原始飲料的價格後，又層層返回到最下層的，加了很多料的類別，這樣才能計算出
「加了很多料的飲料」的價格，也就是說類別之間相依性很高，而相依性高正好也是
Java程式必須避免的問題。