Composición del objeto


De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

En informática , la composición de objetos es una forma de combinar objetos o tipos de datos en otros más complejos. Los tipos comunes de composiciones son los objetos que se utilizan en la programación orientada a objetos , uniones etiquetadas , conjuntos , secuencias y diversas estructuras de gráficos . [1] Las composiciones de objetos se relacionan con estructuras de datos, pero no son lo mismo.

La composición del objeto se refiere a la estructura lógica o conceptual de la información, no a la implementación o estructura de datos física utilizada para representarla [ cita requerida ] . Por ejemplo, una secuencia difiere de un conjunto porque (entre otras cosas) el orden de los elementos compuestos es importante para el primero pero no para el segundo. Se pueden utilizar estructuras de datos como matrices , listas enlazadas , tablas hash y muchas otras para implementar cualquiera de ellas. Quizás de manera confusa, algunos de los mismos términos se utilizan tanto para estructuras de datos como para compuestos. Por ejemplo, " árbol binario"puede referirse a: como estructura de datos, es un medio para acceder a una secuencia lineal de elementos, y las posiciones reales de los elementos en el árbol son irrelevantes (el árbol se puede reorganizar internamente como se desee, sin cambiar su significado). Sin embargo, como composición de un objeto, las posiciones son relevantes y cambiarlas cambiaría el significado (como por ejemplo en los cladogramas ) [ cita requerida ] .

Técnica de programación

La programación orientada a objetos se basa en objetos para encapsular datos y comportamiento. Utiliza dos técnicas principales para ensamblar y componer funcionalidades en otras más complejas, subtipificación y composición de objetos. [2] La composición de objetos consiste en combinar objetos dentro de objetos compuestos y, al mismo tiempo, garantizar la encapsulación de cada objeto mediante el uso de su interfaz bien definida sin visibilidad de sus partes internas. En este sentido, la composición de objetos difiere de las estructuras de datos, que no imponen la encapsulación.

La composición de objetos también puede tratarse de un grupo de múltiples objetos relacionados, como un conjunto o una secuencia de objetos. La delegación puede enriquecer la composición reenviando solicitudes o llamadas realizadas al objeto compuesto adjunto a uno de sus componentes internos. [3]

En los lenguajes de programación basados ​​en clases y tipificados , los tipos se pueden dividir en tipos compuestos y no compuestos, y la composición se puede considerar como una relación entre tipos: un objeto de un tipo compuesto (por ejemplo, automóvil ) " tiene " objetos de otros tipos ( por ejemplo, rueda ). Cuando un objeto compuesto contiene varios subobjetos del mismo tipo, pueden asignarse roles particulares , a menudo distinguidos por nombres o números. Por ejemplo, un objeto Point puede contener 3 números, cada uno de los cuales representa la distancia a lo largo de un eje diferente, como 'x', 'y' y 'z'. El estudio de las relaciones parte-todo en general es mereología .

La composición debe distinguirse del subtipo , que es el proceso de agregar detalles a un tipo de datos general para crear un tipo de datos más específico. Por ejemplo, los automóviles pueden ser un tipo específico de vehículo: el automóvil es un vehículo . El subtipo no describe una relación entre diferentes objetos, sino que dice que los objetos de un tipo son simultáneamente objetos de otro tipo. El estudio de tales relaciones es ontología .

En los lenguajes de programación basados ​​en prototipos , como JavaScript , los objetos pueden heredar dinámicamente los comportamientos de un objeto prototipo en el momento de su instanciación. La composición debe distinguirse de la creación de prototipos: el objeto recién instanciado hereda la composición de su prototipo, pero puede estar compuesto por sí mismo.

Los objetos compuestos se pueden representar en el almacenamiento colocando los objetos compuestos, colocando referencias o de muchas otras formas. Los elementos dentro de un objeto compuesto pueden denominarse atributos , campos , miembros , propiedades u otros nombres, y la composición resultante como tipo compuesto , registro de almacenamiento , estructura , tupla o tipo definido por el usuario (UDT) . Para obtener más detalles, consulte la sección de agregación a continuación.

Técnica de modelado UML

Composición de objetos usando propiedades UML para componer objetos

En el modelado UML , los objetos se pueden componer conceptualmente, independientemente de la implementación con un lenguaje de programación. Hay cuatro formas de componer objetos en UML: propiedad, asociación, agregación y composición: [4]

  • Una propiedad representa un atributo de la clase.
  • Una asociación representa una relación semántica entre instancias de las clases asociadas. El miembro final de una asociación corresponde a una propiedad de la clase asociada.
  • Una agregación es un tipo de asociación que modela una relación de parte / todo entre un agregado (todo) y un grupo de componentes relacionados (partes).
  • Una composición, también llamada agregación compuesta, es un tipo de agregación que modela una relación parte / todo entre un compuesto (todo) y un grupo de partes de propiedad exclusiva.

La relación entre el agregado y sus componentes es una relación débil "tiene-a": los componentes pueden ser parte de varios agregados, se puede acceder a ellos a través de otros objetos sin pasar por el agregado y pueden sobrevivir al objeto agregado. [4] El estado del objeto componente todavía forma parte del objeto agregado. [ cita requerida ]

La relación entre el compuesto y sus partes es una fuerte relación "tiene-a": el objeto compuesto tiene la única " responsabilidad de la existencia y el almacenamiento de los objetos compuestos ", el objeto compuesto puede ser parte de como máximo un compuesto, y " Si se elimina un objeto compuesto, todas sus instancias de parte que son objetos se eliminan con él ". Por tanto, en UML, la composición tiene un significado más limitado que la composición de objetos habitual.

Notación UML para asociación, composición y agregación

La notación gráfica representa:

  • la propiedad como un elemento escrito en el cuadro de la clase adjunta,
  • la asociación como una línea simple entre las clases asociadas,
  • la agregación como un diamante sin relleno en el lado del agregado y una línea continua,
  • la composición como un diamante relleno en el lado del compuesto y una línea continua.


Formas especiales

Contención

La composición que se utiliza para almacenar varias instancias del tipo de datos compuestos se denomina contención. Ejemplos de tales contenedores son matrices , matrices asociativas , árboles binarios y listas enlazadas .

En UML , la contención se representa con una multiplicidad de 0 .. * o 1 .. *, lo que indica que el objeto compuesto está compuesto por un número desconocido de instancias de la clase compuesta.

Composición recursiva

Los objetos se pueden componer de forma recursiva y su tipo se denomina tipo recursivo . Los ejemplos incluyen varios tipos de árboles , DAG y gráficos . Cada nodo de un árbol puede ser una rama o una hoja; en otras palabras, cada nodo es un árbol al mismo tiempo cuando pertenece a otro árbol.

En UML, la composición recursiva se representa con una asociación, agregación o composición de una clase consigo misma.

Patrón compuesto

El patrón de diseño compuesto es un diseño orientado a objetos basado en tipos compuestos, que combina composición recursiva y contención para implementar jerarquías complejas de parte y todo.

Tipos compuestos en C

Este es un ejemplo de composición en C .

 Persona de estructura{ int age ;  nombre de char [ 20 ];  enum { job_seeking , profesional , non_professional , jubilados , estudiantes } de empleo ;      };

En este ejemplo, los tipos primitivos (no compuestos) int , enum {job_seeking, professional, non_professional, retired, student } y el tipo de matriz compuesta char [] se combinan para formar la estructura compuesta Person . Entonces, cada estructura de Persona "tiene" una edad, un nombre y un tipo de empleo.

Cronología de la composición en varios idiomas.

C llama a un registro una estructura o estructura; Los lenguajes orientados a objetos como Java , Smalltalk y C ++ a menudo mantienen sus registros ocultos dentro de los objetos ( instancias de clases ); los idiomas de la familia ML simplemente los llaman registros. COBOL fue el primer lenguaje de programación generalizado que admitió registros directamente; [5] ALGOL 68 lo obtuvo de COBOL y Pascal lo obtuvo, más o menos indirectamente, de ALGOL 68. Common Lisp proporciona estructuras y clases (este último a través delSistema de objetos Common Lisp ). [ cita requerida ]

1959 - COBOL
 01 registro de cliente . 03 número de cliente foto 9 (8) comp . 03 nombre del cliente . 05 nombres de pila pic x (15) . 05 inicial-2 imagen x . 05 apellido pic x (15) . 03 dirección del cliente . 05 calle . 07 foto del nombre de la calle x (15) . 09 número de casa foto 999 comp . 05 foto de la ciudad x (10) . 05 código de país imagen x (3)                                . 05 código postal pic x (8) . 03 cantidad adeuda imagen 9 (8) comp .       
1960 - ALGOL 60

Las matrices eran el único tipo de datos compuestos en Algol 60 .

1964 - PL / I
dcl 1 basado en newtypet (P); 2 (a, b, c) contenedor fijo (31), 2 (i, j, k) flotar, 2 r ptr;
asignar newtypet;
1968 - ALGOL 68
int max = 99;
modo newtypet = [0..9] [0..max] struct ( largo real a, b, c, corto int i, j, k, ref real r
);
newtypet newarrayt = (1, 2, 3, 4, 5, 6, montón real: = 7)

Por ejemplo, una lista vinculada podría declararse como:

modo nodo = unión (real, int, compl, string), lista = estructura (nodo val, ref lista siguiente);

Para ALGOL 68, solo el nombre del tipo aparece a la izquierda de la igualdad y, sobre todo, la construcción se realiza, y se puede leer, de izquierda a derecha sin tener en cuenta las prioridades.

1970 - Pascal
escriba  a  =  matriz  [ 1 .. 10 ]  de  entero ;  b  =  registro  a ,  b ,  c :  real ;  i ,  j ,  k :  número entero ;  terminar ;
1972 - K&R C
#define max 99 struct  newtypet  {  double  a ,  b ,  c ;  flotar  r ;  corto  i ,  j ,  k ; }  newarrayt [ 10 ]  [ max  +  1 ];
1977 - FORTRAN 77

Fortran 77 tiene matrices, pero carecía de definiciones formales de registro / estructura. Normalmente, las estructuras compuestas se construyeron utilizando EQUIVALENCIA o declaraciones COMUNES :

 CARÁCTER NOMBRE * 32 ,  DIRECCIÓN * 32 ,  TELÉFONO * 16  DEUDA REAL COMÚN / CUST / NOMBRE , DIRECCIÓN , TELÉFONO , DEUDA     
1983 - Ada
tipo  Cust  es el  registro  Nombre  :  Name_Type ;  Dirección  :  Addr_Type ;  Teléfono  :  Phone_Type ;  Debido  :  rango de números enteros  1 .. 999999 ; registro final ;  

Ada 95 trajo conceptos de OOP a través de tipos etiquetados (el equivalente a una clase C ++), Ada 2012 agregó soporte para la verificación de sustitución a través de contratos para toda la clase.

1983 - C ++
const  int  max  =  99 ; class  {  public :  double  a ,  b ,  c ;  flotar  & r ;  corto  i ,  j ,  k ; } newtypet [ 10 ]  [ max  +  1 ];
1991 - Python
max  =  99 clase  NewTypeT :  def  __init__ ( self ):  self . a  =  yo . b  =  yo . c  =  0  propio . yo  =  yo . j  =  yo . k  =  0.0 # Inicialice una matriz de ejemplo de esta clase. newarrayt  =  [[ NewTypeT ()  para  i  en el  rango ( máx.  +  1 )] para  j  en el  rango ( 10 )]
1992 - FORTRAN 90

Las matrices y cadenas se heredaron de FORTRAN 77 y se introdujo una nueva palabra reservada: tipo

tipo newtypet  doble precisión a ,  b ,  c  entero * 2  i ,  j ,  k *  Sin  tipo de puntero REF  REAL R  tipo finaltype  ( newtypet )  t ( 10 ,  100 )

FORTRAN 90 actualizó e incluyó el concepto de FORTRAN IV llamado NAMELIST.

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

Common Lisp proporciona estructuras y el estándar ANSI Common Lisp agregó clases CLOS.

( defclass  alguna-clase  ()  (( f  : type  float )  ( i  : type  integer )  ( a  : type  ( array  integer  ( 10 )))))

Para obtener más detalles sobre la composición en C / C ++, consulte Tipo compuesto .

Agregación

La agregación se diferencia de la composición ordinaria en que no implica propiedad. En composición, cuando el objeto propietario es destruido, también lo son los objetos contenidos. En conjunto, esto no es necesariamente cierto. Por ejemplo, una universidad posee varios departamentos (por ejemplo, química ) y cada departamento tiene varios profesores. Si la universidad cierra, los departamentos dejarán de existir, pero los profesores de esos departamentos seguirán existiendo. Por tanto, una universidad puede verse como una composición de departamentos, mientras que los departamentos tienen una agregación de profesores. Además, un profesor puede trabajar en más de un departamento, pero un departamento no puede formar parte de más de una universidad.

La composición generalmente se implementa de manera que un objeto contenga otro objeto. Por ejemplo, en C ++ :

 profesor de clase ; // Definido en otro lugar  departamento de clase {  publico : Departamento ( const std :: cadena y título ) : título_ ( título ) {}     privado : // Agregación: | Profesores | puede sobrevivir al | Departamento |. std :: vector < std :: débil_ptr < Profesor >> miembros_ ;   const std :: string title_ ;  };clase  Universidad {  publico : Universidad () = predeterminado ;   privado : // Composición: | Departamentos | s existen solo mientras exista la facultad. std :: vector < Departamento > facultad_ = {     Departamento ( "química" ), Departamento ( "física" ), Departamento ( "artes" ), };};

En agregación, el objeto solo puede contener una referencia o puntero al objeto (y no tener responsabilidad de por vida ).

A veces, la agregación se denomina composición cuando la distinción entre composición ordinaria y agregación no es importante.

El código anterior se transformaría en el siguiente diagrama de clases UML:

Agregación en COM

Agregación en COM

En el Modelo de objetos componentes de Microsoft , la agregación significa que un objeto exporta, como si fuera su propietario, una o varias interfaces de otro objeto que posee. Formalmente, esto es más similar a la composición o encapsulación que a la agregación. Sin embargo, en lugar de implementar las interfaces exportadas llamando a las interfaces del objeto de propiedad, se exportan las interfaces del objeto de propiedad. El objeto de propiedad es responsable de asegurar que los métodos de esas interfaces heredadas de IUnknownen realidad invocan los métodos correspondientes del propietario. Esto es para garantizar que el recuento de referencias del propietario sea correcto y que todas las interfaces del propietario sean accesibles a través de la interfaz exportada, mientras que ninguna otra interfaz (privada) del objeto de propiedad sea accesible. [6]

Ver también

  • Estructura C ++
  • Tipo compuesto
  • Composición sobre herencia
  • Delegación (programación)
  • Composición de funciones (informática)
  • Tiene un
  • Herencia de implementación
  • Semántica de herencia
  • Ley de Demeter
  • Herencia virtual

Referencias

  1. ^ Michelle Yaiser . "Conceptos de programación orientada a objetos: composición y agregación" . Adobe . Consultado el 11 de marzo de 2015 . La composición se trata de expresar relaciones entre objetos. Piense en el ejemplo de la silla. Una silla tiene un asiento. Una silla tiene respaldo. Y una silla tiene un par de patas. La frase "tiene un" implica una relación en la que la silla posee, o como mínimo, utiliza, otro objeto. Es esta relación de "tiene" la base de la composición.
  2. ^ Patrones de diseño: elementos de software orientado a objetos reutilizables . Gamma, Erich., Helm, Richard (informático), Johnson, Ralph E., 1955-, Vlissides, John. Reading, Mass .: Addison-Wesley. 1995. ISBN 0-201-63361-2. OCLC  31171684 .CS1 maint: otros ( enlace )
  3. ^ Ostermann, Klaus; Mezini, Mira (1 de octubre de 2001). "Composición orientada a objetos desenredada" . Avisos ACM SIGPLAN . 36 (11): 283–299. doi : 10.1145 / 504311.504303 . ISSN 0362-1340 . 
  4. ↑ a b Dios mío (2017). "Especificación de lenguaje de modelado unificado versión 2.5.1" . www.omg.org . pag. 109-110,197-201 . Consultado el 4 de octubre de 2020 .
  5. ^ Sebesta, Robert W. Conceptos de lenguajes de programación (Tercera ed.). Addison-Wesley Publishing Company, Inc. pág. 218 . ISBN 0-8053-7133-8.
  6. ^ "Agregación" . Platform SDK para Windows XP SP2 . Microsoft . Consultado el 4 de noviembre de 2007 .

enlaces externos

  • Association, Aggregation and Composition , consultado en febrero de 2009
  • Harald Störrle, UML2, Addison-Wesley, 2005
Obtenido de " https://en.wikipedia.org/w/index.php?title=Object_composition&oldid=1026306152#Aggregation "