Новый / книжный объектно-ориентированный подход к дизайну

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

Например, предположим, что меня интересуют персонажи романа и в каких главах и страницах они появляются.

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

Здесь есть множество возможных объектов: Роман, Глава, Страница, Персонаж.

Между этими возможными объектами существует множество отношений:

  • В романах есть последовательность глав, последовательность страниц и набор персонажей.
  • Главы состоят из последовательности страниц и набора из нуля или более символов.
  • Страницы связаны с одной или несколькими главами и нулем или более символов
  • Персонажи связаны с одной или несколькими страницами и главами

Целью этих объектов будет отвечать на такие вопросы, как:

  • На каких страницах появляется персонаж Алиса?
  • Какие персонажи появляются в главе 6?
  • Какие символы часто появляются на одних и тех же страницах?
  • На какой странице впервые упоминается персонаж Боб?

Я немного не понимаю, как подойти к такому дизайну. Я вижу несколько подходов:

  • Сделайте все (Роман, Глава, Страница, Персонаж) объектом, и у каждого из этих объектов есть списки ссылок на другие объекты, которые они содержат/с которыми связаны.

  • Отдайте первенство той или иной главе или странице и сделайте другую атрибутом первой. Например, мы могли бы использовать только список объектов «Роман», «Глава» и «Персонаж» и сделать «страницы» атрибутом объекта «Глава».

  • Мы могли бы развить эту идею еще дальше и просто придерживаться романа и персонажа и дать каждому персонажу несколько атрибутов, таких как: «Происходит в главе» и «Происходит на страницах».

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


person deadcode    schedule 31.05.2013    source источник


Ответы (1)


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

Это говорит нам о двух вещах:

  1. Вы пытаетесь смоделировать физическое расположение определенного издания книги (поскольку в противном случае приведенный выше пример вопроса не имел бы смысла).
  2. На ваш дизайн сильно повлияет круг вопросов, на которые необходимо ответить, так как это определит, будет ли ваша система:

    • use data structures to pre-cache meta-data that will be required as answers (e.g. explicitly store a list of pages a character appears on),
    • хранить «необработанные данные» (например, в виде дерева романа > глав > страниц > текста), которые затем обрабатываются для ответа на заданный вопрос,
    • какое-то сочетание того и другого

Я подозреваю, что комбинация, вероятно, будет правильной в вашем случае, поэтому ваши «необработанные данные» будут представлены аналогично первому упомянутому вами подходу:

Сделайте все (роман, главу, страницу, персонажа) объектом, и каждый из этих объектов будет иметь списки ссылок на другие объекты, которые они содержат/с которыми связаны"

за исключением того, что экземпляры Page будут ссылаться на экземпляры Text, а не Character, которые вместо этого станут классом метаданных.

Метаданные могут быть предварительно кэшированы или генерироваться по запросу путем просмотра необработанных данных.

В любом случае вы захотите нормализовать свою модель данных,

person Ergwun    schedule 31.05.2013
comment
Спасибо за ваше понимание, очень полезно. - person deadcode; 01.06.2013