En el mundo real, y dentro del contexto de una aplicación que debemos implementar, los objetos no están solos. Todo objeto se relaciona en cierta medida con alguno de los otros objetos (sea de la misma clase o no). En el ejemplo de alquiler de autos que estudiamos anteriormente, los clientes (que son objetos) se relacionan con los autos (que también son objetos) mediante la operación de alquiler. Del mismo modo, los formularios de alquiler se relacionan con los autos y con los clientes. Una buena regla adicional para la identificación de objetos a partir de un requerimiento es que, si un objeto no se relaciona con ningún otro, es probable que no sea necesario tenerlo en el sistema o deba ser revisado para ver si no nos faltó considerar algún aspecto del requerimiento.Un objeto puede relacionarse con otro de distintas maneras, como por ejemplo, enviándose mensajes entre sí. Durante el análisis, una vez que determinamos los objetos y definimos las clases, debemos prestar atención a las relaciones entre los objetos, ya que deberán ser modeladas para que luego se encuentren disponibles en ca- da instancia. Entre las relaciones más importantes, podemos mencionar: uso, agregación y herencia. Veamos las dos primeras ahora y dejemos la herencia para después, ya que es muy importante y merece un tratamiento aparte.
POO PURA Muchos puristas de la orientación a objetos sostienen que Smalltalk y Eiffel son de los pocos lenguajes
realmente orientados a objetos. El argumento se basa en que otros lenguajes (como los presentes en la plataforma .Net) poseen aún muchos conceptos de la programación estructurada (como por ejemplo las estructuras de control) y eso atenta
contra la definición formal de orientación a objetos.
RELACIÓN DE USO
En una relación de uso, un objeto A usa un objeto B, en el sentido de utilizar algún servicio provisto por B. En cualquier aplicación, es muy común encontrar que un objeto necesita algún servicio de otro, como pedirle que haga una deter- minada tarea. Si retomamos el ejemplo de la validación de tarjetas de crédito que vimos cuando tratamos el tema de los patrones, podemos observar que el objeto ValidadorTarjetaCredito brinda un servicio que alguien más, por ejemplo un objeto RegistradorDeAlquiler puede usar para completar su función. En la bibliografía de POO, se suele llamar relación Usa-A a la relación de uso.
RELACIÓN DE AGREGACIÓN
Muchas veces, un objeto se compone de otros. Este tipo de relación se denomina agregación. En una relación de agregación entonces, un grupo de objetos (de la misma clase o de clases distintas) se agrupan para formar un objeto más complejo. Por ejemplo, un carrito de compras se compone de uno o más productos que el cliente ha comprado. Si bien los objetos producto son independientes, el objeto carrito necesita de ellos para existir. La relación de agregación puede ser recursiva, es decir, un objeto que está compuesto por otros, a su vez, puede ser parte de un objeto más grande, definiendo así una estructura jerárquica. Por ejemplo, una universidad puede estar compuesta de facultades, cada facultad se compone de departamentos, y cada departamento, de profesores y de alumnos.
Composición
La composición es un caso especial de agregación en el que los objetos agrega- dos a otro, sólo pertenecen a él. Por ejemplo, un automóvil está compuesto de un motor, un chasis, una carrocería y otros elementos, pero cada uno de ellos sólo puede pertenecer a ese auto. Un motor que está en un auto no puede estar en otro. La distinción entre agregación y composición depende directamente del problema por resolver y, en un buen modelo de objetos, debería reflejar exactamente la realidad.
RELACIONES Desde el punto de vista de la implementación, tanto las relaciones de agregación como las de composición suelen representarse como propiedades o atributos de las clases agregadas o compuestas. Por ejemplo, la clase Carrito puede tener una propiedad que sea la lista de objetos de la clase Producto que ella contiene.
MÉTODOS Y PROPIEDADES DE CLASE Normalmente, los métodos y propiedades corresponden a cada instancia de una clase (a cada objeto). Sin embargo, muchas veces hay características que son comunes a todas las instancias. En estos casos, podemos definir métodos o propiedades compartidos, que pertenecen a la clase y se pueden invocar directamente sobre ella.
POO PURA Muchos puristas de la orientación a objetos sostienen que Smalltalk y Eiffel son de los pocos lenguajes
realmente orientados a objetos. El argumento se basa en que otros lenguajes (como los presentes en la plataforma .Net) poseen aún muchos conceptos de la programación estructurada (como por ejemplo las estructuras de control) y eso atenta
contra la definición formal de orientación a objetos.
RELACIÓN DE USO
En una relación de uso, un objeto A usa un objeto B, en el sentido de utilizar algún servicio provisto por B. En cualquier aplicación, es muy común encontrar que un objeto necesita algún servicio de otro, como pedirle que haga una deter- minada tarea. Si retomamos el ejemplo de la validación de tarjetas de crédito que vimos cuando tratamos el tema de los patrones, podemos observar que el objeto ValidadorTarjetaCredito brinda un servicio que alguien más, por ejemplo un objeto RegistradorDeAlquiler puede usar para completar su función. En la bibliografía de POO, se suele llamar relación Usa-A a la relación de uso.
Cuando un objeto A solicita una tarea a un objeto B, se dice que el objeto A usa el objeto B.
RELACIÓN DE AGREGACIÓN
Muchas veces, un objeto se compone de otros. Este tipo de relación se denomina agregación. En una relación de agregación entonces, un grupo de objetos (de la misma clase o de clases distintas) se agrupan para formar un objeto más complejo. Por ejemplo, un carrito de compras se compone de uno o más productos que el cliente ha comprado. Si bien los objetos producto son independientes, el objeto carrito necesita de ellos para existir. La relación de agregación puede ser recursiva, es decir, un objeto que está compuesto por otros, a su vez, puede ser parte de un objeto más grande, definiendo así una estructura jerárquica. Por ejemplo, una universidad puede estar compuesta de facultades, cada facultad se compone de departamentos, y cada departamento, de profesores y de alumnos.
Composición
La composición es un caso especial de agregación en el que los objetos agrega- dos a otro, sólo pertenecen a él. Por ejemplo, un automóvil está compuesto de un motor, un chasis, una carrocería y otros elementos, pero cada uno de ellos sólo puede pertenecer a ese auto. Un motor que está en un auto no puede estar en otro. La distinción entre agregación y composición depende directamente del problema por resolver y, en un buen modelo de objetos, debería reflejar exactamente la realidad.
En una relación de agregación, los objetos se agrupan para formar un objeto más complejo.
RELACIONES Desde el punto de vista de la implementación, tanto las relaciones de agregación como las de composición suelen representarse como propiedades o atributos de las clases agregadas o compuestas. Por ejemplo, la clase Carrito puede tener una propiedad que sea la lista de objetos de la clase Producto que ella contiene.
MÉTODOS Y PROPIEDADES DE CLASE Normalmente, los métodos y propiedades corresponden a cada instancia de una clase (a cada objeto). Sin embargo, muchas veces hay características que son comunes a todas las instancias. En estos casos, podemos definir métodos o propiedades compartidos, que pertenecen a la clase y se pueden invocar directamente sobre ella.