Has-a: Difference between revisions
m Reverted unexplained replacement of content (HG) |
m remove Erik9bot category,outdated, tag and general fixes |
||
Line 1: | Line 1: | ||
{{Unreferenced stub|auto=yes|date=December 2009}} |
|||
In [[database design]] and [[object oriented]] [[program architecture]], '''has-a''' is a relationship where one object (often called the composited object) "belongs" to (is [[object composition|a 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 member field of an object. Multiple '''has-a''' relationships will combine to form a possessive hierarchy. This is contrasted with an [[Is-a]] relationship which constitutes a different kind of hierarchy ([[subtyping]]). The decision whether the most logical relationship for an object and its subordinate is not always clearly ''has-a'' or ''is-a''. Confusion over such decisions have necessitated the creation of these metalinguistic terms. A good example of the ''has-a'' relationship is containers in the [[C++]] [[Standard Template Library|STL]]. |
In [[database design]] and [[object oriented]] [[program architecture]], '''has-a''' is a relationship where one object (often called the composited object) "belongs" to (is [[object composition|a 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 member field of an object. Multiple '''has-a''' relationships will combine to form a possessive hierarchy. This is contrasted with an [[Is-a]] relationship which constitutes a different kind of hierarchy ([[subtyping]]). The decision whether the most logical relationship for an object and its subordinate is not always clearly ''has-a'' or ''is-a''. Confusion over such decisions have necessitated the creation of these metalinguistic terms. A good example of the ''has-a'' relationship is containers in the [[C++]] [[Standard Template Library|STL]]. |
||
==Examples== |
==Examples== |
||
[[File:ER Diagram MMORPG.png |
[[File:ER Diagram MMORPG.png|right | thumb |ER Model]] |
||
[[File:AggregationAndComposition.svg |
[[File:AggregationAndComposition.svg|right | thumb |Composition vs. Aggregation]] |
||
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. |
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. |
||
Line 14: | Line 15: | ||
* [[Meronymy]] |
* [[Meronymy]] |
||
{{DEFAULTSORT:Has-A}} |
|||
[[Category:Object-oriented programming]] |
[[Category:Object-oriented programming]] |
||
[[Category:Relational algebra]] |
[[Category:Relational algebra]] |
||
[[Category:Articles lacking sources (Erik9bot)]] |
|||
{{ |
{{Compu-sci-stub}} |
||
[[ja:Has-a]] |
[[ja:Has-a]] |
Revision as of 14:40, 16 December 2009
In database design and object oriented program architecture, has-a is a relationship where one object (often called the composited object) "belongs" to (is a 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 member field of an object. Multiple has-a relationships will combine to form a possessive hierarchy. This is contrasted with an Is-a relationship which constitutes a different kind of hierarchy (subtyping). The decision whether the most logical relationship for an object and its subordinate is not always clearly has-a or is-a. Confusion over such decisions have necessitated the creation of these metalinguistic terms. A good example of the has-a relationship is containers in the C++ STL.
Examples
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.
In object-oriented programming this relationship can be represented with a Unified Modeling Language diagram. This has-a relationship is also known as composition. As you can see from the 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.
See also