Применяется ли композиция к реализованному классу при создании интерфейса? - PullRequest
Новая
       22

Применяется ли композиция к реализованному классу при создании интерфейса?

1 голос
/ 05 марта 2020

Существует класс A, интерфейс IB и класс B, который реализует интерфейс IB. Класс A имеет поле типа IB. Во время выполнения программы значение этого поля становится экземпляром класса B. Как нарисовать диаграмму классов для этой ситуации? Есть ли «составные» отношения между A и IB, а составные - это отношения между A и B или просто зависимость?

1 Ответ

3 голосов
/ 05 марта 2020

Это зависит от языка и / или семантики, которую вы хотите придать вашей конструкции.

На языке со ссылочными классами, такими как java:

  • , экземпляр B всегда может быть общим и, следовательно, продолжать жить после смерти объекта A. Это противоречит композиции в UML.
  • агрегация позволит разделить B. Но, к сожалению, семантика агрегации не очень хорошо определена в UML и поэтому неоднозначна.
  • нормальная ассоциация будет правильной и однозначной.

В языке с классами, основанными на значениях, таких как C ++:

  • композиция будет соответствующим образом представлять совместный жизненный цикл объектов
  • в вашем случае, однако, ИБ будет полиморпи c. Полиморфизм потребует указатель. Если бы вы использовали unique_ptr<IB>, вы бы express сочинили. Другие указатели могут разрешать совместное использование объектов, поэтому нормальное сопоставление будет лучшим представлением.

Но UML не является языком программирования. Это язык моделирования. Таким образом, вы должны express в модели семанти c, что вы хотите. Если ожидается, что объекты IB не будут совместно использоваться и не должны пережить A, то соответствующая композиция показывает это намерение. Если нет, оставайтесь открытыми.

...