Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

В информатике , состав объекта является способом объединить объекты или тип данных в более сложные. Обычные виды композиций - это объекты, используемые в объектно-ориентированном программировании , помеченные объединения , наборы , последовательности и различные структуры графов . [1] Композиции объектов относятся к структурам данных, но не совпадают с ними.

Состав объекта относится к логической или концептуальной структуре информации, а не к реализации или физической структуре данных, используемой для ее представления [ необходима цитата ] . Например, последовательность отличается от набора, потому что (среди прочего) порядок составных элементов имеет значение для первого, но не для второго. Структуры данных, такие как массивы , связанные списки , хеш-таблицы и многие другие, могут использоваться для реализации любого из них. Возможно, сбивает с толку то, что одни и те же термины используются как для структур данных, так и для композитов. Например, « двоичное дерево"может относиться к любому: как структура данных, это средство доступа к линейной последовательности элементов, и фактические позиции элементов в дереве не имеют значения (дерево может быть внутренне переупорядочено по своему усмотрению, без изменения его значения). Однако, как объектная композиция, позиции релевантны, и их изменение изменит значение (как, например, в кладограммах ) [ необходима цитата ] .

Техника программирования [ править ]

Объектно-ориентированное программирование основано на объектах для инкапсуляции данных и поведения. Он использует два основных метода для сборки и компоновки функциональных возможностей в более сложные: подтипирование и композиция объектов. [2] Композиция объектов - это объединение объектов в составные объекты и в то же время обеспечение инкапсуляции каждого объекта с помощью их четко определенного интерфейса без видимости их внутренних компонентов. В этом отношении состав объектов отличается от структур данных, которые не обеспечивают инкапсуляцию.

Состав объекта также может включать группу из нескольких связанных объектов, например набор или последовательность объектов. Делегирование может обогатить композицию, перенаправляя запросы или вызовы включающего составного объекта в один из его внутренних компонентов. [3]

В классе -и набранный языки программирование, тип можно разделить на композитные и несоставные тип, и состав можно рассматривать как отношения между типами: объект составного типа (например , автомобилем ) « имеют » объекты других типов ( например колесо ). Когда составной объект содержит несколько подобъектов одного и того же типа, им могут быть назначены определенные роли , часто различающиеся по именам или номерам. Например, объект Point может содержать 3 числа, каждое из которых представляет расстояние по разным осям, например «x», «y» и «z». Изучение отношений части и целого в целом - мереология .

Композицию следует отличать от подтипов , которые представляют собой процесс добавления деталей к общему типу данных для создания более конкретного типа данных. Например, автомобили могут быть определенным типом транспортных средств: автомобиль - это транспортное средство . Подтипирование не описывает отношения между разными объектами, но вместо этого говорит, что объекты одного типа одновременно являются объектами другого типа. Изучение таких отношений - онтология .

В языках программирования на основе прототипов, таких как JavaScript , объекты могут динамически наследовать поведение от объекта-прототипа в момент их создания. Композицию следует отличать от прототипирования: вновь созданный объект наследует композицию своего прототипа, но сам может быть составлен сам по себе.

Составные объекты могут быть представлены в хранилище путем совместного размещения составных объектов, совместного размещения ссылок или многих других способов. Элементы в составном объекте могут называться атрибутами , полями , членами , свойствами или другими именами, а результирующая композиция - составным типом , записью хранилища , структурой , кортежем или определяемым пользователем типом (UDT) . Подробнее см. В разделе агрегирования ниже.

Техника моделирования UML [ править ]

Композиция объектов с использованием свойств UML для компоновки объектов

В моделировании UML объекты могут быть концептуально скомпонованы независимо от реализации с помощью языка программирования. В UML есть четыре способа компоновки объектов: свойство, ассоциация, агрегирование и композиция: [4]

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

Отношения между агрегатом и его компонентами являются слабыми отношениями типа «имеет-а»: компоненты могут быть частью нескольких агрегатов, могут быть доступны через другие объекты без прохождения агрегата и могут пережить агрегированный объект. [4] Состояние объекта-компонента по-прежнему составляет часть совокупного объекта. [ необходима цитата ]

Отношения между составным элементом и его частями являются сильными отношениями «имеет-а»: составной объект несет единоличную « ответственность за существование и хранение составных объектов », составной объект может быть частью не более одного составного объекта и » При удалении составного объекта все экземпляры его частей, являющиеся объектами, удаляются вместе с ним ". Таким образом, в UML композиция имеет более узкое значение, чем обычная композиция объектов.

Нотация UML для ассоциации, композиции и агрегирования

Графическое обозначение представляет:

  • свойство как типизированный элемент в поле включающего класса,
  • ассоциация как прямая линия между ассоциированными классами,
  • агрегации , как незаполненный алмаз на стороне агрегата и сплошную линии,
  • композиция в виде закрашенного ромба сбоку от композита и сплошной линии.


Особые формы [ править ]

Сдерживание [ править ]

Композиция, которая используется для хранения нескольких экземпляров составного типа данных, называется включением. Примерами таких контейнеров являются массивы , ассоциативные массивы , двоичные деревья и связанные списки .

В UML включение изображается с кратностью 0 .. * или 1 .. *, что указывает на то, что составной объект состоит из неизвестного числа экземпляров составного класса.

Рекурсивная композиция [ править ]

Объекты можно составлять рекурсивно, и их тип в таком случае называется рекурсивным типом . Примеры включают в себя различные виды деревьев , групп DAG и графов . Каждый узел в дереве может быть ветвью или листом; другими словами, каждый узел является деревом в то же время, когда он принадлежит другому дереву.

В UML рекурсивная композиция изображается как ассоциация, агрегация или композиция класса с самим собой.

Составной узор [ править ]

Композиционный шаблон проектирования является объектно - ориентированным дизайном на основе композиционных типов, который сочетает в себе рекурсивный состав и сдерживание для реализации сложной части-целого иерархии.

Составные типы в C [ править ]

Это является примером композиции в C .

struct  Person {  int  age ;  имя символа  [ 20 ]; enum { job_seeking , professional , non_professional , retired , student } трудоустройство ; };       

В этом примере примитивные (несоставные) типы int , enum {job_seeking, professional, non_professional, retired, student} и тип составного массива char [] объединены, чтобы сформировать составную структуру Person . У каждой структуры Person "есть" возраст, имя и тип занятости.

Хронология композиции на разных языках [ править ]

C называет запись структурой или структурой; объектно-ориентированные языки, такие как Java , Smalltalk и C ++, часто скрывают свои записи внутри объектов ( экземпляров классов ); языки в семействе машинного обучения просто называют их записями. COBOL был первым широко распространенным языком программирования, который напрямую поддерживает записи; [5] АЛГОЛ 68 получил его от COBOL, а Паскаль получил его, более или менее косвенно, от АЛГОЛА 68. Common Lisp предоставляет структуры и классы (последний черезОбщая объектная система Lisp ). [ необходима цитата ]

1959 - КОБОЛ
 01 запись о клиенте . 03 номер заказчика рис. 9 (8) комп . 03 имя клиента . 05 даные имена pic x (15) . 05 начальная-2 рис х . 05 фамилия рис х (15) . 03 адрес заказчика . 05 ул . 07 название улицы pic x (15) . 09 номер дома рис 999 комп . 05 город рис х (10) . 05 код страны рис x (3)                                . 05 почтовый индекс рис х (8) . 03 сумма долга рис 9 (8) комп .       
1960 - АЛГОЛ 60

Массивы были единственным составным типом данных в Algol 60 .

1964 - PL / I
dcl 1 на основе newtypet (P); 2 (а, б, в) фиксированный бункер (31), 2 (i, j, k) с плавающей точкой, 2 р птр;выделить newtypet;
1968 - АЛГОЛ 68
int max = 99;режим newtypet = [0..9] [0..max] struct ( длинный вещественный a, b, c, короткий int i, j, k, ref вещественный r);newtypet newarrayt = (1, 2, 3, 4, 5, 6, настоящая куча: = 7)

Например, связанный список может быть объявлен как:

узел режима = объединение (вещественное, целое, совместное, строковое) list = struct (узел val, ref list next);

Для АЛГОЛА 68 только имя типа появляется слева от равенства, и, что особенно важно, конструкция выполняется - и может быть прочитана - слева направо без учета приоритетов.

1970 - Паскаль
тип  а  =  массив  [ 1 .. 10 ]  из  целого числа ;  b  =  запись  a ,  b ,  c :  реальная ;  i ,  j ,  k :  целое число ;  конец ;
1972 - K&R C
#define max 99 struct  newtypet  {  double  a ,  b ,  c ;  float  r ;  короткие  i ,  j ,  k ; }  newarrayt [ 10 ]  [ макс  +  1 ];
1977 - ФОРТРАН 77

В Fortran 77 есть массивы, но отсутствуют какие-либо формальные определения записей / структур. Обычно составные структуры создавались с помощью операторов EQUIVALENCE или COMMON :

 СИМВОЛОВ ИМЯ * 32 ,  ADDR * 32 ,  ТЕЛЕФОН * 16  РЕАЛЬНОГО вследствие  ОБЩИЙ  / КЛИЕНТ / ИМЯ ,  АДРЕС ,  ТЕЛЕФОН ,  вследствие
1983 - Ада
тип  Cust  - это  запись  Name  :  Name_Type ;  Addr  :  Addr_Type ;  Телефон  :  Phone_Type ;  Принадлежит  :  Целочисленный  диапазон  1 .. 999999 ;  конец записи ;

В Ada 95 концепции ООП реализованы через тегированные типы (эквивалент класса C ++), в Ada 2012 добавлена ​​поддержка проверки подстановки с помощью общеклассовых контрактов.

1983 - C ++
const  int  max  =  99 ; class  {  public :  double  a ,  b ,  c ;  поплавок  & r ;  короткие  i ,  j ,  k ; } newtypet [ 10 ]  [ макс  +  1 ];
1991 - Питон
max  =  99 класс  NewTypeT :  def  __init__ ( self ):  self . а  =  себя . b  =  себя . c  =  0  сам . я  =  себя . j  =  себя . k  =  0.0 # Инициализировать примерный массив этого класса. newarrayt  =  [[ NewTypeT ()  для  i  в  диапазоне ( макс.  +  1 )] для  j  в  диапазоне ( 10 )]
1992 - FORTRAN 90

Массивы и строки были унаследованы от FORTRAN 77, и было введено новое зарезервированное слово: type

type newtypet  double precision a ,  b ,  c  integer * 2  i ,  j ,  k *  Без  указателя типа REF  REAL R  конечный типтип  ( newtypet )  t ( 10 ,  100 )

FORTRAN 90 обновил и включил концепцию FORTRAN IV под названием NAMELIST.

INTEGER  ::  jan  =  1 ,  feb  =  2 ,  mar  =  3 ,  apr  =  4 NAMELIST  /  week  /  jan ,  feb ,  mar ,  apr
1994 - ANSI Common Lisp

Common Lisp предоставляет структуры и классы CLOS, добавленные стандартом ANSI Common Lisp.

( defclass  some-class  ()  (( f  : тип с  плавающей точкой )  ( i  :  целое число типа )  ( a  : тип  ( целое число массива  ( 10 ))))) 

Дополнительные сведения о композиции в C / C ++ см. В разделе Составной тип .

Агрегация [ править ]

Агрегация отличается от обычного состава тем, что не предполагает владения. В композиции, когда объект-владелец уничтожается, то же самое происходит и с содержащимися объектами. В совокупности это не обязательно так. Например, в университете есть различные факультеты (например, химия ), и на каждом факультете есть несколько профессоров. Если университет закроется, факультеты перестанут существовать, но профессора на этих факультетах продолжат свое существование. Таким образом, университет можно рассматривать как совокупность кафедр, тогда как кафедры имеют совокупность профессоров. Кроме того, профессор может работать более чем на одном отделении, но отдел не может быть частью более чем одного университета.

Композиция обычно реализуется таким образом, что объект содержит другой объект. Например, в C ++ :

класс  профессора ;  // Определено в другом местеclass  Department  {  public :  Department ( const  std :: string &  title ) :  title_ ( title )  {} частный :  // Агрегация: | Профессора | может пережить | отдел |.  std :: vector < std :: weak_ptr < профессор >>  members_ ;  const  std :: string  title_ ; };class  University  {  public :  University ()  =  default ; private :  // Состав: | Отделения | существуют только до тех пор, пока существует факультет.  std :: vector < Кафедра >  faculty_  =  {  Кафедра ( «химия» ),  Кафедра ( «Физика» ),  Кафедра ( «Искусство» ,  }; };

В совокупности объект может содержать только ссылку или указатель на объект (и не нести ответственность за это на протяжении всей жизни ).

Иногда агрегацию называют составом, когда различие между обычным составом и агрегацией не имеет значения.

Приведенный выше код преобразуется в следующую диаграмму классов UML:

Агрегация в COM [ править ]

Агрегация в COM

В модели компонентных объектов Microsoft агрегация означает, что объект экспортирует, как если бы он был их владельцем, один или несколько интерфейсов другого объекта, которым он владеет. Формально это больше похоже на композицию или инкапсуляцию, чем на агрегацию. Однако вместо реализации экспортируемых интерфейсов путем вызова интерфейсов принадлежащего объекта, экспортируются сами интерфейсы принадлежащего объекта. Принадлежащий объект отвечает за обеспечение того, чтобы методы этих интерфейсов, унаследованные от IUnknownфактически вызывать соответствующие методы владельца. Это необходимо для гарантии того, что счетчик ссылок владельца верен и все интерфейсы владельца доступны через экспортированный интерфейс, в то время как другие (частные) интерфейсы принадлежащего объекта недоступны. [6]

См. Также [ править ]

  • Структура C ++
  • Составной тип
  • Состав над наследованием
  • Делегирование (программирование)
  • Функциональная композиция (информатика)
  • Имеет
  • Наследование реализации
  • Семантика наследования
  • Закон Деметры
  • Виртуальное наследование

Ссылки [ править ]

  1. ^ Мишель Язер . «Концепции объектно-ориентированного программирования: состав и агрегирование» . Adobe . Проверено 11 марта 2015 года . Композиция - это выражение отношений между объектами. Подумайте о примере стула. У стула есть сиденье. У стула есть спинка. А у стула есть набор ножек. Фраза «имеет» подразумевает отношения, при которых председатель владеет или, как минимум, использует другой объект. Именно эти отношения «есть» и лежат в основе композиции.
  2. ^ Шаблоны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования . Гамма, Эрих., Хелм, Ричард (специалист по информатике), Джонсон, Ральф Э., 1955-, Влиссидес, Джон. Ридинг, Массачусетс: Эддисон-Уэсли. 1995. ISBN. 0-201-63361-2. OCLC  31171684 .CS1 maint: другие ( ссылка )
  3. ^ Остерманн, Клаус; Мезини, Мира (1 октября 2001 г.). «Распутанная объектно-ориентированная композиция» . Уведомления ACM SIGPLAN . 36 (11): 283–299. DOI : 10.1145 / 504311.504303 . ISSN 0362-1340 . 
  4. ^ а б OMG (2017). «Спецификация единого языка моделирования версии 2.5.1» . www.omg.org . п. 109-110,197-201 . Проверено 4 октября 2020 года .
  5. ^ Себеста, Роберт В. Концепции языков программирования (Третье изд.). Addison-Wesley Publishing Company, Inc. стр. 218 . ISBN 0-8053-7133-8.
  6. ^ «Агрегация» . Платформа SDK для Windows XP SP2 . Microsoft . Проверено 4 ноября 2007 года .

Внешние ссылки [ править ]

  • Association, Aggregation and Composition , по состоянию на февраль 2009 г.
  • Харальд Стёррле, UML2, Аддисон-Уэсли, 2005 г.