Algoritmos y Programación III

Presentación del tema: "Algoritmos y Programación III"— Transcripción de la presentación:

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

2 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

3 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

4 Mecanismos de abstracción
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)

5 Herencia (I) En Java, para indicar herencia
public 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!

6 Herencia (II) “Casteo” hacia arriba automático Otro caso
Elipse e = new Elipse(); Figura f = e; // válido y seguro // e = f; inválido e inseguro Otro caso public 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

7 Herencia (III) O colecciones polimorfas Pero
public 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

8 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 {...}

9 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

10 Constructores Los constructores no se heredan Receta 1 Receta 2
Cada clase debe tener el suyo Receta 1 Llamar al constructor del ancestro al principio del constructor propio public 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

11 Redefinición (I) Se puede volver a definir un método en una clase descendiente:

12 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

13 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

14 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

15 Herencia múltiple: no en Java
Las clases dejaron de ser excluyentes

16 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

17 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

18 Métodos virtuales (I) public void dibujarTodas {
for (int i = 0; i < cantFiguras; i++) v[i].dibujar(); } public void mover (int x, int y) { borrar(); nuevasCoordenadas(x,y); dibujar(); }

19 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

20 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

21 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);

22 Métodos abstractos Nunca va a ser invocado No tiene implementación
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();

23 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”

24 En UML

25 Interfaces (I) Nombre confuso Son grupos de métodos sin implementar

26 Interfaces (II) Son como clases Ejemplo Uso Corolario Abstractas
Todos los métodos abstractos Ejemplo public interface Imprimible { void imprimir(); // público y abstracto por defecto } Uso public class Vector extends Matriz implements Imprimible {...} Corolario Si una clase declara implementar una interfaz y no define uno de sus métodos es abstracta

27 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

28 Interfaces y polimorfismo

29 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.

30 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; }

31 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.

32 Clases dentro de métodos
public class Externa { //... public void m() { class Interna extends Base { // ... } Interna i = new Interna();

33 Clases internas anónimas
public class Externa { //... public void m() { // ... return new Base() { // declaración de la clase anónima ... }

34 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

35 Qué sigue Excepciones Colecciones RTTI y reflexión Un poco más de UML
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

36 Muchas Gracias. Carlos Fontela, 2005