可維護的設計模式建議

我正在研究一個項目，針對不同的服務有不同的價格計算。例如：可維護的設計模式建議

首頁服務：基礎上，廚房，臥室，浴室數
嬰兒託管：根據日期和星期，小時數（包括加班）
洗車的時間：根據座位數

每個服務根據這些方面計算不同的成本。服務的數量將會增加，因此每個服務的特定功能最終可能太多以至於無法維護。

我可以使用什麼樣的設計模式，以確保我的代碼仍然會維護在長期運行？

2013-10-29 John Hadikusumo

家庭服務，嬰兒坐，洗車，你在寫X級電影？抱歉抱不住:) –

也許Decorator Pattern有助於解決這個問題。

您的組件將是Service類型，您可以將其子類別爲HomeServices,BabySitting,CarWashing。所以，一個演員可以執行2或三個或多個任務，並獲得所許一次，每個子類有自己的支付計算其服務成員來計算最終的成本int addCost(int cost)和遞歸addCost()，你甚至可以通過每一個新的子類中添加不同的任務任務。

來源

2013-10-29 08:11:57

IMO，DEcorator在這裏沒有幫助，OP不想爲現有類添加新的行爲。此外，我不會爲此使用繼承，因爲BabySitting計算與CarWashing完全不同。讓各種服務彼此不相關要好得多，而它們的「常見」行爲相當於靜態類中的一些實用程序方法，對所有服務都是中性的。 – MikeSW

一切都基於需求，據我瞭解，服務可能由一家公司提供，並且有很多服務，並且每項服務的計費方式都不同，但這是計費！所以我會使用裝飾器並使計費方法抽象化。 –

「服務數量將增加」 –

戰略格局浮現在腦海，但你仍然可以寫一個「功能」，更確切的一類，每個策略。使用DI COntainer，無論策略的數量多少，都不會有問題。

有不是魔術的設計模式，減少的需要爲您的應用程序代碼量，你唯一可以做的事情就是組織代碼更好。

來源

2013-10-29 08:16:21 MikeSW

術士是對的，裝飾者是一種去動態定價的方式。許多服務（這裏的服務被認爲是BLL類）將被需要，但不會太多，因爲它會滿足您的業務需求。

你需要的是2接口，一個通用的服務接口和一個定價基準接口。在C＃：

interface IBillParameter{ 
    decimal DefaultCost { get; } // this is assumed if you has default fixed cost, but may be ignored 
} 

interface IBillCalculator<T> where T : IBillParameter{ 
    decimal Calculate(T parameter); 
}

的實現，如CarServices：

class CarServiceBillParameter :IBillParameter { 
    decimal DefaultCost { get{ return 0; } } // for example if does not has any fixed cost 
    SizeF CarSize { get;set; } 
    int Seat { get;set; } 
} 

class CarFixedCostBillCalculator : IBillCalculator<CarServiceBillParameter>{ 
    decimal Calculate(CarServiceBillParameter parameter){ 
     return parameter.DefaultCost; // this can be replaced by database call, or zero for null pattern 
    } 
} 

class SeatCarServiceBillCalculator : IBillCalculator<CarServiceBillParameter>{ 
    public SeatCarServiceBillCalculator(IBillCalculator<CarServiceBillParameter> baseCalculator){ 
     this.baseCalculator = baseCalculator; 
    } 
    IBillCalculator<CarServiceBillParameter> baseCalculator; 
    decimal Calculate(CarServiceBillParameter parameter){ 
     decimal eachSeatPrice = GetFromDatabase(); 
     return parameter.Seat * eachSeatPrice + baseCalculator.Calculate(parameter); 
    } 
}

這樣，如果你需要添加更多的邏輯，你只需要通過數引入新的類，例如不同的價格輪胎。

來源

2013-10-29 10:19:25 Fendy

感謝這個例子。在我目前的情況下，他們只是添加了House Keeping，其定價基於基於價格的時間，客戶希望預訂多少小時，其他服務是家庭清潔，其價格基於計算多少臥室，廚房，浴室和其他房間有其他可選的預訂，如窗戶清潔與價格指數。問題是我的客戶公司傾向於改變他們的定價模式太快，我渴望滿足他們的需求。 –

可維護的設計模式建議

回答

相關問題