Asociación y herencia PDF

Preview

Summary

David García Solórzano...

Description

Asociación y herencia PID_00249621

David García Solórzano

Tiempo mínimo de dedicación recomendado: 4 horas

© FUOC• PID_00249621

Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

Asociación y herencia

© FUOC• PID_00249621

Asociación y herencia

Índice

Introducción...............................................................................................

5

Objetivos.......................................................................................................

6

1.

7

Asociaciones: relación entre instancias....................................... 1.1.

Asociación binaria .......................................................................

7

1.2.

Asociación de agregación ............................................................

8

1.3.

Asociación de composición ........................................................

9

1.4.

Asociación reflexiva ....................................................................

10

1.5.

Propiedades de las asociaciones ..................................................

10

1.5.1.

Cardinalidad ..................................................................

11

1.5.2.

Navegabilidad ................................................................

14

1.5.3.

Rol ..................................................................................

15

Traduciendo a código... ...............................................................

15

1.6. 2.

Herencia: relación de generalización/especialización o entre clases...........................................................................................

21

2.1.

Concepto .....................................................................................

21

2.2.

Herencia simple ...........................................................................

22

2.3.

Herencia múltiple ........................................................................

23

2.4.

Transitividad ................................................................................

24

2.5.

Traduciendo a código... ...............................................................

25

2.6.

El constructor de la clase hija .....................................................

25

2.7.

Sobreescritura (override) ...............................................................

28

2.8.

Polimorfismo ...............................................................................

31

2.9.

Casting...........................................................................................

34

2.10. La clase Object...............................................................................

37

2.11. Boxing............................................................................................

37

Ejemplo resumen................................................................................

39

Resumen.......................................................................................................

41

Bibliografía.................................................................................................

43

3.

© FUOC• PID_00249621

5

Introducción

Hasta ahora hemos visto una clase –formada por sus atributos y métodos– trabajar de manera aislada. No obstante, en un ejemplo del módulo «Encapsulación y extensión» hemos visto que una clase podía tener como atributo un objeto que pertenecía a otra clase. Éste era el caso de la clase SortedArray, la cual tenía un atributo que era un array de objetos de la clase Object. Esto sería, claramente, una relación entre clases: la clase A (SortedArray) contiene/utiliza la clase B (Object). Es obvio que una única clase no puede solucionar por sí sola un problema y que, por consiguiente, tendrá que colaborar con otras clases para resolverlo. En los módulos que quedan veremos las diferentes relaciones (maneras de colaborar) que se pueden dar entre las clases de un programa siguiendo el paradigma de la programación orientada a objetos. Además, veremos cómo se representan estas relaciones usando el lenguaje de modelado de sistemas de software, UML (Unified Modeling Language). En este punto cabe destacar que, en verdad, son los objetos los que colaboran entre sí para resolver un problema y que cada objeto pertenece a una clase. Si somos rigurosos, debemos distinguir entre dos tipos de relaciones: 1) las que son entre instancias, y 2) las que son entre clases. Las relaciones entre instancias son, como veremos en este módulo, denominadas asociaciones; puede haber, principalmente, de cuatro tipos: 1) asociación binaria, 2) asociación de agregación, 3) asociación de composición y 4) asociación reflexiva. Por su parte, la relación entre clases por excelencia en la POO es la generalización/especialización o comúnmente conocida como herencia. Sobre ella hablaremos en este módulo y aprenderemos, entre otras cosas, el concepto de herencia simple y múltiple, así como la característica conocida como polimorfismo, una consecuencia de la herencia y a la vez una pieza clave de la POO.

Asociación y herencia

© FUOC• PID_00249621

6

Objetivos

El objetivo principal de este módulo es explicar cómo las clases (y, por ende, los objetos) se relacionan entre sí dentro de un programa basado en el paradigma de la programación orientada a objetos (POO). Como consecuencia de este objetivo, aparecen otros, como son:

1. Entender qué es una asociación (o relación entre instancias) y distinguir entre los cuatro tipos más importantes: binaria, agregación, composición y reflexiva. 2. Conocer la relación de generalización/especialización (más conocida como herencia) que se puede dar entre clases. 3. Ver y entender el potencial que la herencia, mediante diferentes mecanismos (por ejemplo, polimorfismo), puede ofrecernos a la hora de diseñar e implementar nuestros programas.

Asociación y herencia

© FUOC• PID_00249621

7

Asociación y herencia

1. Asociaciones: relación entre instancias

La relación entre instancias es conocida con el nombre de asociación. Pode-

Ved también

mos distinguir principalmente cuatro tipos de asociaciones: •

Asociación binaria

•

Asociación de agregación

•

Asociación de composición

•

Asociación reflexiva

Encontraréis un resumen de los conceptos explicados en el apartado 1 de este módulo en el vídeo «Relación entre objetos» que tenéis disponible en el aula de la asignatura.

Veremos estos cuatro tipos a continuación. 1.1. Asociación binaria Una asociación expresa la relación que existe entre dos instancias.

En el caso de la asociación binaria (o simplemente asociación), las dos instancias relacionadas entre sí existen de forma independiente.

Por lo tanto, la creación o destrucción de una de ellas implica únicamente la creación o destrucción de la relación que existe entre ellas, pero nunca significa la creación o destrucción de la otra instancia. Dicho de otro modo, las instancias de una clase no dependen de la existencia de las de la otra clase. Hablando con propiedad, se dice que no hay una relación fuerte entre ambas instancias. La asociación binaria responde a una relación que indica que el objeto de la clase A usa un objeto de la clase B y puede que viceversa también. Ejemplo Por ejemplo, un cliente (una instancia/objeto de la clase Cliente) puede tener varios pedidos de compra o ninguno (instancias/objetos de la clase Pedido). Si se destruye el cliente, no significa que destruyamos sus pedidos, ya que nos puede servir para hacer el cálculo de número de pedidos solicitados anualmente. Más claro es el caso contrario: si se elimina un pedido de un cliente no significa que ese cliente deje de existir. Es más, si no existe ningún pedido por parte de un cliente, puede existir ese cliente, ¡démosle tiempo para que pueda hacer un pedido!

En UML, la asociación binaria se representa con una línea que une ambas

Nota

clases. Para facilitar la comprensión y reducir la extensión de los apuntes, se han eliminado de los diagramas de clases los atributos y métodos de las clases.

© FUOC• PID_00249621

8

1.2. Asociación de agregación

Podemos definir la asociación de agregación como aquella que se da cuando una instancia de una clase (llamada componente) es parte de una instancia de otra clase (llamada compuesto).

Este tipo de asociación es también conocida como composición�débil. Se asume una subordinación conceptual del tipo «todo/parte» o bien «tiene un». Así pues, se trata de un caso particular de la asociación binaria en la que hay un cierta relación de ensamblaje, ya sea física o lógica, entre las instancias. Una de las características de esta asociación es que la destrucción del compuesto no significa la destrucción de los componentes, ni viceversa. Ejemplo 1 Un estuche escolar está formado por lápices. Si el estuche se rompe/destruye, esto no significa que los lápices se rompan/destruyan con él. Lo mismo ocurre al revés, si un lápiz se pierde o rompe (se destruye), esto no significa que el estuche también se pierda/rompa con él.

Ejemplo 2 Una agenda está formada por contactos. Si la agenda se destruye, los contactos existen como tales, de hecho podrían estar en otra agenda. Si un contacto es eliminado de la agenda, la agenda sigue existiendo.

Ejemplo 3 Las instancias de la clase Ingrediente forman parte de una instancia u objeto de la clase Plato. Si eliminamos un plato, no eliminamos los ingredientes (ya que pueden formar parte de otros platos). Si eliminamos un ingrediente, el plato se denomina igual pero queda modificado.

Como hemos podido ver, en UML, la asociación de agregación se representa con un rombo blanco en la parte del objeto agregador (es decir, el compuesto, el que representa el todo).

Asociación y herencia

9

© FUOC• PID_00249621

1.3. Asociación de composición

Podemos definir la asociación de composición como un caso particular de la asociación de agregación en la que la vida/existencia de la instancia de la clase contenida (llamada componente) debe coincidir con la de la instancia de la clase contenedora (llamada compuesto). O dicho de otro modo, la destrucción del objeto compuesto conlleva la destrucción de sus componentes.

Además, en el caso de la composición, cada componente solo puede estar presente en un único compuesto. Por todo lo anterior, este tipo de asociación es también conocida como composición�fuerte. Ejemplo 1 Un ejemplo muy visual y tangible de asociación de composición es el caso de la mano y su relación con los dedos. Si amputamos la mano, implícitamente eliminamos los dedos que la componen. Pero si quitamos un dedo de la mano, ¡no amputamos toda la mano!

Mano

Dedo

Ejemplo 2 Un libro está compuesto por páginas. La página 1 de un ejemplar del Quijote solo tiene sentido en ese libro y no en otro. Por lo tanto, la destrucción del libro implicaría la destrucción de sus páginas. En cambio, si se arranca una página y esta desaparece, el libro seguiría existiendo, aunque mermado.

Libro

Página

Ejemplo 3 Una silla está compuesta/formada por patas. Si destruimos la silla estamos destruyendo sus patas implícitamente. Si le quitamos una pata a la silla, la silla continúa existiendo.

Silla

Pata

Como hemos podido ver, en UML, la asociación de composición se representa con un rombo negro en la parte del objeto que representa el todo (es decir, el compuesto).

Asociación y herencia

© FUOC• PID_00249621

10

En este punto puede que os cueste ver la diferencia entre agregación y composición. El matiz está principalmente en que la composición añade una restricción de vida/existencia en la relación entre instancias. Es decir, si se destruye la instancia agregadora/compuesta, deben morir/destruirse las instancias agregadas/componentes.

El tipo de relación entre dos instancias de clases diferentes puede cambiar según el contexto/problema en el que se encuentren.

Por eso es importante entender el problema/contexto que estamos trabajando en cada momento para saber si estamos ante un caso de agregación o de composición o de asociación binaria. 1.4. Asociación reflexiva

Podemos definir la asociación reflexiva como una asociación binaria en la que las dos clases, origen y destino de la relación, son la misma clase.

Ejemplo El ejemplo típico de asociación reflexiva es el de un empleado que es jefe de otro empleado. El jefe no deja de ser un empleado.

Como hemos visto, en UML, la asociación reflexiva se representa con una línea que sale y entra en la misma clase. Para poder identificar correctamente los roles de los dos extremos de la asociación, hay que definirlos con un texto aclaratorio en cada uno de los extremos. 1.5. Propiedades de las asociaciones Las asociaciones tienen básicamente tres propiedades: •

Cardinalidad

•

Navegabilidad

•

Rol

A continuación, veremos cada una de ellas.

Asociación y herencia

© FUOC• PID_00249621

11

1.5.1. Cardinalidad Dado que una asociación entre dos clases representa en realidad una relación entre instancias de esas dos clases, debemos indicar cuántas instancias/objetos de cada clase pueden estar involucrados como mínimo y/o máximo en la relación. Este número de instancias/objetos es la cardinalidad de la asociación.

La cardinalidad (también conocida como multiplicidad) es el número de instancias de una clase con el que se puede relacionar una instancia de la otra clase de la relación.

La manera de indicar la cardinalidad es mediante modificadores que se añaden encima o debajo de la línea que representa la relación. Hay diferentes notaciones para los modificadores de cardinalidad: 1)�Número�exacto: indica que una instancia de la clase A tiene que estar relacionada exactamente con el número indicado de instancias de la clase B.

En este caso, un objeto de tipo Coche se relaciona con cuatro objetos de tipo Rueda y un objeto de tipo Rueda se relaciona con un único objeto de tipo Coche. En este caso además, se trata de una composición, puesto que la destrucción del objeto de tipo Coche debe suponer la destrucción de los objetos Rueda, ya que por ellos solos no tienen sentido. 2)�Rango�de�valores: permite indicar el número mínimo y máximo de instancias de la clase A con las que tiene que estar relacionada una instancia de la clase B.

En este caso, una microempresa, según la Unión Europea, es aquella que, entre otros criterios, tiene menos de diez trabajadores. Ponemos como mínimo 1 porque entendemos que no existe ninguna empresa sin ningún trabajador (como mínimo está el propietario). En cambio, en este contexto, hemos decidido que un trabajador solo puede estar en una microempresa. En otro contexto, esta cardinalidad podría ser diferente.

Asociación y herencia

© FUOC• PID_00249621

12

Asociación y herencia

3)�Muchos: existe la posibilidad de utilizar el símbolo * (asterisco) para indicar que el número de instancias es «muchos» o «infinito». Dicho de otro modo, con el asterisco decimos que la instancia de la clase A puede estar relacionada con cualquier número de instancias de la clase B (o incluso con ninguna) y no conocemos su número. Escribir * es equivalente a indicar el rango 0..*.

En este caso, una agenda puede estar vacía (cero contactos) o tener muchos contactos (no sabemos el límite en este contexto), mientras que un contacto sólo puede estar en una agenda. A diferencia de un ejemplo anterior, ahora hemos decidido que entre las instancias de las clases Agenda y Contacto haya una asociación de composición. 4)�Rangos�no�consecutivos: separando números exactos y/o rangos por comas, se pueden hacer rangos no consecutivos.

Un camión puede tener 4, 6, 8, 10 ó 12 ruedas (pero no 9, por ejemplo), y una rueda solo puede pertenecer a un camión. 5)�Combinaciones�de�las�anteriores: esto ya se ha visto en los ejemplos anteriores; hay relaciones en las que en un extremo hay un número exacto y en el otro un asterisco, otros en los que hay un rango en un extremo y un número en el otro, otros casos en que en ambos extremos hay un asterisco, etc. Ejemplo A partir del siguiente diagrama de clases UML sabemos cómo están organizados los almacenes de nuestra tienda.

Reflexión Si nos paramos a pensar, la cardinalidad, en el caso de la asociación de composición, no tiene sentido indicarla en el extremo de la clase compuesta, puesto que siempre será 1.

© FUOC• PID_00249621

13

Sabemos que un producto (el objeto concreto) solo puede estar en un almacén, como es lógico. Una botella concreta de agua no puede estar en dos almacenes a la vez, no tiene el poder de la omnipresencia. Asimismo, un producto solo puede ser de un tipo: o es un refresco o es un snack, pero no ambos a la vez. Eso sí, un tipo de producto (por ejemplo, refresco) puede asociarse a diferentes productos. Por ejemplo, el tipo de producto refresco es el adecuado tanto para el agua como para la limonada y la cerveza. Por la cardinalidad del diagrama vemos que un producto nos lo puede facilitar entre 0 y 2 proveedores como máximo. El cero nos está diciendo que a lo mejor para algún producto no tenemos proveedor en un instante determinado. Por su parte, el número 2 nos está diciendo que, como máximo, nuestra empresa trabajará con dos proveedores para un producto concreto. Si pensamos en instancias, podríamos inventarnos las siguientes, a falta de saber qué atributos y métodos tiene cada clase: •

Objetos/instancias de la clase Almacén: «Almacén de Ateca», «Almacén de Barcelona», «Almacén de Madrid», etc.

•

Objetos/instancias de la clase Producto: «Cerveza Marca X de 33 cl.», «Cerveza Marca X de 1 l.», «Cerveza Marca Y de 1 l.», «Agua Marca Z de 33 cl.», «Patatas fritas Marca M de 130 g.», etc.

•

Objetos/instancias de la clase TipoProducto: «Refresco», «Snack», «Detergente», etc.

•

Objetos/instancias de la clase Proveedor: «Proveedor 1», «Proveedor 2», etc.

Finalmente, vemos que las instancias de las clases se relacionan entre sí mediante asociaciones binarias. El razonamiento es lógico, la destrucción de un almacén no conlleva la destrucción de un producto ni viceversa; si dejan de fabricar un producto –por ejemplo, «Cerveza Marca X de 33 cl.»–, este hecho no conlleva la desaparición de un tipo de produc...