Как убрать эту параллельную иерархию

Question

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

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

Существует два типа раундов: финальный раунд (содержащий 6 или менее танцевальных пар) или обычный раунд (содержащий более 6 танцевальных пар). Каждый требует немного другого поведения и данных.

В случае финального раунда каждая таблица результатов содержит упорядоченный список из 6 пар в финальной таблице, показывающий, какую пару судья занял 1-е, 2-е место и т. Д. Я называю эти места «таблица результатов содержит 6 мест». Место размещения содержит номер пары, и какое место у этой пары

В случае нормального раунда каждая таблица результатов содержит неупорядоченный набор из M пар (M <количество пар, вступивших в раунд - точное значение, определенное организатором соревнования). Я называю эти отзывы: «таблица результатов, как вспоминает М». Отзыв не содержит оценки или рейтинга </p>

например В финале

• 1-е место: пара 56
• 2 место: пара 234
• 3 место: пара 198
• 4 место: пара 98
• 5 место: пара 3
• 6 место: пара 125

для нормального раунда Следующие пары вспоминаются 54,67,201,104,187,209,8,56,79,35,167,98

Моя наивная версия реализована как

Событие - has_one final_round, has_many раундов

final_round - has_many final_performances final_performance - has_many final_scoresheets final_scoresheet - has_many размещения

тур - has_many выступления производительность has_many партитуры таблица результатов has_many напоминает

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

Answer 1

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

Answer 2

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

Не ясно, что final_performance действительно отличается от исполнения. Я предполагаю, что они оценены по-другому; это должно быть отражено в различиях в final_scoresheet, и вы, вероятно, предполагали, что вам нужно было изменить final_performance, потому что он должен содержать final_scoresheets. Возможно, у вас может быть только один объект перформанса, и вместо того, чтобы таблицы результатов, содержащиеся в перформансе, имели круглые объекты, связывающие таблицы результатов с выступлениями:

round.getScoresheet(couple,dance)

вместо

round.getPerformance(couple,dance).getScoresheet()

Мне также интересно, нужны ли вам объекты для размещения и отзыва: могут ли они быть просто (упорядоченными) списками пар, извлеченными из таблиц результатов? Если так, то вы исключили три класса.

Сдерживание предпочтительнее наследования.