Object composition

[1] Common kinds of compositions are objects used in object-oriented programming, tagged unions, sets, sequences, and various graph structures.

For example, a sequence differs from a set because (among other things) the order of the composed items matters for the former but not the latter.

Data structures such as arrays, linked lists, hash tables, and many others can be used to implement either of them.

Object-oriented programming is based on using objects to encapsulate data and behavior.

It uses two main techniques for assembling and composing functionality into more complex ones, sub-typing and object composition.

In this regard, object composition differs from data structures, which do not enforce encapsulation.

When a composite object contains several sub-objects of the same type, they may be assigned to particular roles, often distinguished by names or numbers.

For example, a Point object might contain 3 numbers, each representing distance along a different axis, such as 'x', 'y', and 'z'.

In UML modeling, objects can be conceptually composed, independently of the implementation with a programming language.

The graphical notation represents: Aggregation differs from ordinary composition in that it does not imply ownership.

Each Person structure then "has an" age, name, and an employment type.

[citation needed] Arrays were the only composite data type in Algol 60.

For example, a linked list might be declared as: For ALGOL 68 only the type name appears to the left of the equality, and most notably the construction is made – and can be read – from left to right without regard to priorities.

Typically compound structures were built up using EQUIVALENCE or COMMON statements: Ada 95 brought OOP concepts through tagged types (the equivalent of a C++ class), Ada 2012 added support for substitution verification through class-wide contracts.