Какие шаблоны использовать - как оформить

Question

Все,

Я - процесс применения дизайнерского мышления к повседневным проблемам.на процессе, мне нужна помощь по следующему.Предположим, что компании по прокату автомобилей, такой как Hertz, нужны приложения, а также регулярные данные, им нужна возможность предлагать клиентам предложения на основе определенных критериев.

Критерии:

1. Все перечисленные праздничные дни (не выходные) - получите скидку 10% от стоимости аренды
2. Только в день труда получите скидку 15% от стоимости аренды
3. если брать> 3 дня для перечисленных праздников - скидка 20%
4. если брать> 3 дня в день труда - скидка 25%
5. и т. Д. - еще больше придет

Теперь я могу придумать для начала декораторы, такие как

IVehicleBase
{  
 Props: Make, Model, HirePrice, HireTimePeriodinDays   
}

Конкретные классы:

public class FordExplorer : VehicleBase   
{
    public override string Make
    {
        get { return "Ford"; }
    }

    public override string Model
    {
        get { return "Explorer"; }
    }

    public override double HirePrice
    {
        get { return 450; }
    }

    public override int HireTimePeriodinDays
    {
        get { return 1; }
    }
}

Аналогично для многих других классов (автомобилей).

Теперь, как мне украсить специальные предложения?

Я могу думать о vehicleDecoratorBase, но если предложение относится только к праздникам, тогда хорошо (сделайте две конкретные реализации для трудовых / других перечисленных праздников), но у нас есть праздники в сочетании с hireDate, которое является свойством доменаавтомобиля.

Я надеюсь, что здесь есть смысл.Любые советы, пожалуйста?

Ура

Answer 1

Я бы сказал, что аренда, цены, специальные предложения и т. Д. Не принадлежат автомобилю: это отдельная абстракция (ы) .Тем более что перечисленные выше типы предложений, похоже, не связаны с конкретной моделью транспортного средства, а только с календарными днями / продолжительностью аренды и т. Д.

Поэтому не пытайтесь добавлять их в качестве декораторов ктранспортное средство.Вместо этого создайте отдельный класс (иерархию) для работы с ними.

Обратите внимание, что на основании вашего описания у вас есть два варианта использования:

• агент по аренде должен бытьв состоянии перечислить все существующие предложения для клиента например ", если вы начнете аренду в следующий понедельник, вы получите скидку 10% благодаря этому предложению, или, если вы начнете во вторник, но продлите аренду до 3 днейВы получите скидку 20% " и т. д.
• (ориентировочная) цена конкретной аренды должна быть рассчитана с учетом всех применимых скидок.

Таким образом, с одной стороны, вы должны хранить экземпляр каждого действительного предложения в коллекции , что позволяет агенту перечислять их по одному вместе с текстовым описанием.(Обратите внимание, что, поскольку предложения, скорее всего, не имеют состояния, у вас может быть один общий экземпляр каждого.)

OTOH вам нужна функциональность для каждого предложения, чтобы решить, применимо ли оно к конкретной конкретной аренде.Это может быть реализовано в отдельных классах предложений, а затем вызывается полиморфно, например, с помощью селектора предложений (особый вид фабрики), который перебирает коллекцию предложений и выбирает их для заданных арендных платежей (хорошо, вы можете сразу же повторно использовать коллекциюпредложений для другой цели!).Применимые предложения тогда фактически действуют на сбор арендной платы (то есть не обязательно непосредственно на сам объект аренды), изменяя / снимая сборы в зависимости от ситуации.

В качестве примечания, если вы представляете каждую модель транспортного средства сотдельный производный класс IVehicleBase, у вас будет очень много производных классов в реальной жизни, и, кроме того, вам нужно будет регулярно добавлять новые, когда появляются новые модели и включаются в парк.А требование изменения кода при появлении новой модели транспортного средства - это головная боль при техническом обслуживании в долгосрочной перспективе.Конечно, если это всего лишь экспериментальный / игрушечный проект, обслуживание не может быть проблемой.