Моделирование вопрос о категоризации. Подтип или нет?

Question

Мне нужен совет по моделированию этой простой категоризации (?) Пример:
У меня есть продукт. Продукт может быть разных типов, например ProductType 1, ProductType 2 и ProductType 3. Все продукты имеют номер детали и имя. Там, где они различаются, это способ расчета их цен.

• Изделия в цене типа 1 зависят от количества продукта. Поэтому, если у меня есть 5 продуктов, цена равна $ x. Если у меня 20 продуктов, цена $ y и так далее.
• Изделия в цене типа 2 зависят от веса каждого продукта. Если вес составляет 5 кг, цена равна $ x и так далее.
• Изделия типа 3 имеют простую цену, например, $ x для каждого продукта.

Как я вижу, каждая «ценовая структура» должна иметь выделенный стол/класс. Затем продукт будет ссылаться на свою ценовую структуру в зависимости от типа продукта. Вы бы просто создали таблицу «тип продукта» и получили атрибут «Тип» в классе «Продукт», или вы бы использовали обобщение, так что продукт 1/2/3 является подтипом продукта? Будет 5 различных ценовых структур, а способ расчета цены отличается от каждого типа. Таким образом, логика расчета общей цены заказа зависит от каждого типа продукта.

Можете ли вы дать мне несколько советов о том, как смоделировать это наилучшим образом? Если я выберу подход, в котором есть атрибут Type в классе Product, я предполагаю, что в моем коде будет получено множество инструкций if-else. Если я захочу подклассифицировать их, каждый класс может нести ответственность за расчет правильной цены или за то, что просят сделать.

Answer 1

Это звучит для меня как прекрасный пример того, когда следует использовать Strategy pattern. Если вы используете наследование класса, чтобы определить, как оценивается продукт, вам придется перекомпилировать всю систему, если кто-то позже решит, что WidgetXYZ теперь должен быть оценен по весу, вместо простой цены.

Я бы определил каждый продукт как имеющий «ценовую стратегию» - в вашем случае это будет либо «volumeDiscount», «byWeight», либо «simple». Затем вы можете использовать Factory, чтобы обеспечить правильный объект PriceCalculator в зависимости от стратегии продукта, и что priceCalculator рассчитает цену продукта соответствующим образом.

Answer 2

Мое предложение состоит в том, что в вашей реляционной модели данных у вас будет столбец типа, чтобы отличить тип записи. В коде вы должны обязательно использовать подкласс. Модель домена должна быть как можно больше независима от базовой модели данных, и ваше описание хорошо поддерживает необходимость совместного использования атрибутов (с использованием ABC - абстрактного базового класса для продукта), подтипа P1, P2, P3 (дать ему значимое имя домена) и полиморфизм для изменения расчета цены.

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