36
Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Embed Size (px)

Citation preview

Page 1: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Algoritmos y Programación III

2. Herencia, polimorfismo,

interfaces

Carlos Fontela, 2005

Page 2: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 2Algoritmos y Programación IIICarlos Fontela, 2005

Temario

Reutilización con composición y con herencia Redefinición Cuándo usar herencia y cuándo composición Polimorfismo y vinculación tardía Métodos virtuales Métodos y clases abstractas Interfaces Clases internas

Page 3: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 3Algoritmos y Programación IIICarlos Fontela, 2005

Reutilización

Dos acepciones Usar clases en una aplicación diferente

a que motivó su primer uso Extensión: Usar clases como base para

la creación de otras nuevas con comportamiento parecido• No necesitamos el código fuente

Page 4: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 4Algoritmos y Programación IIICarlos Fontela, 2005

Mecanismos de abstracción

Mecanismos clasificación (individuo-especie)

• Lassie - perro agrupación (entre individuos)

• Auto - rueda generalización (entre especies)

• Lápiz – herramienta de escritura

En OO instanciación (objeto-clase) agregación (objeto-objeto) herencia (clase-clase)

Page 5: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 5Algoritmos y Programación IIICarlos Fontela, 2005

Herencia (I)

En Java, para indicar herenciapublic class Elipse extends Figura { ... }

Elipse tiene, por lo menos: los mismos atributos de Figura los mismos métodos de Figura puede agregar atributos y métodos puede redefinir métodos

¡Reutilización de clases compiladas!

Page 6: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 6Algoritmos y Programación IIICarlos Fontela, 2005

Herencia (II)

“Casteo” hacia arriba automáticoElipse e = new Elipse();

Figura f = e; // válido y seguro

// e = f; inválido e inseguro

Otro casopublic void p (Figura x) { … }

// … luego será invocado:

p(e); // e es de tipo Elipse

Los llamamos “objetos polimorfos” Parecen una cosa pero son otra f es una Elipse aunque se la trate como Figura

Page 7: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 7Algoritmos y Programación IIICarlos Fontela, 2005

Herencia (III)

O colecciones polimorfaspublic Figura[ ] v;

// luego…

v[1] = unaElipse;

v[2] = unCirculo;

v[3] = unTrianguloRectangulo;

Pero Estamos perdiendo información del objeto Cada v[i] sólo va a tener disponibles los

atributos y métodos públicos de Figura Ya volveremos sobre esto

Page 8: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 8Algoritmos y Programación IIICarlos Fontela, 2005

Más sobre herencia en Java

Jerarquía de raíz única Clase Object Todo se puede transformar en un Object Atributos y métodos comunes a todas las

clases Otras importantes consecuencias

Posibilidad de evitar la herencia Declaramos la clase como “final”:

• Ejemplo: String

public final class String {...}

Page 9: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 9Algoritmos y Programación IIICarlos Fontela, 2005

Más sobre visibilidad

Atributos y métodos con visibilidad “de paquete” (por defecto) Sólo pueden verse dentro de su mismo paquete

Atributos y métodos protegidos (protected) Son visibles sólo para las clases descendientes y las del

propio paquete

Poco uso; riesgos

Clases con visibilidad “de paquete” Sólo se pueden usar dentro de su paquete

No hay clases privadas ni protegidas

Page 10: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 10Algoritmos y Programación IIICarlos Fontela, 2005

Constructores

Los constructores no se heredan Cada clase debe tener el suyo

Receta 1 Llamar al constructor del ancestro al principio del

constructor propiopublic Derivada() {

super();...

} Automático con constructores por defecto

Receta 2 Llamar al constructor de un objeto contenido desde el

constructor del objeto compuesto Esto nunca es automático

Page 11: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 11Algoritmos y Programación IIICarlos Fontela, 2005

Redefinición (I)

Se puede volver a definir un método en una clase descendiente:

+depositar()+retirar()

Cuenta

+depositar()+retirar()

CajaAhorro

+depositar()+retirar()

CuentaCorriente

+depositar()+retirar()

CAComun

+depositar()+retirar()

CAEspecial

Page 12: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 12Algoritmos y Programación IIICarlos Fontela, 2005

Redefinición (II)

Debe preservar la semántica (significado)

Obligatoria Si la implementación debe ser diferente

Caso de imprimirAtributos

Optativa Razones, en general, de eficiencia

Caso de longitud de Elipse

Los métodos deben tener la misma signatura

Page 13: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 13Algoritmos y Programación IIICarlos Fontela, 2005

Redefinición (III)

Los métodos privados no pueden ser redefinidos Se estaría definiendo uno nuevo

Posibilidad de evitar la redefinición Métodos “final”

public final void m() {...}

No se puede redefinir un método haciéndolo más privado

Sobrecarga y redefinición Redefinición se hace con la misma signatura

Si no, es sobrecarga

Page 14: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 14Algoritmos y Programación IIICarlos Fontela, 2005

Composición vs. Herencia

Herencia: relación “es un”

Composición/agregación: “contiene”

“hace referencia”

“es parte de”

Mito: en POO todo es herencia

Mal ejemplo: Stack en Java 1.0/1.1 ¡una pila no es un vector!

Herencia si se va a reutilizar la interfaz Stack es un mal ejemplo

Page 15: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 15Algoritmos y Programación IIICarlos Fontela, 2005

Herencia múltiple: no en Java

Inmueble

ActivoAsegurable

Mueble

Auto

Las clases dejaron de ser excluyentes

Page 16: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 16Algoritmos y Programación IIICarlos Fontela, 2005

Problemas de la herencia

Difícil construir buenas jerarquías de tamaño mediano a grande.

Dificultad de un buen manejo de toda la jerarquía.

Mayores costos de aprendizaje.

Importante Buen diseño de clases y paquetes

Buena documentación• puede ser tipo javadoc

Page 17: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 17Algoritmos y Programación IIICarlos Fontela, 2005

Polimorfismo

Objetos de distintas clases de una misma familia entienden los mismos mensajes Igual semántica o significado Implementaciones diferentes Un mismo mensaje puede provocar la

invocación de métodos distintos

Vinculación tardía Se retarda la decisión sobre el tipo del objeto

hasta el momento en que vaya a ser utilizado el método

Page 18: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 18Algoritmos y Programación IIICarlos Fontela, 2005

Métodos virtuales (I)

public void mover (int x, int y) {

borrar();

nuevasCoordenadas(x,y);

dibujar();

}

public void dibujarTodas {

for (int i = 0; i < cantFiguras; i++)

v[i].dibujar();

}

+dibujar()+borrar()+nuevasCoordenadas()+mover()

Figura

+dibujar()

Elipse

+dibujar()

Cuadrilatero

+dibujar()

Triangulo

+dibujar()

Otros

+dibujarTodas()

VectorFiguras

1 *

Page 19: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 19Algoritmos y Programación IIICarlos Fontela, 2005

Métodos virtuales (II)

// llama al dibujar de Elipse:

unaElipse.mover();

// llama al dibujar de Triangulo:

unTriangulo.mover();

// llama al dibujar de la clase de cada v[i]:

v.dibujarTodas();

// porque dibujar es virtual

En Java la “virtualidad” se da por defecto En otros lenguajes no Métodos privados y final no son virtuales

Page 20: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 20Algoritmos y Programación IIICarlos Fontela, 2005

Métodos virtuales (III)

Los métodos virtuales agregan ineficiencias Pero garantizan reutilización Eliminar la “virtualidad” sólo si se demuestra

que no se van a redefinir y la presunta ineficiencia

Un método debe ser virtual sí o sí cuando se lo redefinirá y es llamado desde: Un método no redefinido en una clase ancestro. Un método de una clase que contenga como

atributo algún objeto de una clase ancestro

Page 21: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 21Algoritmos y Programación IIICarlos Fontela, 2005

Caso típico estándar

En Object toString, redefinible System.out.println usa toString()

Si quiero que un objeto sea imprimible, debo redefinir toString: En CtaCte

public String toString() {return nro+titular+Double.toString(saldo); }

Luego...CtaCte cc = new CtaCte(12,”Juan”);System.out.println(cc);

Page 22: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 22Algoritmos y Programación IIICarlos Fontela, 2005

Métodos abstractos

Nunca va a ser invocado Caso del dibujar de Figura

Pero se necesita para el compilador

No tiene implementación

Corolarios Debe redefinirse

Debe ser virtual

En Java: public void abstract dibujar();

Page 23: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 23Algoritmos y Programación IIICarlos Fontela, 2005

Clases abstractas

No tienen instancias Caso de Figura Pero pueden tener constructor

• ¡que no debe ser llamado nunca!

Generalizan estructura y comportamiento de varias clases Caso del método mover O crean una familia

En Java: Si se declara “abstract” Si tiene métodos abstractos

• En este caso, declarar “abstract”

Page 24: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 24Algoritmos y Programación IIICarlos Fontela, 2005

En UML

+depositar()+retirar()

Cuenta

+depositar()+retirar()

CajaAhorro

+depositar()+retirar()

CuentaCorriente

+depositar()+retirar()

CAComun

+depositar()+retirar()

CAEspecial

Page 25: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 25Algoritmos y Programación IIICarlos Fontela, 2005

Interfaces (I)

Nombre confuso Son grupos de métodos sin implementar

+imprimir()

«interface»Imprimible

-dia : int-mes : int-anio : int

Fecha

Vector

Matriz

MatrizCuadrada

Page 26: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 26Algoritmos y Programación IIICarlos Fontela, 2005

Interfaces (II)

Son como clases Abstractas Todos los métodos abstractos

Ejemplopublic interface Imprimible {

void imprimir(); // público y abstracto por defecto}

Usopublic class Vector extends Matriz implements Imprimible {...}

Corolario Si una clase declara implementar una interfaz y no

define uno de sus métodos es abstracta

Page 27: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 27Algoritmos y Programación IIICarlos Fontela, 2005

Interfaces (III)

Una clase puede implementar varias Ojo con los conflictos de nombres

Hay herencia entre interfaces

¡Variables cuyo tipo es una interfaz!Imprimible p = new Fecha(20,6,1964);

Imprimible[ ] v = new Imprimible[3];

v[0] = new Fecha(20,1,2000);

v[1] = new Vector();

v[2] = new Fecha(8,6,2002);

for (int i=0; i < 3; i++) v[i].imprimir();

Ojo que no estoy instanciando la interfaz sino una clase

Page 28: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 28Algoritmos y Programación IIICarlos Fontela, 2005

Interfaces y polimorfismo

Page 29: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 29Algoritmos y Programación IIICarlos Fontela, 2005

Interfaces predefinidas

Caso de Comparable En java.lang.Comparable

interface Comparable {

int compareTo (Object o);

}

Devuelve valores <0, 0 o >0 ¡Muy útil en colecciones!

Hay otras predefinidas Comparator, Serializable, Cloneable, etc.

Page 30: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 30Algoritmos y Programación IIICarlos Fontela, 2005

Uso de Comparable

public class Fraccion implements Comparable {

private int n; private int d;

// otros métodos

public int compareTo(Object otro) {

Fraccion otroR = (Fraccion)otro;

if (n * otroR.d > d * otroR.n)

return 1;

else if (n * otroR.d < d * otroR.n)

return -1;

else return 0;

}

}

Page 31: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 31Algoritmos y Programación IIICarlos Fontela, 2005

Clases internas

Pueden utilizar métodos y atributos privados de

su clase externa (sin relación de herencia).

Pueden ser descendientes de cualquier clase

visible de la clase externa.

En una clase descendiente de la externa se

puede declarar una clase interna que descienda

de la interna del ancestro.

Se usan poco.

Page 32: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 32Algoritmos y Programación IIICarlos Fontela, 2005

Clases dentro de métodos

public class Externa {

//...

public void m() {

class Interna extends Base {

// ...

}

Interna i = new Interna();

// ...

}

}

Page 33: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 33Algoritmos y Programación IIICarlos Fontela, 2005

Clases internas anónimas

public class Externa {

//...

public void m() {

// ...

return new Base() {

// declaración de la clase anónima ...

}

}

}

Page 34: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 34Algoritmos y Programación IIICarlos Fontela, 2005

Resumen Herencia para relaciones “es un” Composición para relaciones “es parte de” Redefinición permite cambiar

implementación manteniendo la semántica Métodos virtuales aseguran reutilización al

máximo Métodos y clases abstractas son de uso bien

concreto y habitual Interfaces son grupos de métodos sin

implementar Pero se usan casi como clases

Page 35: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Página 35Algoritmos y Programación IIICarlos Fontela, 2005

Qué sigue

Excepciones Manejo de problemas en tiempo de

ejecución

Colecciones RTTI y reflexión

Información sobre tipos en tiempo de ejecución

Un poco más de UML

Page 36: Algoritmos y Programación III 2. Herencia, polimorfismo, interfaces Carlos Fontela, 2005

Muchas Gracias.

Carlos Fontela, 2005