Форум Сообщества Аналитиков
Дисциплины => Реализация => Тема начата: Максим от 23 Октября 2014, 16:56:00
-
Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?
-
Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?
Нет однозначного соответствия между отношениями и способом реализации в коде. И композицию, и агрегацию можно реализовать одним и тем же кодом.
Можно устанавливать связь в конструкторе и разрывать в деструкторе. Имеет смысл, если агрегируемый используется объект на всём протяжении жизни агрегатора.
Можно использовать отдельную функцию инициализации объекта, вызываемую после его создания.
Можно подключать и отключать агрегируемые объекты отдельными методами, например, при обработке событий. Имеет смысл, если в процессе жизни агрегатора агрегируемые объекты могут изменяться. Или если агрегатор может выполнять какие-то функции вообще без агрегируемых объектов.
Вообще, по моему мнению, однозначное соответствие между моделью отношений и кодом возможно только в самых примитивных проектах - по большей части учебных. В реальной жизни всегда находится компромисс между соответствием абстрактной модели, читаемостью, сопровождаемостью и универсальностью кода, совместимостью с существующими наработками и прочими нефункциональными требованиями, вроде требований к производительности.
-
Получается, что связь между классом контейнером и включаемыми в него объектами можно установить как в теле конструктора, так и в любом другом методе этого класса, в любое время. Если объекты создаются в теле конструктора или любого другого метода, то это композиция. Если же объекты приходят извне и передаются как аргументы конструктора или метода, то это агрегация. Таким образом мы уже будем знать что произойдет с включаемыми объектами после уничтожения класса-контейнера. В случае ассоциации же, в классе просто объявляются объектные поля без уточнения как будет устанавливаться связь, т.е. откуда будут приходить включаемые объекты снаружи класса или создаваться в этом контейнере. Верно я понял реализацию этих трех отношений?
-
Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?
[Трёпа ради прилечу.]
Если композиция такова, что объект-целое обязателен, и объект-часть обязателен, и объект-часть не может существовать сам по себе, например, Здание◆-1---1..*-Этаж, то обязательный этаж здания должен создаваться в конструкторе здания. Любой строитель подтвердит. (Экзотику, когда берут этаж от одного здания и передают в другое, не рассматриваем.)
Если композиция такова, что объект-целое необязателен, , а объект-часть обязателен, и объект часть может существовать сам по себе, например, Авто◆-0..1---3..8-Колесо, то три обязательных колёса можно создавать раньше авто и передавать ему при вызове конструктора.
Т. е. исходный вопрос не про композицию/агрегацию, а про композицию со специфическими мощностями.
-
[Трёпа ради прилечу.]
Если композиция такова, что объект-целое необязателен, , а объект-часть обязателен, и объект часть может существовать сам по себе, например, Авто◆-0..1---3..8-Колесо, то три обязательных колёса можно создавать раньше авто и передавать ему при вызове конструктора.
Простите, но это же агрегация, а не композиция. Колесо же не может быть произведено как часть необязательной композиции. Это нонсенс, но может быть произведено само себе и употреблено как часть автомобиля. Другое дело, что автомобиль накладывает определенные ограничения на вид такого колеса
-
Про колесо придумал Конрад Бок: http://www.jot.fm/issues/issue_2004_11/column5/
Это один из "друзей" "3-х друзей" -- в смысле, разработчик стандарта.
-
Про колесо придумал Конрад Бок: http://www.jot.fm/issues/issue_2004_11/column5/
Это один из "друзей" "3-х друзей" -- в смысле, разработчик стандарта.
И что. Мне следует пасть ниц? Если нелогично, почему нужно следовать авторитету?
-
Я лишь попыталось пояснить свой ответ.
-
Я лишь попыталось пояснить свой ответ.
Тогда нужно прояснить семантику понятия композиция и семантику понятия агрегация. Ведь еще Конфуция замечал, что все непорядки от неточно данного понятия или неправильно понимаемого понятия.
Давайте по понятиям?? Пройдемся ...
-
Семантика umlьная. Другой на моей планете нет, не завезли.
-
[deleted]
-
Я с планеты 7ми пятниц.
Как бы не соскочить в офтопик и не раздосадовать модератора.
Пока модераторы спят .. на страницы форума пробираются инопланетяне
-
"Don’t worry about the diamonds" -- наставляет Скот Амблер в своём "The Elements of UML 2.0 Style". При этом на его диаграмму из сопроводиловки лучше не смотреть, чтобы не терзаться популярным на здешней планете вопросом: "А что у Вас, ребята, в головах?"
-
Композиция: Элемент-источник является частью и не может существовать без целевого элемента.
Агрегация: Элемент-источник является частью и может существовать отдельно целевого элемента.
-
Композиция: Элемент-источник является частью и не может существовать без целевого элемента.
А если при черном ромбе будет не 1..1, а 0..1?
Агрегация: Элемент-источник является частью и может существовать отдельно целевого элемента.
А если при белом ромбе будет 1..1 или 1..*?
Конечно при условии:
Семантика umlьная. Другой на моей планете нет, не завезли.
-
А если при черном ромбе будет не 1..1, а 0..1?А если при белом ромбе будет 1..1 или 1..*?
Конечно при условии:
А зачем там отношения, используемые в ассоциациях?)))
-
А зачем там отношения, используемые в ассоциациях?)))
Композиция и агрегация являются ассоциациями с дополнительными ограничениями (транзитивное замыкание антирефлексивно - нельзя быть композитом/агрегатом самому себе ни непосредственно, ни опосредованно; композитов не может быть более одного; ...).
-
Композиция и агрегация являются ассоциациями с дополнительными ограничениями (транзитивное замыкание антирефлексивно - нельзя быть композитом/агрегатом самому себе ни непосредственно, ни опосредованно; композитов не может быть более одного; ...).
Я пользуюсь в работе агрегацией без дополнительных отношений ассоциации. Отношения я прописываю на ассоциации между элементами модели.
-
Я пользуюсь в работе агрегацией без дополнительных отношений ассоциации. Отношения я прописываю на ассоциации между элементами модели.
Как будут выглядеть такие ситуации (в них, как я понимаю, отношения прописаны прямо на композиции).
Здание◆-1---1..*-Этаж
Авто◆-0..1---3..8-Колесо
-
Как будут выглядеть такие ситуации (в них, как я понимаю, отношения прописаны прямо на композиции).
Хотелось бы работающий производственный пример, а не рассуждения как должно быть))) Мне перегружать агрегацию нет необходимости и даже композицией особо не пользуюсь.
-
Я, в свою очередь, предлагаю голосовать. Или разыскать стандарт и прочесть.
Между "часть не может существовать без целого" и "при уничтожении целого уничтожаются также и части в его составе" есть некоторая разница.
-
Или разыскать стандарт и прочесть.
"If a composite object is deleted, all of its part instances that are objects are deleted with it." (UML 2.5, 9.5.3., стр. 110)
Между "часть не может существовать без целого" и "при уничтожении целого уничтожаются также и части в его составе" есть некоторая разница.
"часть не может существовать без целого" - структурное ограничение, а "при уничтожении целого уничтожаются также и части в его составе" - одно (но не единственное!) из поведений, которое обеспечивает выполнение этого структурного ограничения.
-
"... которое обеспечивает выполнение этого структурного ограничения.
Или не обеспечивает.)
-
Или не обеспечивает.)
Не понял: если при уничтожении Здания уничтожаются и Этажи в его составе, то не может возникнуть ситуация, что Этаж есть, но он не связан ни с каким Зданием - структурное ограничение выполняется.
-
Колесо можно открутить и лишь потом расхреначить авто.)
Композиция с 0..1 у ромба позволяет части существовать без целого (части [?]чего[?], спрашивается).
Фархутдинов пишет: ..in some cases a part can be removed from a composite before the composite is deleted, and so is not necessarily deleted as part of the composite.
-
Ладно, не буду вам мешать)))