В проектировании баз данных , объектно-ориентированном программировании и проектировании has -a ( has_a или has a ) — это отношение композиции , при котором один объект (часто называемый составным объектом или объектом-частью/составляющей/членом) «принадлежит» (является частью или объектом-членом). член ) другого объекта (называемого составным типом) и ведет себя в соответствии с правилами владения. Проще говоря, отношение has-a в объекте называется полем-членом объекта. Множественные отношения «имеет-а» объединятся, образуя притяжательную иерархию.
«Has-a» следует противопоставлять отношениям is-a ( is_a или is a ), которые составляют таксономическую иерархию ( подтипирование ).
Решение о том, является ли наиболее логичным отношением для объекта и его подчиненного объекта, не всегда является очевидным: has-a или is-a . Путаница по поводу таких решений привела к необходимости создания этих металингвистических терминов. Хорошим примером отношения has-a являются контейнеры в C++ STL .
Подводя итоги отношений, мы имеем
В базах данных отношения «имеет-а» обычно представляются в модели «сущность-отношения» . Как вы можете видеть на диаграмме справа, учетная запись может иметь несколько символов. Это показывает, что аккаунт имеет отношение «есть» к персонажу.
В объектно-ориентированном программировании эту связь можно представить с помощью диаграммы классов унифицированного языка моделирования . Это отношение также известно как композиция. Как вы можете видеть из диаграммы классов справа, автомобиль «имеет» карбюратор или автомобиль «состоит из» карбюратора. Когда алмаз окрашен в черный цвет, это означает композицию , то есть объект на стороне, ближайшей к алмазу, состоит из другого объекта или содержит его. Белый ромб означает агрегацию , что означает, что объект, ближайший к ромбу, может обладать другим объектом или владеть им.
Другой способ отличить композицию от агрегации при моделировании реального мира — учитывать относительное время жизни содержащегося объекта. Например, если объект «Автомобиль» содержит объект «Шасси», скорее всего, шасси не будет заменено в течение срока службы автомобиля. Срок его службы будет такой же, как и у самого автомобиля; таким образом, отношения являются составными . С другой стороны, если объект «Автомобиль» содержит набор объектов «Шины», эти объекты «Шины» могут изнашиваться и заменяться несколько раз. Или, если Автомобиль станет непригодным для использования, некоторые Шины могут быть утилизированы и переданы другому Автомобилю. В любом случае время жизни объектов Tire отличается от времени жизни объекта Car; поэтому отношения являются отношениями агрегации .
Если бы кто-то создал программный класс C++ для реализации описанных выше отношений, объект Car содержал бы полный объект Chassis в элементе данных. Этот объект Chassis будет создан в конструкторе класса Car (или определен как тип данных элемента данных и его свойства, назначенные в конструкторе). И поскольку это будет полностью содержащийся элемент данных класса Car, Chassis объект больше не существовал бы, если бы объект класса Car был удален.
С другой стороны, члены данных класса Car, указывающие на объекты Tire, скорее всего, будут указателями C++. Объекты Tire можно создавать и удалять извне или даже присваивать элементам данных другого объекта Car. Объекты «Шины» будут иметь независимое время жизни, отдельное от момента удаления объекта «Автомобиль».