Составные отношения в объектно-ориентированном программировании
Has-a
Композиция в ООП: отношения "часть-целое", владение объектами, членские поля. Реализация в базах данных и ER-моделях. Объектно-ориентированное программирование.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Отношения композиции в объектно-ориентированном программировании
Composition relationship in object oriented programming
В проектировании баз данных, объектно-ориентированном программировании и проектировании, отношение "имеет" (или "состоит из") является отношением композиции, где один объект (часто называемый составным объектом, или частью/компонентом/элементом) "принадлежит" (является частью или элементом) другого объекта (называемого композитным типом) и ведет себя в соответствии с правилами владения. Проще говоря, отношение "имеет" в объекте называется полем-членом объекта. Множество отношений "имеет" объединяются, формируя иерархию владения.
In database design, object oriented programming and design, has a (has a or has a) is a composition relationship where one object (often called the constituted object, or part/constituent/member object) "belongs to" (is part or member of) another object (called the composite type), and behaves according to the rules of ownership. In simple words, has a relationship in an object is called a member field of an object. Multiple has a relationships will combine to form a possessive hierarchy.
Модель отношений между субъектами
В базах данных отношения обычно представляются в ER-модели (Entity-Relationship). Как видно на диаграмме справа, у аккаунта может быть несколько персонажей. Это показывает, что аккаунт имеет отношение "имеет" к персонажу.
In databases has a relationships are usually represented in an Entity–relationship model. As you can see by the diagram on the right an account can have multiple characters. This shows that account has a "has a" relationship with character.
Диаграмма классов UML
В объектно-ориентированном программировании это отношение можно представить с помощью диаграммы классов языка унифицированного моделирования (UML). Это отношение также известно как композиция. Как видно из диаграммы классов справа, автомобиль "имеет" карбюратор, или автомобиль "состоит из" карбюратора. Если ромб закрашен черным цветом, это указывает на композицию, то есть объект со стороны, ближайшей к ромбу, состоит из другого объекта или содержит его. В то время как белый ромб указывает на агрегацию, что означает, что объект, ближайший к ромбу, может иметь или владеть другим объектом.
In object oriented programming this relationship can be represented with a Unified Modeling Language Class diagram. This has a relationship is also known as composition. As you can see from the Class Diagram on the right a car "has a" carburetor, or a car is "composed of" a carburetor. When the diamond is coloured black it signifies composition, i. e. the object on the side closest to the diamond is made up of or contains the other object. While the white diamond signifies aggregation, which means that the object closest to the diamond can have or possess the other object.
C++
Другой способ различать композицию и агрегацию при моделировании реального мира — рассмотреть относительный срок службы содержащегося объекта. Например, если объект «Автомобиль» содержит объект «Шасси», то «Шасси», скорее всего, не будет заменено в течение срока службы «Автомобиля». Оно будет иметь такой же срок службы, как и сам «Автомобиль», следовательно, отношения будут композиционными. С другой стороны, если объект «Автомобиль» содержит набор объектов «Шина», эти объекты «Шина» могут изнашиваться и заменяться несколько раз. Или, если «Автомобиль» станет непригодным для использования, некоторые «Шины» могут быть сохранены и использованы для другого «Автомобиля». В любом случае, объекты «Шина» имеют срок службы, отличный от срока службы объекта «Автомобиль»; следовательно, отношения являются агрегационными. Если бы кто-то создавал программный класс C++ для реализации описанных выше отношений, объект «Автомобиль» содержал бы полный объект «Шасси» в качестве члена данных. Этот объект «Шасси» был бы создан в конструкторе класса «Автомобиль» (или определен как тип данных члена данных, а его свойства присвоены в конструкторе). И поскольку это был бы полностью содержащийся член данных класса «Автомобиль», объект «Шасси» перестал бы существовать при удалении объекта класса «Автомобиль». С другой стороны, члены данных класса «Автомобиль», указывающие на объекты «Шина», скорее всего, были бы указателями C++. Объекты «Шина» могли бы быть созданы и удалены вне класса, или даже назначены членам данных другого объекта «Автомобиль». Объекты «Шина» имели бы независимый срок службы, отличный от срока службы объекта «Автомобиль».
Another way to distinguish between composition and aggregation in modeling the real world, is to consider the relative lifetime of the contained object. For example, if a Car object contains a Chassis object, a Chassis will most likely not be replaced during the lifetime of the Car. It will have the same lifetime as the car itself; so the relationship is one of composition. On the other hand, if the Car object contains a set of Tire objects, these Tire objects may wear out and get replaced several times. Or if the Car becomes unusable, some Tires may be salvaged and assigned to another Car. At any rate, the Tire objects have different lifetimes than the Car object; therefore the relationship is one of aggregation. If one were to make a C++ software Class to implement the relationships described above, the Car object would contain a complete Chassis object in a data member. This Chassis object would be instantiated in the constructor of the Car class (or defined as the data type of the data member and its properties assigned in the constructor.) And since it would be a wholly contained data member of the Car class, the Chassis object would no longer exist if a Car class object was to be deleted. On the other hand, the Car class data members that point to Tire objects would most likely be C++ pointers. Tire objects could be instantiated and deleted externally, or even assigned to data members of a different Car object. Tire objects would have an independent lifetime separate from when the Car object was deleted.