Как определить это классовое отношение
Это моя диаграмма классов UML (URL)
На приведенной выше диаграмме ChildParent (или Child1, Child2 и Child3) можно инициализировать только в MainObject->create_new_object() и сохранить его в классе Library через ObjectData->lib->add_object(key, newObject).
Итак, как определить отношения класса UML между ChildParent, Library и MainObject?
Спасибо
1 ответ
Отношения между классами являются структурными, а не поведенческими. MainObject создает его, но не контролирует срок его жизни и не владеет им никоим образом. После создания он передается в ObjectData, транспортируется в библиотеку и сохраняется там. Между MainObject и объектом ChildParent существует поведенческая связь, но между ними нет структурной связи. Я не должен изображать какие-либо отношения между ними.
Библиотека хранит его. Это типичная целая часть отношений и структурная. Что такое библиотека без книг? Поэтому я бы использовал тип агрегации. Это не композиция, поскольку библиотека не контролирует продолжительность жизни какого-либо объекта ChildParent или Child и не подразумевает, что ChildObject будет уничтожен при уничтожении объекта Library. Это может произойти, но, учитывая представленные данные, мне это не ясно.
РЕДАКТИРОВАТЬ в качестве ответа на комментарий:
Диаграммы классов показывают структурные отношения между классами, а не их использование. Когда класс реализует интерфейс, вы увидите это соотношение на диаграмме. В коде (поведении) вы могли бы не видеть эту связь, потому что реализация скрыта в методе фабрики или предоставляется контейнером IoC, или это может быть даже связь, которая никогда не используется.
Каковы отношения между классом (вызывающим), который выбирает класс (вызываемый) из библиотеки, и между вызывающим и библиотекой? Очевидно, что вызывающая сторона и библиотека имеют поведенческие отношения. Если модуль изменяется, может ли вызывающий абонент получить своего вызываемого из какого-либо другого класса. Поэтому библиотека и вызывающая сторона не будут иметь отношения в диаграмме классов. Существует структурная связь между вызывающим абонентом и вызываемым абонентом. Вызывающий абонент нуждается в вызываемом абоненте. Ваш комментарий не определяет точную связь между ними, но есть связь. Самая слабая форма - это отношения зависимости. Примером, связанным с библиотекой, является то, что человек одалживает книгу из библиотеки. Когда он начинает читать книгу, используется вызываемый абонент. Он не принадлежит человеку в целом, но он принадлежит определенному методу класса человека. Есть много способов реализовать библиотеку. Это может быть, например, гардероб. Каковы отношения между человеком в армии и его униформой? В определенных ситуациях ему необходимо носить форму, но в других ситуациях запрещается носить эту форму. Ношение униформы является частью класса военных. Нельзя быть в армии, не надев форму во время службы. В тот момент, когда вы вышли из армии, вы больше не можете носить форму. Отсюда и военная композиционная связь с этой формой из его гардероба.
Существует больше типов отношений между вызывающим абонентом и вызываемым абонентом. Вы не можете сказать это заранее. Вы должны ответить на него так же, как и любые другие отношения. Первый вопрос очень ясен: это структурные отношения или нет? Ключевые слова типа "есть" и "имеет" обозначают структурные отношения. Ключевые слова, такие как "использует", "просит", "выбирает из", показывают поведенческие отношения. Вы пришли к выводу, что это структурные отношения, тогда вы должны выяснить, какова зависимость между двумя классами.