Проектирование объектной модели

Здравствуйте! Есть задание спроектировать объектную модель определённый предметной области.
Определить иерархию продуктов питания. Собственно создаём абстрактный класс Products, определяем поля и методы. С этим проблем нет. Дальше у нас к примеру появляется 2 ветки наследования, а именно - классы "Овощи" и "Фрукты", создавать от таких классов экземпляры - не имеет смысла. Как вариант сделать их тоже абстрактными, но по сути они будут пустыми ибо никаких своих методов они не имеют (или могут иметь?). Просто я не вижу отличий между классами "Овощи" и "Фрукты". Наследованные поля типа: имя, вес, и т.д. и соответствующие методы уже определены в суперклассе...Подскажите как быть? Может быть что-то почитать?

0

Эти рассуждения очень похожи на "ООП ради ООП".
Смысл классов, интерфейсов и т.п. в том, чтобы упростить решение какой-то
конкретной задачи. Например, единообразное управление объектами разных типов.
А если цели нет, или нет понимания того, для решения какой задачи нужны будут
все эти наследования и иерархии, превращать все в ООП не имеет смысла.

0

Сообщение от Убежденный Эти рассуждения очень похожи на "ООП ради ООП". Смысл классов, интерфейсов и т.п. в том, чтобы упростить решение какой-то конкретной задачи. Например, единообразное управление объектами разных типов. А если цели нет, или нет понимания того, для решения какой задачи нужны будут все эти наследования и иерархии, превращать все в ООП не имеет смысла.

Цель - получить конкретный овощ и фрукт. Как пример нам нужен огурец, который имеет суперкласс "Овощи". Мы его можем порезать, поместить в массив с другими овощами/фруктами и получить салат. Сам же суперкласс "Овощи" не имеет "личных" методов, он просто наследует всё то, что определено в Products. Я не знаю правильно ли оставлять "Овощи" пустым. Да, вы правильно заметили, тут всё похоже на "ООП ради ООП"...

0

Сообщение от Recreate Цель - получить конкретный овощ и фрукт.

Для чего ? Для каких функциональных или архитектурных требований это нужно ?
Ответите на этот вопрос - станет ясно, что от чего наследовать (и нужно ли).

0

Сообщение от Убежденный Для чего ? Для каких функциональных или архитектурных требований это нужно ? Ответите на этот вопрос - станет ясно, что от чего наследовать (и нужно ли).

Ну требование такое: Спроектировать объектную модель для заданной предметной области.
По сути дела нам нужен конкретный овощ или фрукт (чтобы сортировать и искать их по разным параметрам и т.д.). Огурец может наследоваться от Products, а "Овощи" можно сделать интерфейсом который мы реализуем в "огурце".

0

Сообщение от Recreate Ну требование такое: Спроектировать объектную модель для заданной предметной области.

В том-то и дело, что данное требование весьма и весьма туманное.

Давайте возьмем реальный пример ООП - парсер какого-нибудь формата, такого как
JSON, XML или CSV, не суть. Хороший парсер позволяет работать с любой формой
входных данных - файл, буфер в памяти, URL, по которому размещаются данные, и т.п.
Для этого парсер работает с данными не напрямую, а через некий обобщенный
интерфейс, пусть будет abstract_stream, а за этим интерфейсом уже скрываются
реальные формы данных - file_stream, memory_stream, url_stream и т.д.
Если клиента по каким-то причинам не устраивает ни одна из готовых реализаций,
он пишет свою, переопределяя нужные методы в базовом abstract_stream.

Но можно делать и совсем по-другому.
Например, есть класс "картошка". У картошки есть кожура. Сразу вопрос:
кожура - это часть картошки, или кожура - это и есть картошка. Или, может быть,
картошка - это наследник кожуры. Давайте наследовать картошку от ее кожуры.
Ах, да, у картошки есть разные сорта. Введем несколько базовых классов "сорта",
унаследуем от них каждую разновидность картошин. Картошка бывает жареная,
вареная, сырая, печеная - отличный повод сделать еще одну параллельную
иерархию наследования... Давайте введем класс-примесь, который будет определять,
какие блюда можно готовить из картошки, а какие нет. А регулировать это
все будем различными visitor-ами, двойной диспетчеризацией и т.п.

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

Второй пример - типичная "ООП-каша", в которой наследуются только ради
того, чтобы от чего-то унаследоваться, "потому что так нужно в ООП".
И нет ни одного требования или ограничения (естественного или созданного
искусственно), чтобы привести все эти наследования в порядок и ответить
на вопрос, где оно нужно, это ООП, а где оно как козе баян.

3

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

Вот Вы уже создали классы "Овощи" и "Фрукты" - а зачем? Ну да, одни растут на земле, др на деревьях, но если напр мы торгуем ими в магазине - какая разница? Отсюда избитое выражение "не плодите сущности". Я понимаю что это не поможет Вам сдать задание, но может Вы хотели услышать правдивые ответы

Добавлено через 10 минут

Сообщение от Убежденный Давайте возьмем реальный пример ООП - парсер какого-нибудь формата, такого как JSON, XML или CSV, не суть. Хороший парсер позволяет работать с любой формой входных данных - файл, буфер в памяти, URL, по которому размещаются данные, и т.п. Для этого парсер работает с данными не напрямую, а через некий обобщенный интерфейс, пусть будет abstract_stream, а за этим интерфейсом уже скрываются реальные формы данных - file_stream, memory_stream, url_stream и т.д. Если клиента по каким-то причинам не устраивает ни одна из готовых реализаций, он пишет свою, переопределяя нужные методы в базовом abstract_stream.

Хороший пример, но и он предполагает какие-то правила типа

- данные организованы в виде тегов, для конкретного формата правила оформления тегов известны
- тег может иметь вложенные теги и.т.п.

В данных где этого нет (напр obj файл alias 3d модель) вся конструкция развалится (что не означает она плоха)

1

Да, в моём случае можно создать бесконечно глубокую иерархию картошки и прочих овощей. Причём практически все эти классы бесполезны ибо не будут выполнять какие-либо действия. Их наличие "просто для галочки". Можно попробовать у конкретных объектов добавить константное поле типа такого: type = "Овощ" или же задавать тип в конструкторе. Таким образом можно решить проблему бессмысленного наследования?

0

Проблема бессмысленного наследования нерешаема в принципе

Сообщение от Recreate По сути дела нам нужен конкретный овощ или фрукт (чтобы сортировать и искать их по разным параметрам и т.д.).

Вот от этого (выделил жирным) можно попробовать отталкиваться.

1

Сообщение от Igor3D Я понимаю что это не поможет Вам сдать задание, но может Вы хотели услышать правдивые ответы

Мне хочется именно разобраться в данном вопросе. Сдать задание я всегда успею. Хочу понять и сделать качественно.

Добавлено через 2 часа 15 минут
Итого, после переваривания вышеизложенной информации решил поступить как-то так...
Конкретный класс (картошка) наследует только абстрактный класс (быть может придумаются какие-то нужные интерфейсы), в поле type мы выбираем чем является наша картошка...Соответственно сортировку можно производить по цене, весу, типу. Поиск по аналогии. Если нам нужен салат, то создаём массив имеющий тип абстрактного класса и уже туда кладём конкретные продукты. Вроде бы такой подход компактен и не имеет излишеств.

0

иллюстрация предыдущих ответов
http://habrahabr.ru/post/153225/

1

Сообщение от Recreate Мне хочется именно разобраться в данном вопросе. Сдать задание я всегда успею. Хочу понять и сделать качественно.

Сделать ЧТО? В задании это никак не звучит, нет цели для чего это.

Сообщение от Recreate Конкретный класс (картошка) наследует только абстрактный класс (быть может придумаются какие-то нужные интерфейсы), в поле type мы выбираем чем является наша картошка...Соответственно сортировку можно производить по цене, весу, типу. Поиск по аналогии. Если нам нужен салат, то создаём массив имеющий тип абстрактного класса и уже туда кладём конкретные продукты. Вроде бы такой подход компактен и не имеет излишеств.

Добавить поле ID - уникальный идентификатор продкута. Заметим что так или иначе - цель появилась, напр можно искать продукты по каким-то ключам. Вполне нормально

0

Сообщение от Igor3D Ну да, одни растут на земле, др на деревьях, но если напр мы торгуем ими в магазине - какая разница?

Арбуз, дыня, ананас, черника теперь являются овощами?)

1

Если по теме, то одно из основных понятий ООП не класс, а абстракция

Абстрагирование — это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция — это набор всех таких характеристик

Если не можешь выделить существенные отличия, то и класс создавать не стоит.

0

я как то писал небольшую статью по UML в которой немного раскрывается этот вопрос
articleUML
как будет время поправлю ссылки в статье. (там просто теперь в ссылках "http" нужно заменить на "https" в самом начале, возможно также нужно убирать "www.")

Добавлено через 8 минут
можно обратиться к сообществу системных аналитиков(сайт uml2_ru) они вас быстро научат точно определять требования к системе и определять цели пользователей.

0

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

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

0

Сообщение от novi4ok овощ может иметь методы, например, "сколькодлясалата", "сколькодлясупа", "скольковарить"

способ приготовления (рецепт) никакого отношения к овощам не имеет

Добавлено через 24 секунды

Сообщение от novi4ok фрукт - "насколькосладкий", "насколькокислый".

относительно чего? по какой шкале?

0

у тебя есть хорошие идеи по поводу того, что может овощ такого, чего не могут ни фрукт, ни абстрактный продукт питания? выложи, а мы посмеемся.

0

Задача решилась в 2 класса. Абстрактный Products и класс наследник ConcreteProduct. К слову сдал на отлично, с небольшими оговорками. Всем спасибо кто принимал участие.

0