Правильно ли оформлен мой ООП? - PullRequest
Новая
       26

Правильно ли оформлен мой ООП?

1 голос
/ 04 августа 2011

У меня есть сценарий, в котором я разрабатываю систему для розничной торговли. Это не правильное живое приложение, а всего лишь сценарий, чтобы проверить, правильны ли мои навыки проектирования ОО и правильно ли я думаю. Я все еще учусь здесь. Я делаю это в C #.

Сценарий таков:

Ритейлер, продающий стационарные товары, хочет разработать систему, которая выберет лучшую цену из своего различного фиксированного числа поставщиков и сделает заказ от этого поставщика. Для простоты я сократил количество стационарных продуктов до одного продукта от той же компании, который представляет собой ручку XYZ. Каждый из поставщиков предоставит ценовое предложение для ручки XYZ, когда система спросит, и система розничной торговли выберет лучшую цену у различных продавцов и разместит заказ у этого продавца.

Подход 1:

  1. Создайте абстрактный класс для поставщика и реализацию для каждого поставщика.
  2. У каждой реализации поставщика есть метод PlaceOrder () и свойство cost.
  3. DataLayer устанавливает свойство стоимости для каждой реализации поставщика.
  4. Создайте класс CheckBestRetailer, который оценивает каждую реализацию по лучшей цене и размещает заказ в соответствующей реализации.

Подход 2:

  1. Создание списка поставщиков типов со свойством Cost и методом PlaceOrder ().
  2. Для каждого поставщика уровень данных добавляет новый тип поставщика в список и устанавливает сведения о стоимости, полученные из базы данных.
  3. Класс CheckBestRetailer проходит по этому списку и оценивает каждый объект по лучшей цене и размещает заказ в соответствующей реализации.

Из двух приведенных выше, я чувствую, что подход 1 ближе к ООП, но при условии, что у меня есть фиксированное количество поставщиков. Если количество поставщиков может меняться в зависимости от данных, извлеченных из базы данных, то подход 2 лучше.

Что вы думаете?

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

Спасибо за ваше время.

Ответы [ 2 ]

3 голосов
/ 04 августа 2011

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

Что я обычно делаю, когда не знаю, как что-то решить:

  • Перечислите мои требования: Получите лучшую цену за предмет из набора поставщиков.
  • Создайте список объектов-кандидатов: Поставщик, Товар, Ритейлеры и т.д.
  • Рисование или разметка классов с отношениями, которые, я думаю, имеют смысл
  • Когда я потерян, я начинаю кодировать основные классы для требования, в этом случае это будет метод Retailers и GetBestRetailer ().

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

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

НТН

3 голосов
/ 04 августа 2011

Я бы сказал, что подход 2 лучше.Нет необходимости создавать уникальный класс для каждого поставщика, поскольку поведение поставщиков почти одинаково.

...