Какая структура класса будет наиболее подходящей для установки?

Question

Я работаю над университетским заданием для модуля объектно-ориентированного проектирования. После лингвистического c анализа существительных и глаголов и определения вариантов использования в настоящее время составляется диаграмма классов.

Соответствующие части программы следующие:

• Программа используется сотрудниками магазина. Существует список продуктов, которые представляют, что находится в магазине. Каждый продукт имеет уникальные данные, включая ассоциированного поставщика и компанию-поставщика (у которой родительский класс может называться «внешняя компания»).

• Должна также быть функциональность для отслеживания заказов (но не для размещения). Требования не включают несколько заказов на один продукт; только один запас за один раз для каждого продукта.

Это заставляет меня думать, что любые детали, связанные с заказом на продукт, могут быть перечислены как атрибуты для этого объекта продукта, а не как атрибуты объекта заказа, который связан с объект продукта. Если бы было несколько заказов на один продукт, я бы определенно составил список заказов в дополнение к списку продуктов, однако на один продукт приходилось только 1.

Проблема заключается в том, что все атрибуты продукта (имя, вес, срок годности, идентификатор, стоимость за единицу, скорость продаж, фотография и т. Д. c) и все атрибуты заказа (предполагаемая дата заказа, сумма заказа). , дата поставки, сумма, причитающаяся поставщику, дата последнего заказа), поскольку атрибуты продукта сделают класс продукта громоздким. Кроме того, разделение их на два класса может создать избыточность. Кроме того, большинство «атрибутов» заказа на самом деле являются результатами вычислений, выполненных с использованием атрибутов продукта, а не «базовых атрибутов» (извинения за неправильную терминологию).

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

Опция 1:

Опция 2:

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

Answer 1

Ключом к успешному проектированию ОО является разделение интересов . Это означает, что если вы знаете, что есть какие-то вещи, которые присущи продукту, и другие вещи, которые связаны с заказом этого продукта, вы должны отделить их.

Теперь, после 20 лет работы в ERP, я могу вам сказать, что один заказ за раз является лишь временной ситуацией. Рано или поздно вам придется развиваться, поэтому лучше предвидеть, если это очевидно. Так что вариант 2 - это путь к go.

Теперь вы должны сделать пару вещей на диаграмме:

• Сначала добавьте кратность .
• Используйте стрелки, только если вы действительно хотите express однонаправленную навигацию . В вашем случае я настоятельно советую против этого.
• Ваша связь между Product, Order, Supplier и External Company не соответствует вашему повествованию. Вы сказали, что у каждого продукта есть связанный поставщик и компания по доставке. Так что между ними должна быть прямая связь. Вы также сказали, что поставщик МОЖЕТ иметь в качестве материнской компании внешнюю компанию. Таким образом, могут быть заказы без какой-либо внешней материнской компании.
• Конечно, это неявно, но заказ также будет иметь компанию. И даже если в определенный момент времени это только один, если вы сохраните это в базе данных, вы сможете надежно найти заказ любого данного поставщика, даже бывших.
• Не стесняйтесь пометить ассоциации , чтобы добавить выразительность к вашей диаграмме. Потому что некоторые ассоциации могут показаться излишними, но не совсем, если посмотреть на их значение.

Теперь последнее: я не знаю о вашем назначении, но я бы посоветовал сосредоточиться на классах домена и выпустить GUI. Почему ? потому что, как только вы начнете с GUI, у вас наверняка появятся подклассы GUI, связанные с другими вещами, а не только со списком продуктов. Как это, я нахожу это в заблуждение.