Вопрос для интервью: хот-дог, чипсы, напитки, еда (OO Design, Design Pattern.)

Question

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

1. Разработайте систему для этой ситуации.

2 Какие шаблоны дизайна вы можете использовать здесь? Опишите это?

Кто-нибудь может дать мне несколько советов? Вы можете дать краткое представление или подробное описание. Спасибо, ребята.

Answer 1

FoodCartFactory, которая может производить несколько экземпляров FoodCart.

FoodCart - основной класс.

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

Использование DI также было бы хорошей идеей, поскольку цены могут варьироваться в зависимости от местоположения и т. Д., Поэтому завод должен настроить корзину с объектом PolicyManager, который контролирует цены.

Кроме того, FoodCartController обеспечит наличие в корзине нужных предметов.

Вам также необходим объект CartCustomer, представляющий цель сообщения FoodSale, которая будет содержать товар, сумму и цену (включая, конечно, соответствующие налоги).

Вам также понадобится некоторая бизнес-логика в классе под названием ProfitMaximizer, где подсчитывается, что продается и сколько, чтобы передать необходимые сообщения FoodNeeded в FoodController.

Конечно, ProfitMaximizer не может хорошо работать без какой-либо аналитики, возможно, в классе под названием FoodStatistics, который отслеживает продажи, тренды, маржу, номер клиента и т. Д.

Вам также понадобится некоторая поддержка диагностики, представленная классом под названием FoodCartLogger, для сбора информации для диагностики и устранения неполадок с корзиной.

Очевидно, что вам также нужно заботиться о производительности корзины, поэтому FoodCartPerfMonitor требует изменений.

Опять же, нам не следует пропускать возможность того, что эта корзина нужна для обслуживания клиентов в разных точках мира, поэтому вам, очевидно, нужны ResourceManager и FoodCartLocalizer.

Вам также нужна подсистема для отслеживания доступного капитала на основе потока доходов и расходов. Давайте назовем это FoodCartAccountManager.

И если у вас есть какая-либо прибыль, она должна автоматически инвестироваться в диверсификацию дохода, поэтому, конечно, класс ExchangeTrader не может быть и речи.

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

Конечно, все эти классы необходимы для управления одной тележкой; если вам нужно разработать систему, которая может работать с несколькими тележками, вам придется добавить несколько других компонентов. С другой стороны, очевидно, что многие из приведенных выше классов могут иметь дело с более чем одной тележкой, поэтому вы можете использовать их повторно.

Я думаю, что это касается обложек базового дизайна.

Answer 2

Я бы сделал что-то подобное ..

class FoodCart extends Vendor {
    List<FoodItem> foodItems;
    List<Meal> meals;
}

class Vendor {
    List<SellableItem> sellableItems;
    int saleRevenue;
}

class SellableItem {
    int price;
    int quantity;

    /**
     * @return true if the item is sold out
     */
    public boolean soldOut() {
        return quantity == 0;
    }
}

class FoodItem extends SellableItem {
    Date expirationDate;
    //more food-specific variables
}

class Meal {
    FoodItem[] foodItems;

    /**
     * The meal cannot be sold if any one component making up the meal is sold out.
     * @return true, if none of this meal's components is sold out.
     */
    boolean sellable() {
        boolean result = true;
        for (int i = 0; i < foodItems.getLength(); i++) {
            result &= !foodItems[i].soldOut();
        }
        return result;
    }
}

И вот оно. Напитки - это тоже FoodItems. Скажи мне, что ты думаешь.