En el diseño de bases de datos , programación orientada a objetos y diseño , has-a ( has_a o has a ) es una relación de composición en la que un objeto (a menudo llamado objeto constituido u objeto parte/constituyente/miembro) "pertenece a" (es parte o miembro de ) otro objeto (llamado tipo compuesto) y se comporta de acuerdo con las reglas de propiedad. En palabras simples, la relación has-a en un objeto se llama campo miembro de un objeto. Múltiples relaciones has-a se combinarán para formar una jerarquía posesiva.
"Tiene-un" debe contrastarse con una relación es-un ( is_a o is a ) que constituye una jerarquía taxonómica ( subtipificación ).
La decisión de si la relación más lógica entre un objeto y su subordinado es siempre clara no es has-a o is-a . La confusión sobre tales decisiones ha hecho necesaria la creación de estos términos metalingüísticos. Un buen ejemplo de la relación has-a son los contenedores en la STL de C++ .
Para resumir las relaciones, tenemos
En las bases de datos, las relaciones "tiene un" suelen representarse en un modelo de relación de entidad . Como puede ver en el diagrama de la derecha, una cuenta puede tener varios personajes. Esto muestra que la cuenta tiene una relación "tiene un" con el personaje.
En la programación orientada a objetos, esta relación se puede representar con un diagrama de clases de lenguaje de modelado unificado . Esta relación tiene-un también se conoce como composición. Como puede ver en el diagrama de clases de la derecha, un automóvil "tiene-un" carburador , o un automóvil está "compuesto por" un carburador. Cuando el diamante es de color negro, significa composición , es decir, el objeto del lado más cercano al diamante está formado por o contiene el otro objeto. Mientras que el diamante blanco significa agregación , lo que significa que el objeto más cercano al diamante puede tener o poseer el otro objeto.
Otra forma de distinguir entre composición y agregación al modelar el mundo real es considerar la vida útil relativa del objeto contenido. Por ejemplo, si un objeto Car contiene un objeto Chassis, es muy probable que un Chassis no se reemplace durante la vida útil del Car. Tendrá la misma vida útil que el propio coche; por lo tanto, la relación es de composición . Por otro lado, si el objeto Car contiene un conjunto de objetos Tire, estos objetos Tire pueden desgastarse y reemplazarse varias veces. O si el Car se vuelve inutilizable, algunos Tires pueden recuperarse y asignarse a otro Car. En cualquier caso, los objetos Tire tienen vidas útiles diferentes a las del objeto Car; por lo tanto, la relación es de agregación .
Si uno creara una clase de software C++ para implementar las relaciones descritas anteriormente, el objeto Car contendría un objeto Chassis completo en un miembro de datos. Este objeto Chassis se instanciaría en el constructor de la clase Car (o se definiría como el tipo de datos del miembro de datos y sus propiedades asignadas en el constructor). Y dado que sería un miembro de datos completamente contenido de la clase Car, el objeto Chassis ya no existiría si se eliminara un objeto de la clase Car.
Por otro lado, los miembros de datos de la clase Car que apuntan a objetos Tire probablemente sean punteros de C++. Los objetos Tire podrían instanciarse y eliminarse externamente, o incluso asignarse a miembros de datos de un objeto Car diferente. Los objetos Tire tendrían una duración independiente, distinta a la del momento en que se eliminó el objeto Car.