какой дизайн выбрать? - плюсы и минусы

Question

Какой из этих 3 подходов выберет и почему?

// This is the one I would choose

class Car {

}

class FeeCalculator {

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

---

// в этом случае проблема может заключаться в том, что мы используем среду ORM и пытаемся вызвать save с параметром Car

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

Я голосую за первого. Такой калькулятор не является частью автомобиля, и автомобиль, как правило, не способен рассчитывать сборы.

Второй дизайн моделирует что-то вроде автомобиль-калькулятор , третий вариант близок к автомобиль-калькулятор (даже если он делегирует вычисление другой класс).

---

И, кроме того, структура ORM не должна влиять на архитектуру модели. Модель должна отражать «реальный мир», вокруг достаточно экспертов, чтобы реализовать модель в любой среде ORM.

Answer 2

Какое отношение имеет автомобиль к исчислению платы? Ничего, скорее всего. В связи с этим мне нравится вариант 1.

Answer 3

Я бы использовал вариант на второй теме.Я вставлял в машину FeeCalculator (либо old-skool, либо через DI-фреймворк - Spring / Guice / и т.Тем не менее, я бы сделал так, чтобы API FeeCalculator не знал о Car (иначе у вас круговая зависимость, и вам придется выставлять из Car такие вещи, которые в противном случае вы не хотели бы).Вместо этого я бы попросил API для FeeCalculator взять основные входные данные для расчета - количество дней в прокате, дневную ставку, график скидок клиентов и т. Д.