Question

我正在开发一个针对不同服务进行不同价格计算的项目。例如：

家庭服务：基于厨房，卧室，浴室的数量
宝宝坐着：根据一天和一周的时间，小时数（包括加班）
洗车：根据车的大小，座位数

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

我可以使用哪种设计模式来确保我的代码从长远来看仍然可维护？

Answer 1

也许Decorator Pattern可以在这里提供帮助。

您的组件的类型为Service，您可以将其子类化为HomeServices，BabySitting，CarWashing。因此，一个角色可以执行2个或3个或更多任务并获得一次付款，每个子类都有自己的付款计算int addCost(int cost)并且递归addCost()其服务成员来计算最终成本，您甚至可以添加通过为每个任务添加新的子类来完成不同的任务。

Answer 2

战略模式浮现在脑海中，但你仍然会为每个策略编写一个“功能”，更确切地说是一个类。使用DI COntainer，无论策略数量多少，都不会有问题。

没有神奇的设计模式可以减少应用程序所需的代码量，您唯一能做的就是更好地组织代码。

Answer 3

术士是对的，装饰者是动态定价的一种方式。许多服务（此处的服务被假定为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);
    }
}

这样，如果你需要添加更多逻辑，你只需要引入新的类，例如不同的轮胎数量。

可维护的设计模式建议

3 个答案: