PDF de programación - Herencia y Relaciones entre clases

fundamentos de programación
(unidad 7) herencia y relaciones entre clases





Para ver una copia completa de la licencia, acudir a la
dirección http://creativecommons.org/licenses/by-nc-sa/2.5/es/legalcode.es



(3)



(7)

herencia y

relaciones entre

clases

esquema de la unidad

(7.1) relaciones entre clases

(7.1.1) asociaciones
(7.1.2) agregación y composición

(7.2) herencia

(7.3) casting de clases

(7.3.1) instanceof

(7.4) clases abstractas
(7.5) final
(7.6) interfaces

(7.2.1) introducción
(7.2.2) métodos y propiedades heredables. modificador protected
(7.2.3) anulación de métodos
(7.2.4) constructores

__________________________________________ 6

____________________________________________________________ 6

_______________________________________________ 8

______________________________________________________ 9

___________________________________________________________ 9

_______________ 11

________________________________________________ 12

_________________________________________________________ 14

_______________________________________________ 18

____________________________________________________________ 19

_______________________________________________ 19

__________________________________________________________ 21

____________________________________________________ 23

______________________________________________________ 23

_________________________________________________ 23

_________________________________________________________ 24

__________________________________________________ 25

___________________________ 25

________________________________________________ 26

______________________________________ 27

__________________________________________________________ 28

________________________________________________________ 28

______________________________________________________ 29

___________________________ 30


(7.6.1) utilizar interfaces
(7.6.2) creación de interfaces
(7.6.3) subinterfaces
(7.6.4) variables de interfaz
(7.6.5) interfaces como funciones de retroinvocación

(7.7.1) comparar objetos. método equals
(7.7.2) código hash
(7.7.3) clonar objetos
(7.7.4) método toString
(7.7.5) lista completa de métodos de la clase Object

(7.7) la clase Object

(5)

fundamentos de programación
(unidad 7) relaciones entre clases. herencia


(7.8) clases internas

(7.8.1) uso de clases internas
(7.8.2) clases internas regulares
(7.8.3) acceso a propiedades
(7.8.4) clases internas a un método
(7.8.5) clases internas dentro de un bloque
(7.8.6) clases internas anónimas
(7.8.7) clases internas estáticas
(7.9) creación de paquetes

________________________________________________ 30

__________________________________________________ 30

_______________________________________________ 31

_________________________________________________ 32

___________________________________________ 33

____________________________________ 34

______________________________________________ 35

________________________________________________ 37

_________________________________________ 38

__________________________________________ 39


(7.9.1) organización de los paquetes

(7.1) relaciones entre clases

Hasta lo visto en los temas anteriores, se puede entender que el diseño de una
aplicación es prácticamente el diseño de una clase. Sin embargo en realidad
una aplicación es un conjunto de objetos que se relacionan. Por ello en el
diagrama de clases se deben indicar la relación que hay entre las clases. En
este sentido el diagrama de clases UML nos ofrece distintas posibilidades.

(7.1.1) asociaciones

Las asociaciones son relaciones entre clases. Es decir, marcan una
comunicación o colaboración entre clases. Dos clases tienen una asociación si:
♦ Un objeto de una clase envía un mensaje a un objeto de la otra clase.
Enviar un mensaje, como ya se comentó en el tema anterior es utilizar
alguno de sus métodos o propiedades para que el objeto realice una
determinada labor.

♦ Un objeto de una clase, crea un objeto de otra clase.
♦ Una clase tiene propiedades cuyos valores son objetos o colecciones de

objetos de otra clase

♦ Un objeto de una clase recibe como parámetros de un método objetos

de otra clase.

En UML las asociaciones se representan con una línea entre las dos clases
relacionadas, encima de la cual se indica el nombre de la asociación y una
flecha para indicar el sentido de la asociación. Ejemplo:

Ilustración 7-1, Asociación simple en UML



Como se observa en el ejemplo la dirección de la flecha es la que indica que
es el usuario el que alquila los libros. Los números indican que cada usuario
puede alquilar de cero a más (el asterisco significa muchos) libros. Esos
números se denominan cardinalidad, e indican con cuántos objetos de la clase

(6)

1er curso de administración de sistemas informáticos
autor: Jorge Sánchez – www.jorgesanchez.net

se puede relacionar cada objeto de la clase que está en la base de la flecha.
Puede ser:

♦ 0..1. Significa que se relaciona con uno o ningún objeto de la otra

clase.

♦ 0..*. Se relaciona con cero, uno o más objetos
♦ 1..* Se relaciona al menos con uno, pero se puede relacionar con más
♦ un número concreto. Se puede indicar un número concreto (como 3
por ejemplo) para indicar que se relaciona exactamente con ese
número de objetos, ni menos, ni más.

La dirección de la flecha determina de dónde a dónde nos referimos. Así esa
misma relación al revés:

Ilustración 7-2, Asociación UML

Por eso se suele reflejar así de forma completa:

Ilustración 7-3, Asociación UML completa



En muchos casos en las asociaciones no se indica dirección de flecha, se
sobreentenderá que la asociación va en las dos direcciones.

Las asociaciones como es lógico implican decisiones en las clases. La clase
usuario tendrá una estructura que permita saber qué libros ha alquilado. Y el
libro tendrá al menos una propiedad para saber qué usuario le ha alquilado.
Además de métodos para relacionar los usuarios y los libros.

Normalmente la solución a la hora de implementar es que las clases
incorporen una propiedad que permita relacionar cada objeto con la otra
clase. Por ejemplo si la clase usuario Alquila cero o un libro:

public class Usuario{
…
Libro libro; //representa la relación Usuario->Libro con

…

//cardinalidad 0..1 o 1



(7)

fundamentos de programación
(unidad 7) relaciones entre clases. herencia


Con una cardinalidad fija pero mayor de uno (por ejemplo un usuario siempre
alquila 3 libros):

public class Usuario{
…
Libro libro[]; //representa la relación Usuario->Libro con

…

//cardinalidad 0..1 o 1



Si la cardinalidad es de tamaño indefinido (como 1..* por ejemplo) entonces la
propiedad será una colección de libros (en temas posteriores se habla sobre
colecciones de datos).

(7.1.2) agregación y composición

Son asociaciones pero que indican más información que una asociación normal.
Definen asociaciones del tipo es parte de o se compone de.

agregación

Indica que un elemento es parte de otro. Indica una relación en definitiva de
composición. Así la clase Curso tendría una relación de composición con la
clase Módulo.

Ilustración 7-4, Diagrama UML de agregación



Cada curso se compone de tres o más módulos. Cada módulo se relaciona con
uno o más cursos.

En Java al final se resuelven como las asociaciones normales, pero el

diagrama representa esta connotación importante.

composición



La composición indica una agregación fuerte, de hecho significa que una clase
consta de objetos de otra clase para funcionar. La diferencia es que cada
objeto que compone el objeto grande no puede ser parte de otro objeto, es
decir pertenece de forma única a uno.

La existencia del objeto al otro lado del diamante está supeditada al

objeto principal y esa es la diferencia con la agregación.

Ejemplo:

Ilustración 7-5, Diagrama UML de composición



(8)

1er curso de administración de sistemas informáticos
autor: Jorge Sánchez – www.jorgesanchez.net

En este caso se refleja que un edificio consta de pisos. De hecho con ello lo
que se indica es que un piso sólo puede estar en un edificio. La existencia del
piso está ligada a la del edificio. Como se ve la asociación es más fuerte.

implementación

La implementación en Java de clases con relaciones de agregación y
composición es similar. Pero hay un matiz importante. Puesto que en la
composición, los objetos que se usan para componer el objeto mayor tienen
una existencia ligada al mismo, se deben crear dentro del objeto grande. Por
ejemplo (composición):

public class Edificio {
private Piso piso[];
public Edificio(…..){



piso=new Piso[x]; //composición
……

En la composición (como se observa en el ejemplo), la existencia del piso está
ligada al edificio por eso los pisos del edificio se deben de crear dentro de la
clase Edificio y así cuando un objeto Edificio desaparezca, desaparecerán los
pisos del mismo.

Eso no debe ocurrir si la relación es de agregación. Por eso en el caso de los
cursos y los módulos, como los módulos no tienen esa dependencia de
existencia según el diagrama, seguirán existiendo cuando el módulo
desaparezca, por eso se deben declarar fuera de la clase cursos. Es decir, no
habrá new para crear módulos en el constructor. Sería algo parecido a esto:

public class Cursos {
private Módulo módulos[];
public Edificio(….., Módulo m[]){



módulos=m; //agregación
……



(7.2) herencia

(7.2.1) introducción

La herenc