Has-a: Difference between revisions
No edit summary |
m Unref stub now merely unref, since not a stub., removed stub tag using AWB |
||
| Line 1: | Line 1: | ||
{{Unreferenced |
{{Unreferenced|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 a 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 a 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]]. |
||
| Line 11: | Line 11: | ||
Another way to distinguish between [[Object composition|composition]] and [[Object composition#Aggregation|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 [[Object composition|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 [[Object composition#Aggregation|aggregation]]. |
Another way to distinguish between [[Object composition|composition]] and [[Object composition#Aggregation|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 [[Object composition|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 [[Object composition#Aggregation|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. |
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. |
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. |
||
| Line 24: | Line 24: | ||
[[Category:Object-oriented programming]] |
[[Category:Object-oriented programming]] |
||
[[Category:Relational algebra]] |
[[Category:Relational algebra]] |
||
{{Compu-sci-stub}} |
|||
[[ja:Has-a]] |
[[ja:Has-a]] |
||
Revision as of 22:03, 9 February 2011
 |
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 a 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.
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.