1. 程式人生 > >裝飾者模式(一)

裝飾者模式(一)

背景

假設我們現在要為沙縣小吃建立一個應用程式,我們需要對沙縣小吃進行建模。假設一開始他們提供了雞腿飯、鴨腿飯、大肉面三種飯。剛剛開始的時候我們使用了繼承來實現,而且將公共的操作放在了抽象的Snack類中。

    每種飯的價格不一樣,所以在每個子類中都重寫了getCost()方法。現在顧客除了點雞腿飯、鴨腿飯、大肉面之外,還想加上青菜、蒸蛋、土豆以及再加一個雞腿等等需求。按照現在的方式針對上面的需求有兩種實現方式。

第一種

將加了額外項的看成是一個獨立的菜種繼承Snack,並覆蓋它的getCost()方法,在這個方法中計算價格。

以這種方式來實現的缺點是每增加一種配菜就需要增加一個子類,隨著時間的推移會出現很多類,這到後期會導致專案很難維護。

第二種方式

在父類中定義配菜以及是否存在配置的方法以及一個獲取價格的方法(getCost),在子類中覆蓋父類的

 使用這種方式,存在一下幾個缺點:

  1. 一旦出現新的配菜,我們就需要在父類中增加新的方法,並修改getCost方法
  2. 並不是每個配菜都適合所有的飯,這樣就造成類方法的冗餘
  3. 很難處理客戶給飯加雙份配菜的情況