design-patterns - 可维护的设计模式建议

Question

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

• 家庭服务：基于厨房、卧室、浴室的数量
• 婴儿看护：基于一天和一周的时间，小时数（包括加班）
• 洗车：根据汽车大小、座位数

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

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

Answer 1

也许装饰器模式可以在这里提供帮助。

您的组件将是类型Service，您可以将其子类化为HomeServices, BabySitting, CarWashing。因此，一个参与者可以执行 2 个或三个或多个任务并获得一次报酬，每个子类都有自己的支付计算，int addCost(int cost)并递归地addCost()计算其服务成员以计算最终成本，您甚至可以通过为每个任务添加一个新的子类来添加不同的任务。

Answer 2

我想到了策略模式，但您仍然会为每个策略编写一个“函数”，更准确地说是一个类。使用 DI 容器，无论有多少策略，您都不会遇到问题。

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

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);
    }
}

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