TEMA 2. RELACIONES ENTRE CLASES. HERENCIA …

1 tema 2 . RELACIONES ENTRE CLASES. HERENCIA ENTRE CLASES.. 1 COMUNICACI N ENTRE DISTINTAS CLASES .. 3 CLASES QUE CONTIENEN OBJETOS COMO ATRIBUTOS: ALGUNOS EJEMPLOS CONOCIDOS .. 3 RELACIONES DE AGREGACI N .. 4 RELACIONES DE ASOCIACI N .. 9 IMPLEMENTACI N DE RELACIONES DE AGREGACI N Y ASOCIACI N EN C++ Y JAVA .. 11 RELACIONES DE ESPECIALIZACI N/GENERALIZACI N .. 31 DEFINICI N DE LA RELACI N DE HERENCIA ENTRE CLASES .. 35 REPRESENTACI N DE RELACIONES DE HERENCIA EN UML .. 36 DECLARACI N Y DEFINICI N DE RELACIONES DE HERENCIA EN C++ 37 DECLARACI N Y DEFINICI N DE RELACIONES DE HERENCIA EN JAVA 42 VENTAJAS DEL USO DE RELACIONES DE HERENCIA : REUTILIZACI N DE C DIGO Y POLIMORFISMO DE TIPOS DE 46 REUTILIZACI N DE C DIGO .. 46 POSIBILIDAD DE DEFINICI N DE ESTRUCTURAS GEN RICAS .. 47 REDEFINICI N DE M TODOS EN CLASES HEREDADAS .. 49 MODIFICADOR DE USO PROTEGIDO : POSIBILIDADES DE USO.

2 61 REPRESENTACI N DE RELACIONES DE HERENCIA EN DIAGRAMAS UML . 64 PROGRAMACI N EN JAVA Y C++ DE RELACIONES DE 64 1 tema 2 . RELACIONES ENTRE CLASES. HERENCIA ENTRE CLASES. Introducci n al tema: En el Tema 1 nos hemos ocupado de c mo se debe implementar una clase en un lenguaje orientado a objetos y las mejoras que esto supon a con respecto a la implementaci n de TAD s en lenguajes estructurados. En este tema nos vamos a ocupar de hacer que esas mismas clases se comuniquen ENTRE s , por medio de lo que llamaremos RELACIONES ENTRE clases . En primer lugar (Secci n ) veremos c mo distintas clases se pueden comunicar ENTRE s y colaborar por medio del paso de mensajes. Para ello deberemos recuperar las nociones de parte p blica y parte privada de una clase. En la Secci n pasaremos a enunciar dos de los tipos de RELACIONES ENTRE clases m s conocidos (asociaci n y agregaci n) y a ver c mo se pueden representar los mismos en los lenguajes de programaci n.

3 Esto nos servir para ver c mo los lenguajes de especificaci n (por ejemplo, UML) tienen una sintaxis m s rica que la mayor parte de los lenguajes de POO, que ofrecen un n mero limitado de mecanismos para implementar RELACIONES ENTRE clases. Despu s de algunos ejemplos de RELACIONES ENTRE clases, pasaremos a ver la parte central del tema 2 , que son las RELACIONES de especializaci n/generalizaci n (tambi n conocidas como HERENCIA ). A ello dedicaremos el resto del tema 2 . En particular, la Secci n la emplearemos en enunciar ejemplos de RELACIONES de especializaci n/generalizaci n basados en los ejemplos hasta ahora introducidos en la asignatura. Nuestro prop sito ser observar que una relaci n ENTRE clases que permita agrupar clases con una serie de caracter sticas (atributos y m todos) comunes nos va a permitir reutilizar el c digo de nuestros programas (y simplificar el mantenimiento del mismo).

4 A partir de estos ejemplos, en la Secci n enunciaremos formalmente la noci n de HERENCIA ENTRE clases. En la Secci n recuperaremos algunas de las ventajas principales de utilizar RELACIONES de HERENCIA ENTRE clases que ya habr n ido apareciendo a lo largo del Tema y las ilustraremos con ejemplos. La Secci n la dedicaremos a introducir aquellas RELACIONES de HERENCIA que no heredan ntegramente el comportamiento de sus superclases, sino que lo modifican por medio de la redefinici n de algunos de sus m todos. En la Secci n recuperaremos los modificadores de acceso que introdujimos en la Secci n del Tema 1 y a adiremos el modificador de acceso protegido (o protected) explicando su comportamiento en RELACIONES de HERENCIA . La Secci n la dedicaremos a conocer la representaci n de RELACIONES ENTRE clases en diagramas UML (tanto las de asociaci n como las de agregaci n, y 2por supuesto, las de generalizaci n/especializaci n).

5 Finalmente, en la Secci n veremos la sintaxis en Java y en C++ que permite definir RELACIONES de HERENCIA ; aqu prestaremos especial atenci n a la definici n de los constructores de subclases as como a la declaraci n y definici n de objetos de las mismas. En realidad, a lo largo del tema 2 habremos ido introduciendo las notaciones propias de UML, Java y C++ para definir RELACIONES ENTRE clases, as que las Secciones y servir n como compendio de la notaci n que ya habremos introducido. Los objetivos principales del Tema son que los alumnos conozcan los diversos tipos de RELACIONES ENTRE clases existentes, que sean capaces de identificar por s mismos RELACIONES de generalizaci n/especializaci n, que utilicen los mecanismos de representaci n, declaraci n y definici n de RELACIONES de HERENCIA ENTRE clases en UML, Java y C++, y que conozcan y apliquen las nociones de redefinici n de m todos y de atributos protegidos en ejemplos de programaci n.

6 ENTRE los objetivos del Tema no se encuentra la identificaci n de RELACIONES de asociaci n y de agregaci n ENTRE clases que los alumnos aprender n en asignaturas m s dirigidas al dise o de sistemas software. Una posible referencia sobre RELACIONES ENTRE clases y su implementaci n en Java son los cap tulos 8, 16 y 17 de Practical Object-Oriented development with UML and Java , Richard C. Lee, William Tepfenhart, en Prentice Hall (2002). COMUNICACI N ENTRE DISTINTAS CLASES En el Tema 1 pusimos especial nfasis en comprender c mo los usuarios y clientes de una clase se comunicaban con la misma. Para posibilitar esta comunicaci n de una clase con el exterior (en el Tema 1 entend amos por exterior el nico usuario o cliente que defin amos, el programa principal) utiliz bamos la parte p blica (o interfaz) de la misma (tal y como introdujimos en la Secci n ).

7 En el tema 2 aumentaremos el mbito de lo que entendemos como usuarios o clientes de una clase tambi n a otras clases. Veremos (en la Secci n y ) que dos (o m s clases) pueden tener una relaci n ENTRE ellas de asociaci n, agregaci n o de especializaci n/generalizaci n. En el primer caso y en el segundo, la comunicaci n ENTRE clases ser posible s lo a trav s de la parte p blica de las clases correspondientes (o, en Java, a las partes declaradas como package ). Conviene recordar ahora que el mbito de visibilidad de un m todo o atributo p blico es cualquier otra clase o fragmento de c digo que haya en nuestra aplicaci n. En las RELACIONES de HERENCIA veremos que adem s existe un modificador de acceso especial, llamado protected que permite que un atributo o m todo de una clase sea visible desde las clases que heredan de la misma.

8 3En cualquier caso, nunca una clase podr acceder a un atributo que sea privado en otra, independientemente de c mo stas est n relacionadas. Manual de buenas pr cticas: incidiendo en la idea de ocultaci n de informaci n que presentamos en la Secci n , el programador de una clase debe, por lo general, declarar los atributos (o estado de la misma) como privados (private) y hacer que sean m todos los que accedan a esa informaci n. De esta forma facilitar que si se modifica la implementaci n de la misma, los usuarios (ya sea el programa principal, u otras clases) no perciban ni sufran las consecuencias de estos cambios. CLASES QUE CONTIENEN OBJETOS COMO ATRIBUTOS: ALGUNOS EJEMPLOS CONOCIDOS En esta Secci n presentaremos dos tipos de RELACIONES ENTRE clases. En primer lugar hablaremos de RELACIONES de agregaci n ENTRE clases (Secci n ), y luego pasaremos a hablar de RELACIONES de asociaci n (Secci n ).

9 Una vez m s, insistimos en la idea de que el objetivo de este curso no es tanto que el alumno identifique tipos de RELACIONES ENTRE clases, sino que comprenda los mecanismos de comunicaci n ENTRE la mismas. Por eso esta Secci n tendr un contenido basado en ejemplos que permitan ver estos tipos de RELACIONES en ejemplos reales. RELACIONES DE AGREGACI N Las RELACIONES de agregaci n se basan en la idea de observar o entender un objeto como una composici n de otros objetos. Desde nuestro punto de vista, las RELACIONES de agregaci n se entender n como RELACIONES en las cuales una serie de clases aparecen como tipos de los atributos de otra clase. Estas RELACIONES se conocen tambi n como RELACIONES todo - partes . El todo est representado por la clase que aglutina a las otras clases, y las partes est n dadas por las diversas clases que aparecen.

10 La mejor forma de identificar si nos encontramos ante una relaci n de agregaci n es preguntarnos si la clase que queremos definir tiene un (en ingl s, has - a ) atributo de la otra clase que estemos usando (de ah que en ciertas referencias se definan como RELACIONES has - a ). En realidad, hemos tratado ciertos ejemplos de agregaci n (en Java) desde que comenzamos el curso, ya que hemos usado la clase propia de Java String ( ) para definir nuevas clases. Utilizaremos alguno de esos ejemplos para ilustrar la sintaxis en UML y Java de las RELACIONES de agregaci n. 4+CuentaBancaria(entrada : String, entrada : String)+getNumeroCuenta() : String+getNombreTitular() : String+getSaldo () : double+setSaldo (entrada : double) : void+getNumeroOperaciones() : int+ingresarCantidad(entrada : double) : void+retirarCantidad(entrada : double) : void+getCuentasCreadas() : int+setCuentasCreadasNull() : void-numeroCuenta : String-nombreTitular : String-saldo : double-numeroOperaciones : int-MAXIMOREINTEGRO : double = 5000-cuentasCreadas : int = 0 CuentaBancariaStringString En la anterior imagen podemos observar c mo se representan en UML las RELACIONES de agregaci n.