可维护的设计模式建议

我正在研究一个项目，针对不同的服务有不同的价格计算。例如：可维护的设计模式建议

首页服务：基础上，厨房，卧室，浴室数
婴儿托管：根据日期和星期，小时数（包括加班）
洗车的时间：根据座位数

每个服务根据这些方面计算不同的成本。服务的数量将会增加，因此每个服务的特定功能最终可能太多以至于无法维护。

我可以使用什么样的设计模式，以确保我的代码仍然会维护在长期运行？

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，其定价基于基于价格的时间，客户希望预订多少小时，其他服务是家庭清洁，其价格基于计算多少卧室，厨房，浴室和其他房间有其他可选的预订，如窗户清洁与价格指数。问题是我的客户公司倾向于改变他们的定价模式太快，我渴望满足他们的需求。 –

可维护的设计模式建议

回答

相关问题