Читая книгу Крейга Лармана (Применение UML и шаблонов;...), я заметил, что он добавил экземпляры класса Die в качестве атрибутов в класс DiceGame.
.
Является ли это возможным? и есть много связанных вопросов по программированию, где они отрицают сделать это.
Я бы изменил вопрос на "Могут ли ссылки на любой класс рассматриваться как атрибуты в другом классе?" Технически ответ «да», но вы не должны моделировать это таким образом в UML. Вы должны моделировать простые значения как атрибуты (внутри прямоугольника класса), а непростые ссылки моделировать как ассоциации. Простые значения идентифицируются только их значениями (например, число 5), тогда как непростые ссылки указывают на вещи с идентичностью. В вашем случае каждый Die должен иметь идентификатор, отличный от его текущей номинальной стоимости. Следовательно, вы не должны моделировать атрибуты типа Die, вы должны моделировать свойство в конце ассоциации.
На опубликованной вами диаграмме есть три (!!) свойства типа Die. Один называется die1, один называется die2, а третий безымянный с кратностью 2. На языке программирования это дало бы вам четыре места для хранения ссылок на игральные кости, что явно неверно.
Я бы смоделировал это следующим образом:
Когда вы создаете код (или транскрибируете его вручную), свойство dice становится переменной-членом в DiceGame. Эта переменная-член обычно типизируется коллекцией в вашем языке программирования, но ее также можно смоделировать как массив. Эта коллекция или массив позволяет вам получить доступ к обоим кубикам.
Обратите внимание, что ассоциация является однонаправленной. Это потому, что Die, вероятно, не нужен доступ к Dice Game. (Однако, если вам нужно, чтобы каждый Die был активным объектом, работающим в своем собственном потоке, вам может понадобиться, чтобы ассоциация была двунаправленной, чтобы каждый Die мог отправлять сигнал, когда он закончил работу или что-то в этом роде.)
Это не экземпляры Die, а просто два свойства типа Die. На картинке не очень удачное использование UML (позор Ларману). Связь между DiceGame и Die использует кратность 2. И, скорее всего, он имеет в виду die1 и die2. Но это было бы угадыванием. Лучшее обозначение было бы
с соответствующими именами конца ассоциации.
Краткий ответ: да... и это случается очень часто.
В объектно-ориентированной архитектуре есть изящный маленький трюк, позволяющий выяснить, должен ли класс содержать свойство какого-либо другого типа класса: "Is-A" и "Has-A".
В этом случае у вас есть класс DiceGame. Вы спрашиваете себя: «Является ли DiceGame кубиком» или DiceGame «Has-A» умирает. Если ответ первый, то вы используете наследование, в противном случае вы устанавливаете его как свойство (я), как в опубликованном вами примере.
Если бы у вас был другой класс под названием «GamblingRoom», наличие DiceGame свойства этого класса «GamblingRoom» «могло бы» быть жизнеспособным решением... конечно, в зависимости от того, что вам нужно делать.
Вот лучшее объяснение этого в вопросе, аналогичном тому, что у вас есть ... но, вероятно, лучше объяснено, чем то, что я сделал здесь;)
терминология HAS-A, IS-A в объектно-ориентированном языке
Это не только возможно, это стандартный случай. На самом деле, многие языки программирования не делают большой разницы между классами и элементарными типами данных, такими как int.
Да, это возможно. ООП обеспечивает отношение контейнера, что означает имеет отношение, в котором один класс может содержать экземпляры другого класса.
Например, может быть класс стула, класс стола и класс комнаты. Теперь в комнате могут быть стулья и столы, поэтому класс комнаты будет иметь экземпляр стульев и столов.
