Здравствуйте, уважаемые форумчане. Не могу разобраться чем отличается реализация отношения ассоциации от агрегации и композиции в коде например в java или си шарпе? Во всех трех случаях необходимо создать в классе поле объектного типа. А в чем разница между ними я не могу понять. Ведь каждое отношение является самостоятельным.

Разница как раз в реализации.

Ассоциация - это семантическая концепция, а агрегация или композиция - реализация связи в коде. Ассоциация в общем смысле связь типа has a, т.е. связь принадлежности. В зависимости от силы связи принадлежности - она сводится или к агрегации (share) или композиции.

С другой стороны можно привести и ассоциации типа многие-ко-многим, которые не могут быть сведены к агрегации или композиции.

Если я вас правильно понял, то однонаправленная ассоциация это как-бы абстрактное понятие, которое используется на начальном этапе проектирования и впоследствии в коде уже принимает вид либо агрегации, либо композиции. Верно я уловил смысл?

Если я вас правильно понял, то однонаправленная ассоциация это как-бы абстрактное понятие, которое используется на начальном этапе проектирования и впоследствии в коде уже принимает вид либо агрегации, либо композиции. Верно я уловил смысл?

Не совсем. Я не говорил об однонаправленности. Одно или дву направленность - это другой момент. Кстати тоже относящийся к реализации.
Ассоциация - это абстракция связи. Ассоциация отражает отношение между двумя и более классами. Агрегация и композиция - частный случай ассоциации, определяющий более точный смысл такой связи.
Просто прямое воплощение ассоциации по смыслу (но не всегда) сводится к агрегации или композиции.

Здравствуйте, уважаемые форумчане. Не могу разобраться чем отличается реализация отношения ассоциации от агрегации и композиции в коде например в java или си шарпе? Во всех трех случаях необходимо создать в классе поле объектного типа. А в чем разница между ними я не могу понять. Ведь каждое отношение является самостоятельным.

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

Примеры здесь:
http://ootips.org/uml-hasa.html

Спасибо, что помогли разобраться мне с темой отношений между классами. У меня возник еще один вопрос. Ассоциация (и ее подвиды агрегация и композиция) позволяет представить программу в виде связанных друг с другом объектов. Какова форма этой структуры объектов? Она представляет собой дерево иерархии (как и в случае с иерархией наследования классов) или граф с циклическими связями между объектами?

[Раз пошла такая тема]
Является ли объект-часть вложенным в объект-целое или нет, зависит от "многих гитик". Композиция так таковая (без рассмотрения её мощностей) в плане существования частей накладывает ограничение лишь на то, что все части целого, какие не успели отцепиться в момент удаления целого, также удаляются.

[Раз пошла такая тема]
Является ли объект-часть вложенным в объект-целое или нет, зависит от "многих гитик". Композиция так таковая (без рассмотрения её мощностей) в плане существования частей накладывает ограничение лишь на то, что все части целого, какие не успели отцепиться в момент удаления целого, также удаляются.

Кто такие гитики?

Может ли квартира отцепиться от дома?

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

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

а по-русски?

Прошу прощения, ксенолингвистический гаджет барахлит.
Если Вы хотите в модели показать, что объект-часть существует внутри объекта-целого, то для этого Вы рисуете диаграмму составной структуры (composite structure diagram). Сама по себе композиция, нарисованная на диаграмме классов не накладывает ограничений на то, чтобы части жили именно внутри целого.
Если Вы хотите в модели показать, что объект-часть в течение своей жизни не может сменить хозяина -- объект-целое --, как в Вашем примере с квартирой, то Вы пишете возле чёрного ромба {readOnly}, или как когда-то писали {frozen}. Если такой пометки нет, то [по умолчанию] композиция позволяет менять хозяина. [По умолчаию] она не обладает стационарностью.

Прошу прощения, ксенолингвистический гаджет барахлит.
Если Вы хотите в модели показать, что объект-часть существует внутри объекта-целого, то для этого Вы рисуете диаграмму составной структуры (composite structure diagram). Сама по себе композиция, нарисованная на диаграмме классов не накладывает ограничений на то, чтобы части жили именно внутри целого.
Если Вы хотите в модели показать, что объект-часть в течение своей жизни не может сменить хозяина -- объект-целое --, как в Вашем примере с квартирой, то Вы пишете возле чёрного ромба {readOnly}, или как когда-то писали {frozen}. Если такой пометки нет, то [по умолчанию] композиция позволяет менять хозяина. [По умолчаию] она не обладает стационарностью.

Хм, а в таком случае чем композиция отличается от агрегации? Без этих уточняющих признаков?

Гм. Видимо, важно добавить, что всюду у меня речь об UMLьных агрегациях и UMLьных композициях.
По UMLю композиция -- это усиленная форма агрегации, отличающаяся тем, что при композиции:
1) у части не может быть больше одного целого;
2) все части, имеющиеся у целого в момент его удаления также удаляются.

Гм. Видимо, важно добавить, что всюду у меня речь об UMLьных агрегациях и UMLьных композициях.
По UMLю композиция -- это усиленная форма агрегации, отличающаяся тем, что при композиции:
1) у части не может быть больше одного целого;
2) все части, имеющиеся у целого в момент его удаления также удаляются.

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

Похожие раскопки делали тут же на форуме в части диаграмм состояний. Думаю, что можно попытаться раскопать, кто же выдумал композицию с агрегацией, что он на самом деле имел в виду, до того как всё испортили авторы стандарта UML.)