Диаграмма классов UML - диктует ли множественность ограничение реализации?

Рассмотрим простую агрегацию с моим любимым примером (шахматы): я бы создал шахматную доску как двумерный массив шахматных фигур (по крайней мере, мне кажется, что это хорошее решение), например:

chessman [,] board=new chessman[8,8];

Это означает, что на каждой позиции может стоять шахматная фигура. Но на самом деле фигурок будет максимум 32. И в этом проблема - что должна отображать диаграмма классов, реализация или мое предположение?

BOARD‹>----Шахматная фигура 0..64 или 0..32?

Потому что реализация однозначно позволяет 64, а игровая логика не должна допускать больше 32.


analysis uml class-diagram diagramming
person John V    schedule 02.11.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Нет, это должно быть как 0...64, потому что есть 64 ChessMan, где только 32 из массива не являются нулевыми.
в диаграмме классов мы не опускаем (уменьшаем) ссылки, которые являются нулевыми.
введите описание изображения здесь
Еще раз, это правда, что будет только 32 объекта, не нулевых, но это это не диаграмма классов, вам НУЖНО целых 64 блока в игре, и это описывает диаграмма классов.
Но помимо этого, я действительно не вижу, чтобы ваш подход был очень хорошо разработан, потому что +50% массива board всегда равно нулю. поэтому я предлагаю просто сохранить (отследить) ChessMan и найти каждое ChessMan местоположение с самим собой. вам также может понадобиться удалить потерянные ChessMans.
введите здесь описание изображения
см. также в приведенном выше примере, это возможно, что потеря каждого ChessMan приводит к установке нулевого значения в массиве, но в диаграмме классов мы всегда устанавливаем ФАКТИЧЕСКИЙ размер ассоциаций.

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

и другое решение будет продолжать отслеживать местоположения

person Community    schedule 02.11.2013
comment
Спасибо, отличное объяснение! С вашим подходом, я предполагаю, вам понадобится еще один 2D-массив с 64 квадратами, чтобы узнать доступные местоположения и т. Д.? - person John V; 03.11.2013
comment
Я предлагаю продолжать отслеживать доступные ChessMan с помощью List<> (без массива), потому что размер списка/массива уменьшается, и просто сохранять нулевые значения не очень хорошая идея. - person ; 03.11.2013
comment
@ user25111414 да, но вам нужно где-то хранить координаты доски. Как бы вы подсчитывали возможные ходы, проверяли их доступность, не имея массива, представляющего сетку доски 8x8? Но я согласен с тем, что шахматы хранятся отдельно, просто спрашиваю, как оттуда идти дальше. - person John V; 03.11.2013
comment
как я сказал, ваш подход лучше всего подходит для выполнения, это означает, что вы узнаете возможные ходы, просто проверяя блоки вокруг, но мой подход говорит, что просто держите доступную шахматную фигуру, в этом случае вам нужно проверить и обработать все доступные местоположения шахматной фигуры (x ,y), чтобы узнать возможное движение. Предположим, вам нужно переместить шахматную фигуру, поэтому, если вы просто отсортируете доступный массив шахматных фигур по x и y, вы найдете статус целевого блока с помощью небольшого поиска в массиве рядом с соответствующим индексом шахматной фигуры. - person ; 03.11.2013
comment
Извините, что вы подразумеваете под сортировкой массива шахматных фигур по X и Y? - person John V; 03.11.2013
comment
(во втором решении), например, рассмотрим ход солдата (1 вперед), поэтому вам нужно проверить весь список массивов, чтобы обработать, возможно ли движение или нет, поэтому я говорю, что пока есть 32 шахматные фигуры, и только одна chessman ограничит (отклонит) движение, если массив отсортирован по x и y позициям шахматной фигуры, поэтому вам не нужно каждый раз проверять весь массив, просто проверяйте близлежащие индексы. - person ; 03.11.2013
comment
о точно, спасибо. Итак, если бы вы реализовали шахматы, у вас вообще не было бы массива квадратов? Я видел диаграмму, на которой Board содержит ссылки на 64 квадрата и наборы частей, где каждая часть содержит ссылку на квадрат, которому она принадлежит. - person John V; 03.11.2013
comment
Если честно, то в этом случае ваш случай может быть и лучше, я просто упоминаю, что мы можем рассчитывать на ЦП больше, чем на ОЗУ, но здесь массив длиной 64 не очень большая вещь, кроме того, ваше решение очень простое процесс, чем мой. но, конечно, здесь было бы лучшее решение, мне просто нужно немного кофе, чтобы подумать глубже - person ; 03.11.2013