Question

这3个approches中的哪一个会选择以及为什么？

// This is the one I would choose

class Car {

}

class FeeCalculator {

    public double calculateFee(Car car) {
        return 0;
    } 
}

//在这种情况下，问题可能出在我们使用ORM框架时，我们尝试使用参数Car调用save

class Car {

    private FeeCalculator calculator;

    public double calculateFee() {
        return calculator.calculateFee(this); 
    }
}

class FeeCalculator {

    public double calculateFee(Car car) {
        return 0;
    }
}

//在这种情况下，上面提到的问题已经解决，但我不喜欢这个设计

class Car {

    public double calculateFee(FeeCalculator calculator) {
        return calculator.calculateFee(this); 
    }
}

class FeeCalculator {

    public double calculateFee(Car car) {
        return 0;
    }
}

Answer 1

我为第一个投票。这样的计算器不是汽车的一部分，汽车通常无法计算费用。

第二个设计模型类似 car-has-a-calculator ，第三个选项接近 car-is-a-calculator （即使它委托了计算到另一个班级。）

此外，ORM框架不应影响模型的体系结构。该模型应反映“现实世界”，有足够的专家在任何ORM框架中实施该模型。

Answer 2

我会在第二个主题上使用变体。我会在车上注入FeeCalculator（通过旧车或通过DI框架 - Spring / Guice /等），然后让车能够通过委托来计算费用。但是，我会让FeeCalculator API不知道Car（否则你有一个循环依赖，你必须暴露你可能不想要的Car的东西）。相反，我会让FeeCalculator的API采用计算的基本输入 - 租用天数，日费率，客户折扣计划等。

Answer 3

汽车与计算费用有什么关系？没什么，最有可能的。在这方面，我喜欢备选方案1.

哪个设计选择？ - 利弊

3 个答案: