7: Polimorfismo El polimorfismo es la tercera característica esencial de los lenguajes de programación orientados a objetos, después de la abstracción de datos y la herencia.

Esto aporta otra dimensión para separar interfaz de implementación, para separar el qué del cómo. El polimorfismo nos permite mejorar la organización y comprensión del código así como la creación de programas extensibles que pueden "crecer" no sólo durante la creación del proyecto, sino también cuando se diseñen nuevas características.

La encapsulación crea un nuevo tipo de datos combinando características y comportamientos. La implementación oculta la interfaz de la implementación haciendo los detalles privados. Esta clase de organización mecánica tiene sentido para alguien que proceda de un lenguaje procedimental. Pero el polimorfismo trata del desacoplamiento de en términos de tipos . En él ultimo capitulo se vio cómo la herencia permite el tratamiento de un objeto como su propio tipo o su tipo base. Esta habilidad es crítica ya que permite que muchos tipos (derivados del mismo tipo base) sean creados como si fueran uno solo, y una sola pieza de código funcionará con todos estos tipos diferentes de la misma forma. La llamada a un método polimórfico permite a un tipo expresar su diferencia con otro similar, ambos derivados de la misma clase. Esta distinción es expresada a través de diferencias en el comportamiento de los métodos a los que podemos invocar a través de la clase.

En este capitulo aprenderemos a cerca del polimorfismo (también llamado enlazado dinámico, enlazado diferido o enlazado en tiempo de ejecución ) comenzando por lo básico, con simples ejemplos en los que lo fundamental es el comportamiento polimórfico del programa.

Conversión ascendente

En el capitulo 6 mostramos como puede usarse un objeto como su propio tipo o como un objeto de su tipo base. Tomar un manejador de objeto y tratarlo como el manejador de su tipo base se denomina upcasting (conversión ascendente), dado que el árbol de herencia se dibujado con la clase base en la cima.

En el siguiente ejemplo mostramos un problema importante que surge: (ver la página XX si tiene problemas ejecutando este programa)

//: Music.java // Inheritance & upcasting package c07;

class Note { private int value; private Note(int val) { value = val; } public static final Note middleC = new Note(0), cSharp = new Note(1), cFlat = new Note(2); } // Etc. class Instrument { public void play(Note n) { System.out.println("Instrument.play()"); } } // Wind objects are instruments // because they have the same interface: class Wind extends Instrument { // Redefine interface method: public void play(Note n) { System.out.println("Wind.play()"); } } public class Music { public static void tune(Instrument i) { // ... i.play(Note.middleC); } public static void main(String[] args) { Wind flute = new Wind(); tune(flute); // Upcasting } } ///:~

El método Music.tune() acepta un manejador instrumental , pero también cualquier tipo derivado de un instrumento. En la función main() podemos ver como se pasa el manejador Wind al método tune() sin necesidad de cast. Esto es aceptable; en Wind debe existir el interface de Instrument , ya que Wind lo hereda de él. La conversión hacia arriba desde Wind hacia Instrument puede "estrechar" el interfaz, pero no puede hacer nada menos el interface completo de Instrument .

¿Por qué upcast?

Este programa puede parecer extraño. ¿Por qué debe alguien olvidar intencionadamente el tipo de un objeto? Esto es lo que sucede cuando se realiza el

upcast, y parece que seria mucho más simple si tune() simplemente el manejador Wind como su argumento. Esto trae un punto esencial: suponga que necesita escribir un nuevo tune() para cada tipo de Instrument en su sistema. Suponga que seguimos ese razonamiento y añadimos instrumentos de cuerdas y metálicos:

//: Music2.java // Overloading instead of upcasting class Note2 { private int value; private Note2(int val) { value = val; } public static final Note2 middleC = new Note2(0), cSharp = new Note2(1), cFlat = new Note2(2); } // Etc. class Instrument2 { public void play(Note2 n) { System.out.println("Instrument2.play()"); } } class Wind2 extends Instrument2 { public void play(Note2 n) { System.out.println("Wind2.play()"); } } class Stringed2 extends Instrument2 { public void play(Note2 n) { System.out.println("Stringed2.play()"); } } class Brass2 extends Instrument2 { public void play(Note2 n) { System.out.println("Brass2.play()"); } } public class Music2 { public static void tune(Wind2 i) { i.play(Note2.middleC); } public static void tune(Stringed2 i) { i.play(Note2.middleC); }

public static void tune(Brass2 i) { i.play(Note2.middleC); } public static void main(String[] args) { Wind2 flute = new Wind2(); Stringed2 violin = new Stringed2(); Brass2 frenchHorn = new Brass2(); tune(flute); // No upcasting tune(violin); tune(frenchHorn); } } ///:~

Esto funciona, aunque hay mejores formas: Debemos escribir el tipo especifico del método para cada clase del nuevo Intrument2 que se añada.

Esto significa que programar más en el primer lugar, pero también significa que si se necesita añadir un nuevo método como tune() o un nuevo tipo de instrumento, tienes mucho trabajo que hacer. Añadir el echo que el compilador no dará mensajes de error si olvida sobrecargar uno de tus métodos y todo el proceso de trabajo con los tipos no se puedan manejar.

¿No será muy agradable si solo escribe un método simple que toma como clase base como su argumento, y ninguno de las derivadas clases especificas? ¿Esto es, no será agradable si se olvida que hay clases derivadas, y escribe el código para hablar solo con las clases base?

Esto es exactamente lo que el polimorfismo te permite hacer. De todos modos, la mayoría de los programadores (que proceden de programación procedural) tienen un pequeño problema con la forma que trabaja el polimorfismo.

El enriedo

La dificultad con Music.java pueden verse ejecutando el programa. La salida es Wind.play() Este es una salida "limpia", pero no parece que funcione de esa forma. Mire el método tune():

public static void tune(Instrument i) { // ... i.play(Note.middleC); }

Este recibe un manejador Instument. ¿De esta forma como puede saber el compilador que este manejador Instrument apunta a viento en este caso y no a metálicos o de cuerda? El compilador no puede saberlo. Para tomar un profundo

conocimiento de la fuente, es útil examinar el tema de binding .

Enlazado en las llamadas a métodos

Conectar una llamada de un método con el cuerpo de un método se denomina enlazado. Cuando se binding se permite antes de ejecutar el programa (por el compilador y linkador, si hay alguno), es llamado primero binding . Puede que no haya oído el termino antes por que nunca ha sido una opción con lenguajes procedurales. Los compiladores de "C" solo tienen un tipo de llamada a métodos, y esta es antes de binding .

La parte confusa de arriba del programa resuelve a cerca del early binding por que el compilador no puede saber el método correcto para llamar cuando este solo tiene un manejador Instument.

La solución se llama late binding , que significa que el binding ocurre en tiempo de ejecución basado en el tipo de objeto. Late binding también es llamado bindingdinámico o tiempo de ejecución binding . Cuando un lenguaje implementa late binding , debe haber algún mecanismo para determinar el tipo de un objeto en tiempo de ejecución y llamar al apropiado método. Esto es, el compilador todavía no saber el tipo del objeto, pero el mecanismo de llamada al método busca y llama el cuerpo del método correcto. El mecanismo late-binding varia de lenguaje a lenguaje, pero puede imaginar que algunos tipos de información deben ser instalados en los objetos.

Todos los métodos binding en Java usa late binding menos un método que ha sido declarado final. Esto significa que normalmente no necesita tomar ninguna decisión a cerca del cuando ocurrirá el late binding . (Sucederá automáticamente)

¿Por que se declara un método final? Como habrá notado en el ultimo capitulo, este previene de el sobreescribir métodos. Quizás mas importante, es efectivamente "turns off" dynamic binding , o mejor este dice al compilador que dynamic binding no es necesario. Esto permite al compilador generar un código mas eficiente para llamadas a métodos finales.

Produciendo el comportamiento correcto

Una vez que se sabe que todos los binding en Java suceden polimorficamente vía late binding , puedes escribir tu código para hablar a clases base y saber que todos las casos de clases derivadas funcionaran correctamente usando el mismo código. O para ponerlo de otra forma, tu mandas un mensaje a un objeto y dejas que el objeto escoge la correcta cosa a hacer.

El clásico ejemplo en OOP es el ejemplo de las formas. Esto es normalmente usado por que es fácil visualizarlo, pero desafortunadamente puede confundir a los programadores noveles pensando que OOP es programación solamente para gráficos, que por supuesto no es el caso.

El ejemplo de las formas tiene una clase base llamada Shape y varios tipos derivados: Circle, Square, Triangle, etc. La razón del ejemplo funciona por lo fácil que es decir "Circle es un tipo de Shape" y ser entendido. El diagrama de herencia nos enseña las relaciones:

El upcast puede ocurrir en una sentencia tan simple como:

Shape s = new Circle();

Aquí, un objeto Circle es creado y el manejador resultante es inmediatamente asignado a Shape que puede parecer ser un error (asignando un tipo a otro) y esta bien por que un es un "Shape" por la herencia. Por eso el compilador añade con las sentencias no da ningún mensaje de error.

Cuando se llama a un método de clase base (que ha sido sobrescrito en las clases derivadas):

s.draw();

De nuevo, se puede esperar que draw() de Shape es llamado por que esto es un manejador Shape, por eso, ¿como puede el compilador saber hacer algo mas? Y todavía el propio Circle.draw() es llamado por el late binding (polimorfismo). El ejemplo siguiente lo hace de una forma diferente:

//: Shapes.java // Polymorphism in Java

class Shape { void draw() {} void erase() {} } class Circle extends Shape { void draw() { System.out.println("Circle.draw()"); } void erase() { System.out.println("Circle.erase()"); } } class Square extends Shape { void draw() { System.out.println("Square.draw()"); } void erase() { System.out.println("Square.erase()"); } } class Triangle extends Shape { void draw() { System.out.println("Triangle.draw()"); } void erase() { System.out.println("Triangle.erase()"); } } public class Shapes { public static Shape randShape() { switch((int)(Math.random() * 3)) { default: // To quiet the compiler case 0: return new Circle(); case 1: return new Square(); case 2: return new Triangle(); } } public static void main(String[] args) { Shape[] s = new Shape[9]; // Fill up the array with shapes: for(int i = 0; i < s.length; i++) s[i] = randShape(); // Make polymorphic method calls: for(int i = 0; i < s.length; i++) s[i].draw(); }

} ///:~

La clase base Shape establece el interface común a todos los afectados por la herencia de Shape, esto es, todos los "shapes" pueden ser dibujados y borrados. Las clases derivados sobrescritas estas definiciones para provee un único comportamiento para cada especifico tipo de Shape.

La clase principal Shape continúe un método estático randShape() que produce un manejador a un objeto shape elegido aleatoriamente cada vez que se le llama. Notar que el upcasting sucede en las sentencias de retorno, que se toma un manejador a Circle, Squeare, o Triangle y lo envía fuera del método como un tipo devuelto, Shape. Por eso siempre que se llame a este método nunca se obtendrá un cambio para ver que tipo especifico es, desde que se retorna un manejador plain Shape. Main() contiene un array de manejadores Shape llenos de llamadas a randShape(). En este punto sabemos que tenemos Shapes, pero no sabemos nada mas especifico. De cualquier forma, cuando se avanza hacia este array y se llama Draw() para cada uno, el correcto tipo especifico comportamiento mágicamente ocurre, como se puede ver de la salida del siguiente ejemplo:

Circle.draw() Triangle.draw() Circle.draw() Circle.draw() Circle.draw() Square.draw() Triangle.draw() Square.draw() Square.draw()

Por supuesto, desde que todas las figuras son elegidas aleatoriamente cada vez, la ejecución tendrá diferentes resultados. El punto de elegir las figuras aleatoriamente es la unidad "home" el entendimiento que el compilador puede no tener conocimientos especiales que le permitan hacer las llamadas correctas en tiempo de compilación. Todas las llamadas a draw() se hacen a través de dynamic binding .

Extensibilidad

Ahora volvamos al ejemplo de los instrumentos musicales. Por el polimorfismo usted puede añadir tantos tipos nuevos como desee al sistema sin cambiar el método tune(). En un programa POO bien diseñado, la mayoría o todos nuestros métodos seguirán el modelo de tune() y se comunican solo con el interface de clases base. Semejante a un programa extensible, ya que se puede añadir nuevas funcionalidades por la heredación de nuevos tipos de datos procedentes de las

clases base comunes. Los métodos que manipulan el interface de las clases base no necesitaran ser cambiados en absoluto para acomodarlo a las nuevas clases.

Considerar que sucede si tomamos el ejemplo de los instrumentos y añadir mas métodos en las clases base y un numero de nuevas clases. Aquí esta el diagrama:

Todas estas nuevas clases funcionan correctamente con el método antiguo, sin cambiar tune(). Incluso si "tune()" esta en un fichero separado y nuevos métodos son añadidos al interface de Instrumentos tune() funciona correctamente sin recompilar. Aquí esta la implementación del diagrama siguiente:

//: Music3.java // An extensible program import java.util.*; class Instrument3 { public void play() { System.out.println("Instrument3.play()"); } public String what() { return "Instrument3"; } public void adjust() {}

} class Wind3 extends Instrument3 { public void play() { System.out.println("Wind3.play()"); } public String what() { return "Wind3"; } public void adjust() {} } class Percussion3 extends Instrument3 { public void play() { System.out.println("Percussion3.play()"); } public String what() { return "Percussion3"; } public void adjust() {} } class Stringed3 extends Instrument3 { public void play() { System.out.println("Stringed3.play()"); } public String what() { return "Stringed3"; } public void adjust() {} } class Brass3 extends Wind3 { public void play() { System.out.println("Brass3.play()"); } public void adjust() { System.out.println("Brass3.adjust()"); } } class Woodwind3 extends Wind3 { public void play() { System.out.println("Woodwind3.play()"); } public String what() { return "Woodwind3"; } } public class Music3 { // Doesn't care about type, so new types // added to the system still work right: static void tune(Instrument3 i) { // ... i.play(); } static void tuneAll(Instrument3[] e) {

for(int i = 0; i < e.length; i++) tune(e[i]); } public static void main(String[] args) { Instrument3[] orchestra = new Instrument3[5]; int i = 0; // Upcasting during addition to the array: orchestra[i++] = new Wind3(); orchestra[i++] = new Percussion3(); orchestra[i++] = new Stringed3(); orchestra[i++] = new Brass3(); orchestra[i++] = new Woodwind3(); tuneAll(orchestra); } } ///:~

Los nuevos métodos son what() que devuelve un manejador String con una descripción de la clase y adjust() que da unas formas de ajustar cada instrumento.

En Main(), cuando se pone algo en el array Intrument3 automáticamente upcast el inrumento3.

Puedes ver que el método tune() es dichosamente ignorante de todos los cambios de código que ocurren por el, y todavía funciona correctamente. Esto es exactamente lo que el polimorfismo es supuestamente provisto. Los cambios del código no causaran daños a partes del programa que debería no ser afectado. De otra forma, el polimorfismo es una de las mas importantes técnicas que permiten al programador "separar las cosas que cambian de las cosas que continúan igual".

Sobreescritura vs. Sobrecarga

Echemosle un vistazo diferente al primer ejemplo de este capítulo. En el siguiente programa el interfaz del método play() se cambia en el proceso de sobreescritura del mismo, lo que significa que no hemos sobreescrito el método, sino que lo hemos sobrecargado . Como el compilador permite la sobrecarga de métodos no da ningún error, pero el comportamiento probablemente no es lo que pretendiamos.

Aquí está el ejemplo:

//: WindError.java // Accidentally changing the interface class NoteX { public static final int MIDDLE_C = 0, C_SHARP = 1, C_FLAT = 2;

} class InstrumentX { public void play(int NoteX) { System.out.println("InstrumentX.play()"); } } class WindX extends InstrumentX { // OOPS! Changes the method interface: public void play(NoteX n) { System.out.println("WindX.play(NoteX n)"); } } public class WindError { public static void tune(InstrumentX i) { // ... i.play(NoteX.MIDDLE_C); } public static void main(String[] args) { WindX flute = new WindX(); tune(flute); // Not the desired behavior! } } ///:~

Aquí esta otro aspecto confuso que nos muestra el programa. En InstrumentX el método play() recibe un int con el identificativo NoteX . Aunque NoteX es un nombre de clase, también se puede usar como identificativo sin ningún problema. Pero en WindX , play( ) recibe una referencia a NoteX que tiene el identificador n . (No obstante también se podría haber puesto play(NoteX NoteX) sin que produzca ningún error.) Parece como si el programador intentara sobreeescribir play( ) , pero equivocandose un poco a la hora de escribirlo. El compilador, no obstante, asume que lo que se pretendía era sobrecargar y no sobreescribir el método. Notar que si seguimos la convención de nombres estándar de Java, el identificador del argumento hubiera sido noteX ('n' minuscula), que lo distinguiría del nombre de la clase.

En tune, el InstrumentX "i" es enviado el mensaje play(), con uno de los miembros de NoteX (MIDDLE_C) como un argumento. Dado que NoteX contiene definiciones enteras, esto significa que la versión entera del método ahora sobrecargado play() es llamado, y como no ha sido sobreescrito la versión clase-base es usada.

La salida es:

InstrumentX.play()

Ciertamente esto no parece ser una llamada a un método polimórfico. Una vez se entiende que esta sucediendo, usted puede arreglar el problema fácilmente, pero imagine lo dificíl que puede ser encontrar el error si este está enterrado en un programa de tamaño significante.

Clases y métodos Abstractos

En todos los ejemplos de instrumentos, los métodos en la base de clase instrumento hay siempre métodos de pruebas. Si esos métodos suenan llamadas alguna vez, estarás haciendo algo erróneo. Esto es porque el intento de un Instrumento crear un interface común para todos las clases derivadas de él.

La única razón para establecer este interface común es que pueda ser expresado diferente para cada diferente subtipo. Esto establece una forma básica, por eso puedes decir que es común a todas las clases derivadas. Otra forma de ver esto es llamar a Intrument una clase base abstracta (o simplemente clase abstracta). usted crea una clase abstracta cuando se quiere manipular un juego de clases a través de un interface común. Todos los métodos derivados de clases que emparejados la firma de la declaración de clase base será usada por el mecanismo de dynamic binding . (Sin embargo como hemos visto en la ultima sección, si el nombre del método es el mismo que el de la clase base, pero los argumentos son diferentes tendrás sobreescritura , que probablemente no es lo que quiere.)

Si tiene una clase abstracta como intrument, los objetos de esta clase no siempre tendrá significado. Esto es, Intrument pretende expresar solo el interface y no una implementación particular, por eso creando un objeto intrument no tiene sentido y probablemente querrá prevenir el uso de hacer esto. Esto puede ser llevado a cabo haciendo todos los métodos en el mensaje de error de Instrument, pero este aplazar la información hasta el tiempo de ejecución y requiere un test confiable y exhaustivo en la parte de usuario. Esto es siempre mejor coger problemas en tiempo de compilación.

Java provee un mecanismo para hacer estos métodos llamados abstractos. Este es un método que esta incompleto; tiene solo la declaración y no tiene cuerpo del método. Aquí esta la sintaxis para la declaración de un método abstracto:

abstract void X();

Una clase que contiene métodos abstractos se llama clase abstracta. Si una clase contiene uno o mas métodos abstractos, la clase debe ser calificada como abstracta. (De otro modo el compìlador dará un mensaje de error.)

Si una clase abstracta esta incompleta, ¿que supondrá el compilador que debe hacer cuando alguien intente hacer un objeto de esa clase? Seguramente no podrá crear un objeto de una clase abstracta, por eso dará un error el compilador. De

este modo el compilador se asegura de la pureza de la clase abstracta y no necesitaras preocuparse por usarla mal.

Se hereda de una clase abstracta y quieres hacer objetos de un tipo nuevo, deberás proporcionar las definiciones de los métodos para todos los métodos abstractos en la clase base. Si no lo hace (puede no hacerlo) entonces las clases derivadas serán también abstractos y el compilador le obligará a identificar la clase como abstracta con la palabra "abstract".

Es posible declarar una clase como abstracto sin incluir ningún método abstracto. Esto es útil cuando se tiene una clase en la que no se hace buen uso para tener ningún método abstracto y todavía quieres prevenir cualquier ejemplo de esa clase.

La clase instrument puede ser cambiado fácilmente a una clase abstracto. Solo algunos de los métodos serán abstractos, desde que haciendo una clase abstracta no se fuerza a hacer todos los métodos abstractos. Aquí esta como aparece:

Aquí esta el ejemplo orquesta modificado para usar clases y métodos abstractos:

//: Music4.java // Abstract classes and methods import java.util.*;

abstract class Instrument4 { int i; // storage allocated for each public abstract void play(); public String what() { return "Instrument4"; } public abstract void adjust(); } class Wind4 extends Instrument4 { public void play() { System.out.println("Wind4.play()"); } public String what() { return "Wind4"; } public void adjust() {} } class Percussion4 extends Instrument4 { public void play() { System.out.println("Percussion4.play()"); } public String what() { return "Percussion4"; } public void adjust() {} } class Stringed4 extends Instrument4 { public void play() { System.out.println("Stringed4.play()"); } public String what() { return "Stringed4"; } public void adjust() {} } class Brass4 extends Wind4 { public void play() { System.out.println("Brass4.play()"); } public void adjust() { System.out.println("Brass4.adjust()"); } } class Woodwind4 extends Wind4 { public void play() { System.out.println("Woodwind4.play()"); } public String what() { return "Woodwind4"; } }

public class Music4 { // Doesn't care about type, so new types // added to the system still work right: static void tune(Instrument4 i) { // ... i.play(); } static void tuneAll(Instrument4[] e) { for(int i = 0; i < e.length; i++) tune(e[i]); } public static void main(String[] args) { Instrument4[] orchestra = new Instrument4[5]; int i = 0; // Upcasting during addition to the array: orchestra[i++] = new Wind4(); orchestra[i++] = new Percussion4(); orchestra[i++] = new Stringed4(); orchestra[i++] = new Brass4(); orchestra[i++] = new Woodwind4(); tuneAll(orchestra); } } ///:~

Puede ver que no hay realmente cambio excepto en la clase base. Esto es útil para crear clases y métodos abstractos por que hacen la abstracción de una clase concreta y dicen tanto al usuario como al compilador como debe ser usado.

Interfaces

La palabra "clave" interface toma un concepto abstracto un paso más lejano. Podría pensarse que es como una clase abstracta "pura". Esto permite al creador establecer la forma para una clase: nombre de los métodos, lista de argumentos y tipos devueltos, pero no los cuerpos de los métodos. Un interface puede también contener datos de tipos primitivos, pero estos son implícitamente estáticos y final. Un interface provee solo una forma, pero no implementación.

Un interface dice: "esto es que todas las clases que implementan este particular interface se parecerán". Por eso ningún código que use un interface particular sabe que métodos deben ser llamados por ese interface, y esto es todo. Por lo que el interface es usado para establecer un "protocolo" entre clases. (Algunos lenguajes de programación orientados o objetos tienen una palabra reservada llamada "protocol" para hacer lo mismo.

Para crear un interface, usar la palabra interface en vez de class. Como una clase, puedes añadir la palabra public antes de interface (pero solo si el interface esta definido en un fichero del mismo nombre) o dejarlo para darle el estado

"amistoso".

Para hacer una clase que conforma un interface particular (o grupo de interfaces) usar la palabra implements. Con esto se esta diciendo: "El interface es lo que parece y aquí esta como funciona". otro como este, lleva un parecido fuerte para heredar. El diagrama para el ejemplo de instrumentos es este:

Una vez implementado un interface, esa implementación comienza una clase ordinaria que puede ser extendida a una forma regular.

Usted puede elegir declarar explícitamente las declaraciones del método en un interface como publico. Pero serán públicos incluso si no se le indica. Por eso cuando se implementa un interface, los métodos del interface deben ser definidos como públicos. De otro modo serán por defecto "amistosos" y podría ser restringido el acceso a un método durante la herencia, que no es permitida por el compilador de Java.

Puedes ver en esta versión modificada del ejemplo de instrumentos. Apuntar que todo método en el interface es estrictamente una declaración, que es lo único que el compilador permite. Además, ninguno de los métodos en Intrument5 son declarados como públicos, pero ellos son públicos automáticamente:

//: Music5.java

// Interfaces import java.util.*; interface Instrument5 { // Compile-time constant: int i = 5; // static & final // Cannot have method definitions: void play(); // Automatically public String what(); void adjust(); } class Wind5 implements Instrument5 { public void play() { System.out.println("Wind5.play()"); } public String what() { return "Wind5"; } public void adjust() {} } class Percussion5 implements Instrument5 { public void play() { System.out.println("Percussion5.play()"); } public String what() { return "Percussion5"; } public void adjust() {} } class Stringed5 implements Instrument5 { public void play() { System.out.println("Stringed5.play()"); } public String what() { return "Stringed5"; } public void adjust() {} } class Brass5 extends Wind5 { public void play() { System.out.println("Brass5.play()"); } public void adjust() { System.out.println("Brass5.adjust()"); } } class Woodwind5 extends Wind5 { public void play() { System.out.println("Woodwind5.play()"); } public String what() { return "Woodwind5"; }

} public class Music5 { // Doesn't care about type, so new types // added to the system still work right: static void tune(Instrument5 i) { // ... i.play(); } static void tuneAll(Instrument5[] e) { for(int i = 0; i < e.length; i++) tune(e[i]); } public static void main(String[] args) { Instrument5[] orchestra = new Instrument5[5]; int i = 0; // Upcasting during addition to the array: orchestra[i++] = new Wind5(); orchestra[i++] = new Percussion5(); orchestra[i++] = new Stringed5(); orchestra[i++] = new Brass5(); orchestra[i++] = new Woodwind5(); tuneAll(orchestra); } } ///:~

El resto del código funciona lo mismo. No importa si esta upcasting a una clase "regular" llamada Intrument5, una clase abstracta llamada Instrument5, o a un interface llamado Intrument5. La acción es la misma. De echo puede ver en el método tune() que no hay ninguna evidencia a cerca tanto si instrument5 es una clase "regular", una clase abstracta o un interface. Esto es el intento: cada entrada da al programador diferentes controles sobre la forma de que son creados y usados los objetos.

Herencia múltiple en Java

El interface no es simplemente una forma pura mas de una clase abstracta. Tiene un propósito mayor que esto. Por que un interface no tiene implementación, entonces, no hay storage asociado con el interface -no hay nada para impedir interfaces siendo combinados. Esto es evaluable por que hay veces cuando se necesita decir: "Una x es una a y a b y a c " En C++ esta acción se hace combinando múltiples interfaces de clases y se llama herencia múltiple, y este conlleva algunos raras consecuencias por que cada clase puede tener una implementación. En Java, puedes permitir el mismo acto, pero solo una de las clases puede tener una implementación, por eso los problemas vistos en C++ no ocurren con Java cuando se combinan múltiples interfaces:

En una clase derivada no estas obligado a tener una clase base que sea o un abstracto o "concreto" (que no tiene métodos abstractos). Si usted hereda desde un no-interface, puedes heredar de uno solo. El resto de los elementos básicos deben ser interfaces. Se colocan todos los nombres de interfaces después de la palabra implements y separados por comas. Puedes tener tantos interfaces como quieras y cada uno trae un tipo independiente que puedes upcast también. El ejemplo siguiente muestra una clase concreta combinada con varios interfaces para producir una clase nueva:

//: Adventure.java // Multiple interfaces import java.util.*; interface CanFight { void fight(); } interface CanSwim { void swim(); } interface CanFly { void fly(); } class ActionCharacter { public void fight() {} } class Hero extends ActionCharacter implements CanFight, CanSwim, CanFly { public void swim() {} public void fly() {} }

public class Adventure { static void t(CanFight x) { x.fight(); } static void u(CanSwim x) { x.swim(); } static void v(CanFly x) { x.fly(); } static void w(ActionCharacter x) { x.fight(); } public static void main(String[] args) { Hero i = new Hero(); t(i); // Treat it as a CanFight u(i); // Treat it as a CanSwim v(i); // Treat it as a CanFly w(i); // Treat it as an ActionCharacter } } ///:~

Se puede ver que Hero combina la clase concreta ActionCharacter con los interfaces CanFight, CanSwin, y CanFly. Cuando se combina una clase concreta con interfaces esta forma, la clase concreta debe ir primero, después los interfaces. (El compilador dará error si no es así.)

Notar que la firma para fight() es el mismo en el interface CanFight y la clase ActionCharacter, y que fight() no es provista con una definición en Hero. La regla para un interface es que tu puedes heredar de él (como se verá pronto), pero entonces tienes otro interface. Si quiere crear un objeto de un nuevo tipo, este debe ser una clase con todas las definiciones provistas. Incluso si Hero no provee explícitamente una definición para fight(), la definición viene con Action Character por eso es automáticamente provista y es posible crear objetos de Hero.

En la clase Adventure, puedes ver que hay cuatro métodos que toman como argumento los diferentes interfaces y la clase concreta. Cuando un objeto Hero es creado, este puede ser pasado a cualquiera de esos métodos, que significa que se esta upcast a cada interface in turn . Por que la forma de los interfaces son diseñados en Java, estos funcionan sin tropiezos y sin ningún particular esfuerzo por parte del programador.

Conserva en mente que the core reason para interfaces se muestra en el ejemplo de abajo: para poder upcast a mas de un tipo base. Como sea, la segunda razón para usar interfaces es el mismo que usando una clase base abstracta: para prevenir al cliente programador de hacer un objeto de esta clase y establecer que solo es un interface. Esto nos trae una pregunta: ¿Usarías un interface o una clase abstracta? Un interface te da los beneficios de una clase abstracta y los beneficios de un interface, por eso es posible crear tu clase base sin definiciones de métodos o variables podrías preferir siempre interfaces que clases abstractas. De echo, si sabes algo será una clase base, tu primera elección podría ser hacer un interface, y solo si te ves forzado a tener definiciones de métodos o variables cambiarías a una clase abstracta.

Extendiendo un interface con herencia

Usted puede añadir fácilmente nuevas declaraciones de métodos a un interface usando la herencia y puedes también combinar varios interfaces en un nuevo interface con la herencia. En ambos casos obtendrás un nuevo interface, como se ve en este ejemplo:

//: HorrorShow.java // Extending an interface with inheritance interface Monster { void menace(); } interface DangerousMonster extends Monster { void destroy(); } interface Lethal { void kill(); } class DragonZilla implements DangerousMonster { public void menace() {} public void destroy() {} } interface Vampire extends DangerousMonster, Lethal { void drinkBlood(); } class HorrorShow { static void u(Monster b) { b.menace(); } static void v(DangerousMonster d) { d.menace(); d.destroy(); } public static void main(String[] args) { DragonZilla if2 = new DragonZilla(); u(if2); v(if2); } } ///:~

Dangerous Monster es una extensión de Monster que produce un nuevo interface.

Esto es implementado en DragonZilla.

La sintaxis usada en Vampire funciona solamente cuando heredas interfaces. Normalmente, puedes usar extendidos con solo una clase simple, pero desde un interface puede ser echo desde otros múltiples interfaces, extendidos pueden referirse a interfaces múltiples base cuando se construye un nuevo interface. Como puedes ver los nombres del interface son simplemente separados con comas.

Agrupando constantes

Por que ningún campo que pongas en un interface será automáticamente estático y final, el interface es una utilidad conveniente para crear grupos de valores constantes, como una enumeración en C o C++, por ejemplo:

//: Months.java // Using interfaces to create groups of constants package c07; public interface Months { int JANUARY = 1, FEBRUARY = 2, MARCH = 3, APRIL = 4, MAY = 5, JUNE = 6, JULY = 7, AUGUST = 8, SEPTEMBER = 9, OCTOBER = 10, NOVEMBER = 11, DECEMBER = 12; } ///:~

Notar que el estilo de Java para usar las letras mayúsculas (con underscores para separar múltiples palabras con un identificador simple) para las primitivas finales estáticas que tienen inicializadores constantes que es constantes en tiempo de compilación.

Los campos en un interface son públicos automáticamente, por eso no es necesario especificarlo.

Ahora puede usar las constantes importándolas del paquete c07.* o c07.Months o de cualquier otro paquete, y referenciando los valores con expresiones como Months.JANUARY. Pr supuesto, que tendrás un entero por eso no hay el tipo extra seguro que C++'s enum tenia, pero esta (usada comúnmente) técnica que es ciertamente un desarrollo del hard-coding numbers en tus programas. (Esto suele ser referido para usar "números mágicos" y estos producen un código muy difícil de mantener) Si quiere un tipo seguro extra, puede construir una clase como esta: (Esta aproximación fue inspirada por un e-mail de Rich Hoffarth.)

//: Month2.java // A more robust enumeration system package c07; public final class Month2 { private String name; private Month2(String nm) { name = nm; } public String toString() { return name; } public final static Month2 JAN = new Month2("January"), FEB = new Month2("February"), MAR = new Month2("March"), APR = new Month2("April"), MAY = new Month2("May"), JUN = new Month2("June"), JUL = new Month2("July"), AUG = new Month2("August"), SEP = new Month2("September"), OCT = new Month2("October"), NOV = new Month2("November"), DEC = new Month2("December"); public final static Month2[] month = { JAN, JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC }; public static void main(String[] args) { Month2 m = Month2.JAN; System.out.println(m); m = Month2.month[12]; System.out.println(m); System.out.println(m == Month2.DEC); System.out.println(m.equals(Month2.DEC)); } } ///:~

La clase se llama Month2 desde que hay un mes en la librería standard de Java. Este es una clase final con un constructor privado por eso ninguno puede heredar de el o hacer ningún ejemplo de él. El único ejemplo es el final estático creado en la clase él mismo: JAN, FEB, MAR, etc. Estos objetos son también usados en el array Month, que le deja elegir meses por el número en vez del por el nombre. (Notar el extra JAN en el array para proveer un offset por uno, por eso que Diciembre es el mes 12) En main() puedes ver el tipo safety: m que es un objeto Month2 por lo que puede ser asignado solo a Month2. El anterior ejemplo Months.java provisto solo valores enteros, que no era demasiado seguro.

Este ejemplo también te permite usar == o "equals()" intercambiables, como se muestra al final de main().

Inicializando campos en interfaces

Los campos definidos en los interfaces son automáticamente estáticos y finales. Estos no pueden ser "blank finals", pero pueden ser inicializados con expresiones no constantes. Por Ejemplo:

//: RandVals.java // Initializing interface fields with // non-constant initializers import java.util.*; public interface RandVals { int rint = (int)(Math.random() * 10); long rlong = (long)(Math.random() * 10); float rfloat = (float)(Math.random() * 10); double rdouble = Math.random() * 10; } ///:~

Desde que los campos son estáticos, son inicializados cuando la clase es cargada por primera vez, incluso el primer acceso a cualquier campo. Un simple test:

//: TestRandVals.java public class TestRandVals { public static void main(String[] args) { System.out.println(RandVals.rint); System.out.println(RandVals.rlong); System.out.println(RandVals.rfloat); System.out.println(RandVals.rdouble); } } ///:~

Los campos, por supuesto, no son parte del interface pero en vez de esto son almacenados en el área de almacenamiento estático para ese interface.

Clases internas

En Java 1.1 es posible poner una definición de clase sin otra definición de clase. Este es llamado una clase internar. La clase interna es un rasgo hasta por que permite agrupar clases que lógicamente pertenecen juntos y controlar la visibilidad de uno sin otro. Como sea, es importante entender que las clases internas son distintas de la composición.

Con frecuencia, mientras se esta aprendiendo a cerca de ellas, la necesidad por las clases internas no es obvia inmediatamente. Al final de esta sección, después de todas las sintaxis y semánticas de las clases internas sean descritas, encontrarás un ejemplo que dará una idea clara de los beneficios de estas clases.

Al crear una clase interna podrías esperar: poniendo la definición de la clase dentro de la clase vecina (Ver página 94 si tiene problemas ejecutando este programa)

//: Parcel1.java // Creating inner classes package c07.parcel1; public class Parcel1 { class Contents { private int i = 11; public int value() { return i; } } class Destination { private String label; Destination(String whereTo) { label = whereTo; } String readLabel() { return label; } } // Using inner classes looks just like // using any other class, within Parcel1: public void ship(String dest) { Contents c = new Contents(); Destination d = new Destination(dest); } public static void main(String[] args) { Parcel1 p = new Parcel1(); p.ship("Tanzania"); } } ///:~

Las clases internas, cuando se usan dentro ship(), parece el uso de muchas clases. Aquí la única diferencia práctica es que los nombre están anidadas sin Parcel1. Verás que esta no es la única diferencia.

Mas típicamente, una clase de salida tendrá un método que devuelve un manejador a una clase interna, como esta:

//: Parcel2.java // Returning a handle to an inner class package c07.parcel2; public class Parcel2 { class Contents { private int i = 11; public int value() { return i; } } class Destination { private String label; Destination(String whereTo) { label = whereTo; } String readLabel() { return label; } } public Destination to(String s) { return new Destination(s); } public Contents cont() { return new Contents(); } public void ship(String dest) { Contents c = cont(); Destination d = to(dest); } public static void main(String[] args) { Parcel2 p = new Parcel2(); p.ship("Tanzania"); Parcel2 q = new Parcel2(); // Defining handles to inner classes: Parcel2.Contents c = q.cont(); Parcel2.Destination d = q.to("Borneo"); } } ///:~

Si quieres hacer un objeto de la clase interna en cualquier sitio excepto de uno con métodos no estáticos de una clase de salida, debes especificar el tipo de este objeto como OuterClassName.InnerClassName, como se ve en main().

Clases internas y upcasting

Pues, las clases internas no parecen tan dramaticas. Despues de todo, si esta escondido Java ya es un perfecto mecanismo de esconder- solo permite a las clases ser "amistosas" (visibles solo con un paquete) mejor que crearlas como una clase interna.

De cualquier forma, las clases internas realmente vienen de ellas mismas, cuando

empiezas a upcasting a una clase base, y en particular a un interface. (El efecto que produce un manejador de interface de un objeto que lo implementa esencialmente lo mismo que upcasting a una clase base.) Esto es por que la clase interna puede entonces estar completamente invisibles y no disponibles para cualquiera, que es conveniente para esconder la implementación. Todo lo que consigues es un manejador de la clase base o del interface, y es posible que incluso no encuentres el tipo exacto, como se enseña a continuación:

//: Parcel3.java // Returning a handle to an inner class package c07.parcel3; abstract class Contents { abstract public int value(); } interface Destination { String readLabel(); } public class Parcel3 { private class PContents extends Contents { private int i = 11; public int value() { return i; } } protected class PDestination implements Destination { private String label; private PDestination(String whereTo) { label = whereTo; } public String readLabel() { return label; } } public Destination dest(String s) { return new PDestination(s); } public Contents cont() { return new PContents(); } } class Test { public static void main(String[] args) { Parcel3 p = new Parcel3(); Contents c = p.cont(); Destination d = p.dest("Tanzania"); // Illegal -- can't access private class: //! Parcel3.PContents c = p.new PContents();

} } ///:~

Ahora Contents y Destinatination representan interfaces disponibles para el programador. (El interface, recuerda, automáticamente hace todos los miembros públicos.) Por conveniencia, estos se ponen en un solo fichero, pero ordinariamente Contents y Destination seria cada uno público en sus propios ficheros.

En Parcel3, algo nuevo ha sido añadido: la clase interna Pcontents es privada por eso ninguno excepto Parcel3 puede acceder a él. Pdestination esta protegido, por eso uno, pero Parcel3, clases en el paquete Parcel3 (desde que se protege dados los accesos a los paquetes; es, protegido es también "amistoso"), y los herederos de Parcel3 pueden acceder a Pdestination. Esto significa, que el programador ha restringido el conocimiento y el acceso de estos miembros. De echo, no puedes downcast a una clase interna (o a una clase interna protegida a menos que seas un heredero.), por que no puedes acceder al nombre, como puedes ver en la clase Test. Así, las clases internas privadas proveen una forma para el diseño de la clase para prevenir completamente ninguna dependencia type-coding y esconder los detalles de la implementación. En adicción, la extensión de un interface es menos útil para la perspectiva del programador desde que este no accede a ningún método adicional que no esta en la parte publica del interface de la clase. Esto también provee una oportunidad para el compilador de Java para generar código mas eficiente.

Las clases normales (no internas) no pueden ser privadas o protegidas - solo públicas o "amistosas".

Notar que contents no necesitan ser una clase abstracta. Podrías usar una clase ordinaria, pero los mas típicas empiezan como un diseño en un interface.

Clases internas en métodos y ámbitos

Lo que hemos visto en encompasses el uso típico de clases internas. En General, el código que escribirías y leer envolviendo las clases internas serán "simples" clases internas que son simples y fácil de entender. Sin embargo, el diseño de las clases internas esta completo y hay un número de otro, mas oscuro, formas que puedes usar si eliges: las clases internas pueden ser creadas con un método o incluso con un scope arbitrario. Hay dos razones para hacer esto:

1. Como se ha visto anteriormente, estas implementando un interface de un tipo por lo que puedes crear y devolver un manejador.

2. Estas resolviendo un complicado problema y quieres crear una clase para ayudar en tu solución, pero no quieres hacerlo disponible.

En los siguientes ejemplos, el código previo será modificado para usar:

1. Una clase definida con un método. 2. Una clase definida con un scope dentro de un método. 3. Una clase anónima implementando un interface. 4. Una clase anónima extendiendo una clase que tiene un constructor no por defecto. 5. Una clase anónima que permita la inicialización de campos. 6. Una clase anónima que permita construcción usando inicialización de ejemplos. (una

clase interna anónima no puede tener constructores).

Esto te dará con el paquete innerscopes. Primero, los interfaces comunes del código previo que será definido en sus ficheros propios, por eso pueden ser usados en todos los ejemplos:

//: Destination.java package c07.innerscopes; interface Destination { String readLabel(); } ///:~

El punto que ha sido construido que Contents podría ser una clase abstracta, por eso aquí esta en una forma mas natural, como un interface:

//: Contents.java package c07.innerscopes; interface Contents { int value(); } ///:~

Aunque es una clase ordinaria con una implementación, Envoltura es algo que se viene usando como un interface común para que estas clases derivadas:

//: Wrapping.java package c07.innerscopes; public class Wrapping { private int i;

public Wrapping(int x) { i = x; } public int value() { return i; } } ///:~

Notaras abajo que Wrapping tiene un constructor que requiere un argumento para hacer cosas un poco mas interesante.

El primer ejemplo enseña la creación de una clase entera con un método scope(en vez de el scope de otra clase).

//: Parcel4.java // Nesting a class within a method package c07.innerscopes; public class Parcel4 { public Destination dest(String s) { class PDestination implements Destination { private String label; private PDestination(String whereTo) { label = whereTo; } public String readLabel() { return label; } } return new PDestination(s); } public static void main(String[] args) { Parcel4 p = new Parcel4(); Destination d = p.dest("Tanzania"); } } ///:~

La clase Pdestination es parte de dest() raro que sea parte de Parcel4. (Notar también que podrías usar el identificador de clase Pdestination para una clase interna dentro de cada clase en el mismo subdirectorio sin un nombre de clase). Entonces, Pdestination no puede ser accedido fuera de dest(). Notar que el upcasting que sucede, en la orden return -nada sale de dest() excepto un manejador de la clase base de destino. Por Supuesto, el echo de que el nombre de la clase Pdestination esta dentro de dest(), no significa que Pdestination no sea un objeto valido una vez que dest() acabe.

El siguiente ejemplo enseña como puede anidar una clase interna con un scopealeatorio:

//: Parcel5.java // Nesting a class within a scope package c07.innerscopes; public class Parcel5 { private void internalTracking(boolean b) { if(b) { class TrackingSlip { private String id; TrackingSlip(String s) { id = s; } String getSlip() { return id; } } TrackingSlip ts = new TrackingSlip("slip"); String s = ts.getSlip(); } // Can't use it here! Out of scope: //! TrackingSlip ts = new TrackingSlip("x"); } public void track() { internalTracking(true); } public static void main(String[] args) { Parcel5 p = new Parcel5(); p.track(); } } ///:~

La clase TrackingSlip esta anidada dentro de scope de una orden if. Esto no significa que la clase sea condicionalmente creada es compilado con todo. En cualquier caso, no esta disponible fuera de scope en el que esta definido. Otro, parece una clase ordinaria.

El siguiente ejemplo parece un poco extraño:

//: Parcel6.java // A method that returns an anonymous inner class package c07.innerscopes; public class Parcel6 { public Contents cont() { return new Contents() { private int i = 11; public int value() { return i; } }; // Semicolon required in this case } public static void main(String[] args) { Parcel6 p = new Parcel6(); Contents c = p.cont();

} } ///:~

El método cont() combina la creación de un valor devuelto con la definición de la clase que representa ese valor devuelto! . Además la clase es anónima, no tiene nombre. Para asegurarnos un pequeño mal, parece que estas creando un objeto Contents:

return new Contents()

Pero entonces, antes de conseguir el semicolon , dirás, "pero, espera, yo pienso yo huiré en una definición de clase:

return new Contents() { private int i = 11; public int value() { return i; } };

Que significa esta extraña sintaxis "crear un objeto de una clase anónima que es heredada de Contents." El manejador devuelto por la nueva expresión es upcastautomáticamente a un manejador Contents. La sintaxis de la clase anónima interna es una abreviatura para:

class MyContents extends Contents { private int i = 11; public int value() { return i; } }return new MyContents();

En la clase anónima interna, contents es creado usando un constructor por defecto. El código siguiente enseña que hacer si tu clase base necesita un constructor con un argumento:

//: Parcel7.java // An anonymous inner class that calls the // base-class constructor package c07.innerscopes; public class Parcel7 {

public Wrapping wrap(int x) { // Base constructor call: return new Wrapping(x) { public int value() { return super.value() * 47; } }; // Semicolon required } public static void main(String[] args) { Parcel7 p = new Parcel7(); Wrapping w = p.wrap(10); } } ///:~

Esto es simplemente pasando el argumento apropiado al constructor de la clase base, mirando aquí como se pasa x en el nuevo Wrapping(x). Una clase anónima no puede tener un constructor donde normalmente llamaríamos a super().

Tanto en los ejemplos anteriores, los semicolon no marcan el final de la clase doby (como se hace en C++). En vez de esto, marca el final de la expresión que resulta de contiene la clase anónima. Así, es idéntico al uso de semicolon en cualquier otro sitio.

¿Qué sucede si necesitas realizar algún tipo de inicialización para un objeto de una clase anónima interna? Desde que es anónima, no hay nombre que darle al constructor, por eso no puedes tener un constructor. Podrías, como sea, realizar la inicialización en el punto de definición de los campos:

//: Parcel8.java // An anonymous inner class that performs // initialization. A briefer version // of Parcel5.java. package c07.innerscopes; public class Parcel8 { // Argument must be final to use inside // anonymous inner class: public Destination dest(final String dest) { return new Destination() { private String label = dest; public String readLabel() { return label; } }; } public static void main(String[] args) { Parcel8 p = new Parcel8(); Destination d = p.dest("Tanzania"); }

} ///:~

Si estas definiendo una clase anónima interna y quieres usar un objeto que esta definido fuera de la clase anónima interna, el compilador requiere que el objeto de salida sea final. Esto es por que el objeto de salida sea final. Esto es por que el argumento para dest() es final. Si lo olvida, obtendrá un mensaje de error en tiempo de compilación.

Como estas asignando un campo, el ejemplo de abajo es excelente. Pero, ¿qué sucede si necesitas realizar algún constructor como actividad? Con Java 1.1 la inicialización de ejemplos, puedes en efecto, crear un constructor para una clase anónima interna.

//: Parcel9.java // Using "instance initialization" to perform // construction on an anonymous inner class package c07.innerscopes; public class Parcel9 { public Destination dest(final String dest, final float price) { return new Destination() { private int cost; // Instance initialization for each object: { cost = Math.round(price); if(cost > 100) System.out.println("Over budget!"); } private String label = dest; public String readLabel() { return label; } }; } public static void main(String[] args) { Parcel9 p = new Parcel9(); Destination d = p.dest("Tanzania", 101.395F); } } ///:~

Dentro del inicializador de ejemplos puedes ver el código que no podrás ejecutar como parte de un inicializador de un campo (esto es, la orden if). Por eso en efecto, un inicializador de ejemplos es el constructor para una clase anónima interna. Por supuesto, esta limitada, no puedes overload inicializadores de ejemplos por eso solo puedes tener uno de los constructores.

El enlace a la clase exterior

Más adelante, aparece que las clases internas son justo un nombre escondido y un esquema de organización del codigo, que es útil, pero no totalmente completo. Aunque, hay otro problema. Cuando se crea una clase interna, los objetos de esa clase interna tienen un enlace al objeto "padre" que los creó, y por eso ellos pueden acceder a los miembros del objeto "padre" sin ninguna calificación especial. Además, las clases internas tienen derechos de acceso a todos los elementos en la clase "padre".¹ El siguiente ejemplo demuestra esto:

¹Esto es muy diferente del diseño de clases anidadas en C++, que es simplemente un mecanismo de esconder el nombre. No hay enlace a un objeto "padre" y sin permisos implicitos en C++.

//: Sequence.java // Holds a sequence of Objects interface Selector { boolean end(); Object current(); void next(); } public class Sequence { private Object[] o; private int next = 0; public Sequence(int size) { o = new Object[size]; } public void add(Object x) { if(next < o.length) { o[next] = x; next++; } } private class SSelector implements Selector { int i = 0; public boolean end() { return i == o.length; } public Object current() { return o[i]; } public void next() { if(i < o.length) i++; } } public Selector getSelector() { return new SSelector(); } public static void main(String[] args) { Sequence s = new Sequence(10); for(int i = 0; i < 10; i++) s.add(Integer.toString(i)); Selector sl = s.getSelector(); while(!sl.end()) { System.out.println((String)sl.current()); sl.next(); } } } ///:~

La secuencia es simplemente un array de tamaño fijo de objetos con una clase envuelta en ella. Llama a add() para añadir un nuevo objeto al final de la secuencia (Lista) (si hay sitio). Para buscar cada objeto en una lista, hay un interface llamado Selector, que permite ver si estas en el final end(), mirar el objeto actual current(), y pasar al siguiente next(). Ya que el Selector es un interface, muchas otras clases pueden implementar el interface de su propia forma, y muchos métodos pueden tomar un interface como argumento para crear un código genérico.

Aquí, el Sselector es una clase privada que provee la función de Selector. En main() puedes ver la creación de una lista, seguida por añadir un numero de objetos string. Entonces, un selector se produce con una llamada a get Selector() y esta es usada para moverse a través de la lista y seleccionar cada elemento.

Primero, la creación de Sselector parece otra clase interna. Pero examínelo cuidadosamente. Note que cada uno de los métodos end() y next() se refieren a "o", que es un manejador que no es parte de Sselector, pero si es un campo privado en la clase "padre". Sin embargo, la clase interna puede acceder a métodos y a campos desde una clase "padre" como si fuera suya. Esto quita que sea muy conveniente, como puedes ver abajo en el ejemplo.

Por eso una clase, interna tuvo acceso a los miembros de las clases "padres". ¿Cómo puede suceder esto? La clase interna debe conservar una referencia a un objeto particular de la clase "padre" que fue responsable para crearlo. Entonces cuando te refieres a un miembro de la clase "padre", que (escondido) referencia es usada para seleccionar ese miembro. Afortunadamente el compilador tiene cuidado con todos estos detalles por ti, pero puedes también entender ahora que un objeto en una clase interna puede ser creado solo asociado con un objeto de una clase interna. El proceso de construcción requiere la inicialización del manejador del objeto de la clase "padre" y el compilador reclamará si no puede acceder al manejador. Muchas veces esto ocurre sin intervención por parte del programador.

Clases internas estáticas

Para comprender el significado de "estático" aplicando a las clases internas, debes recordar que el objeto de las clases internas conserva implícitamente un manejador del objeto de la clase "padre" que lo creó. Esto no es verdad, aunque, cuando se dice una clase interna es estática. Una clase interna estática significa:

1. No necesitas un objeto de una clase de salida para crear un objeto de una clase interna estática.

2. No puedes acceder a un objeto de una clase de salida desde un objeto de una clase de salida desde un objeto de una clase interna estática.

Hay algunas restricciones: los miembros estáticos, pueden estar en un nivel de

una clase por eso las clases internas no pueden tener datos estáticos o clases internas estáticas.

Si no necesita crear un objeto de una clase de salida para crear un objeto de la clase interna, puedes hacerlo todos estático. Para esto para trabajar, debes también hacer las clases internas estáticas:

//: Parcel10.java // Static inner classes package c07.parcel10; abstract class Contents { abstract public int value(); } interface Destination { String readLabel(); } public class Parcel10 { private static class PContents extends Contents { private int i = 11; public int value() { return i; } } protected static class PDestination implements Destination { private String label; private PDestination(String whereTo) { label = whereTo; } public String readLabel() { return label; } } public static Destination dest(String s) { return new PDestination(s); } public static Contents cont() { return new PContents(); } public static void main(String[] args) { Contents c = cont(); Destination d = dest("Tanzania"); } } ///:~

En main no es necesario objetos de Parcel10; en vez de eso use la sintaxis normal para seleccionar un miembro estático para llamar a los métodos que devuelve

manejadores a Contents y Destination.

Normalmente no puedes poner ningún código dentro de un interface, pero una clase interna estática puede ser parte de un interface. Desde que las clases son estáticas no violan las reglas para los interfaces - las clases internas estáticas es puesta solo en el espacio del nombre del interface:

//: IInterface.java // Static inner classes inside interfaces class IInterface { static class Inner { int i, j, k; public Inner() {} void f() {} } } ///:~

Anteriormente en el libro I sugería poner un main() en todas las clases to act as a test bed para esa clase. Un inconveniente de este es la cantidad de código extra debes arrastrar. Si este es un problema, puedes usar una clase interna estática para contener el código de test:

//: TestBed.java // Putting test code in a static inner class class TestBed { TestBed() {} void f() { System.out.println("f()"); } public static class Tester { public static void main(String[] args) { TestBed t = new TestBed(); t.f(); } } } ///:~

Esto genera una clase aparte llamada TestBed$Tester (para ejecutar el programa poner java TestBed$Tester) Puedes usar esta clase para testear, pero no necesitas incluir en tu shipping product .

Refiriéndose al objeto de la clase más exterior

Si necesita producir el manejador de salida de la clase objeto, ponga: nombre a la

clase de salida seguido por un punto. Por ejemplo, en la clase Sequence.Sselector ninguno de sus métodos puede producir el manejador almacenado a la clase de salida Sequence escribiendo Sequence.this. El manejador resultante es automáticamente el tipo correcto. (Esto se conoce y es chequeado en tiempo de compilación, por eso no hay run-time overhead ). A veces quieres decir a algún otro objeto que cree un objeto de uno de estas clases internas. Para hacer esto debes proveer un manejador a la otra clase de salida en la nueva expresión, como esta:

//: Parcel11.java // Creating inner classes package c07.parcel11; public class Parcel11 { class Contents { private int i = 11; public int value() { return i; } } class Destination { private String label; Destination(String whereTo) { label = whereTo; } String readLabel() { return label; } } public static void main(String[] args) { Parcel11 p = new Parcel11(); // Must use instance of outer class // to create an instances of the inner class: Parcel11.Contents c = p.new Contents(); Parcel11.Destination d = p.new Destination("Tanzania"); } } ///:~

Para crear un objeto de la clase interna directamente, no sigue la misma forma y referidos al nombre de la clase d salida Parcel11 como puedes esperar, pero en vez de esto debes usar un objeto de la clase de salida para hacer un objeto de la clase interna:

Parcel11.Contents c = p.new Contents();

Así, no es posible crear un objeto de una clase interna a menos que ya tenga un objeto de la clase de salida. Esto es por que el objeto de la clase de salida es

conectado al objeto de la clase de salida de la que fue creado. Como sea, si creas una clase interna estática entonces no necesitas un manejador de la clase del objeto de salida.

Heredando de una clase interna

Por que el constructor de la clase interna debe "engancharse" al manejador del objeto de la clase "padre", las cosas se complican cuando heredas de una clase interna. El problema es que el manejador "secreto" del objeto de la clase "padre" debe ser inicializado, y todavía en la clase derivada no hay mas que un objeto por defecto a quien engancharse. La respuesta es usar la sintaxis provista para hacer la asociación explícita:

//: InheritInner.java // Inheriting an inner class class WithInner { class Inner {} } public class InheritInner extends WithInner.Inner { //! InheritInner() {} // Won't compile InheritInner(WithInner wi) { wi.super(); } public static void main(String[] args) { WithInner wi = new WithInner(); InheritInner ii = new InheritInner(wi); } } ///:~

Puedes ver que InheritInner es extendido solo en las clases interna, y no las de salida. Pero cuando va a crear un constructor, el de defecto no es bueno no puedes pasarle un manejador a un objeto "padre". Además, debes usar la sintaxis:

enclosingClassHandle.super();

dentro del constructor. Este provee el manejador necesario y el programa compilará entonces.

¿Pueden las clases internas ser sobreescritas?

¿Qué sucede cuando creas una clase interna, entonces heredas de una clase

"padre" y redefinir las clases interna? Es posible sobreescribir una clase interna? Esto parece que seria un concepto poderoso, pero sobreescribir una clase interna como si fuera otro método de una clase de salida no hace realmente nada:

//: BigEgg.java // An inner class cannot be overriden // like a method class Egg { protected class Yolk { public Yolk() { System.out.println("Egg.Yolk()"); } } private Yolk y; public Egg() { System.out.println("New Egg()"); y = new Yolk(); } } public class BigEgg extends Egg { public class Yolk { public Yolk() { System.out.println("BigEgg.Yolk()"); } } public static void main(String[] args) { new BigEgg(); } } ///:~

El constructor por defecto es sintetizado automáticamente por el compilador, y este llama al constructor por defecto de la clase base. Puede pensar que desde un BigEgg a sido creado, la versión sobreecrita de Yolk será usada, pero este no es el caso. La salida es:

New Egg() Egg.Yolk()

Este ejemplo simplemente enseña que no hay ninguna clase mágica interna extra va cuando heredas de una clase mas exterior. Como sea, es posible todavía heredar explícitamente de la clase interna:

//: BigEgg2.java // Proper inheritance of an inner class class Egg2 { protected class Yolk { public Yolk() { System.out.println("Egg2.Yolk()"); } public void f() { System.out.println("Egg2.Yolk.f()"); } } private Yolk y = new Yolk(); public Egg2() { System.out.println("New Egg2()"); } public void insertYolk(Yolk yy) { y = yy; } public void g() { y.f(); } } public class BigEgg2 extends Egg2 { public class Yolk extends Egg2.Yolk { public Yolk() { System.out.println("BigEgg2.Yolk()"); } public void f() { System.out.println("BigEgg2.Yolk.f()"); } } public BigEgg2() { insertYolk(new Yolk()); } public static void main(String[] args) { Egg2 e2 = new BigEgg2(); e2.g(); } } ///:~

Ahora BiggEgg2.Yok extiende explícitamente Egg2.Yolk y sobreescribe estos métodos. El método insertYolk() permite a BigEgg2 para upcast uno de sus propios objetos Yok dentro del manejador "y" en Egg2, por eso cuando g() llama a y.f() la versión sobreescrita de f() es usada. La salida es:

Egg2.Yolk() New Egg2() Egg2.Yolk() BigEgg2.Yolk() BigEgg2.Yolk.f()

La segunda llamada a Egg2.Yok() es la llamada al constructor de la clase base llamada del constructor BigEgg2.Yolk. Puedes ver que la versión overridden de f() es usada cuando g() es llamada.

Identificadores de clases interna

Desde que todas las clases producen un fichero .class que contiene toda la información a cerca de cómo crear objetos de ese tipo (esta información produce meta-clases llamadas Clases objeto), puedes esperar que las clases interna debe también producir archivos .class para contener la información para su clases objeto. Los nombres de esos ficheros (clases tienen una formula estricta: el nombre de la clase "padre", seguida por un $, mas el nombre de la clase interna. Por ejemplo, los ficheros .class creados por InheritInner.java incluye:

InheritInner.class WithInner$Inner.class WithInner.class

Si las clases interna son anónimas el compilador simplemente empieza a generar números como identificadores de clases interna. Si la clase interna es anidada con clases interna, sus nombres serán simplemente añadidos después de un $ y el identificador/es de la clase de salida.

Aunque este esquema de generar nombres internos es simple y derecho, es también robusto y manejable en muchas situaciones. 3 Desde que este es el esquema de la forma de nombrar estándar en Java, los ficheros generados son automáticamente independientes de la plataforma. (Notar que el compilador de Java cambia tus clases interna en todos los tipos para hacerlos funcionar.)

¿Por qué las clases internas?. Esqueleto de control

En este punto has visto muchas sintaxis y descripciones semánticas la manera en que las clases interna funcionan, pero esto no contestan a la pregunta de por que existen. ¿Por qué trae tantos problemas para añadirlo como un rasgo fundamental del lenguaje en Java 1.1? La respuesta es algo que referiré como un esqueleto de control (framework)

Una aplicación framework es una clase o un conjunto de clases que son diseñadas para resolver un tipo particular de problema. Para aplicar una aplicación framework, tu heredas de una o mas clases y override algunos de los configuras la solución general provista por esta aplicación framework para resolver tu problema especifico. El control framework es un tipo particular de aplicación predominada

por framework por la necesidad.

3 En la otra mano, $ es un meta-carácter en el shell Unix y por eso tendrás a veces problemas cuando listes los ficheros .class. Esto es un poco extraño viniendo de Sun, una compañía basada en Unix. Supongo que ellos no consideraron este principio, pero en vez de pensar que naturalmente se centrará en los ficheros de código fuente.

Para responder a eventos un sistema que preliminarmente responde a eventos se llama un sistema conducido por eventos. Uno de los mas importantes problemas en la programación de aplicaciones es el interface gráfico del usuario (GUI), que es el que es mas dirigido por eventos. Como verás en el capitulo 13, Java 1.1 AWT es un control framework que elegantemente resuelve el problema del GUI usando clases internas.

Para ver como las clases interna permiten la creación simple y el uso de control framework, considerar un control framework aquel cuyo trabajo es ejecutar eventos siempre que esos eventos esten "listos".> Aunque "listos" puede significar nada, en este caso el defecto será basado en el reloj. Que siguido de un control framework que no contiene información especifica acerca de que esta controlando. Primero, aquí esta el interface que describe ningún evento de control. Este es una clase abstracta en vez de un interface, ya que el comportamiento por defecto es un control basado on time , por eso algunas de las implementaciones pueden ser incluidas aquí:

//: Event.java // The common methods for any control event package c07.controller; abstract public class Event { private long evtTime; public Event(long eventTime) { evtTime = eventTime; } public boolean ready() { return System.currentTimeMillis() >= evtTime; } abstract public void action(); abstract public String description(); } ///:~

El constructor simplemente captura el tiempo cuando quieras que el Evento se ejecute, mientras ready() te dice cuando es tiempo de ejecutarlo. Por supuesto, ready() puede ser overridden en una clase derivada basando el evento en algo mas que el tiempo. Action() es el método que es llamado cuando el evento esta

ready(), y description() da información textual a cerca del evento.

El siguiente fichero contiene el actual control framework que maneja y fija eventos. La primera clase es realmente un "ayudador" de clases cuyo trabajo es contener objetos eventos. Podrías reemplazarlo con cualquier apropiada colección, y en el capitulo 8 descubrirás otras colecciones que hará el engaño sin requerir que escribas código extra:

//: Controller.java // Along with Event, the generic // framework for all control systems: package c07.controller; // This is just a way to hold Event objects. class EventSet { private Event[] events = new Event[100]; private int index = 0; private int next = 0; public void add(Event e) { if(index >= events.length) return; // (In real life, throw exception) events[index++] = e; } public Event getNext() { boolean looped = false; int start = next; do { next = (next + 1) % events.length; // See if it has looped to the beginning: if(start == next) looped = true; // If it loops past start, the list // is empty: if((next == (start + 1) % events.length) && looped) return null; } while(events[next] == null); return events[next]; } public void removeCurrent() { events[next] = null; } } public class Controller { private EventSet es = new EventSet(); public void addEvent(Event c) { es.add(c); } public void run() { Event e; while((e = es.getNext()) != null) {

if(e.ready()) { e.action(); System.out.println(e.description()); es.removeCurrent(); } } } } ///:~

EventSet contiene 100 eventos arbitrariamente. (Si una colección "real" del capitulo 8 es usado aquí no necesitas preocuparte a cerca de que es del tamaño máximo, desde que se redimensione él solo). El índice usado para conservar el sitio del siguiente espacio disponible, y el siguiente es usado cuando estas buscando el siguiente Evento en la lista, para ver tanto si has whether you-ve looped around . Esto es importante durante una llamada a getNext(), por que los objetos Evento son eliminados de la lista (usando remove Current()) una vez que se esta ejecutando, por eso getNext() encontrará huecos en la lista que se mueven por ella.

Notar que removeCurrent() no establece solamente algunas "banderas" indicando que el objeto no estará en uso durante bastante tiempo. En vez de esto, se le manda al manejador que lo anule. Esto es importante ya que si la basura del collector sees un manejador que es todavía en uso entonces no puede clean up el objeto. Si piensas que tus manejadores pueden "engancharlo", una buena idea para ponerlos para dar permiso al colector de basura to clean them up .

El controlador está donde el actual trabajo está. Este usa un Set de Eventos para contener estos objetos Event, y addEvent() te permite añadir nuevos eventos a esta lista. Pero el método importante es run(). Este método dobla a través de EventSethunting para un objeto Evento que está listo ready() para ejecutarse. Para cada uno que esté listo ready(), se llama al método action(), escribe la descripción description() y entonces elimina el evento de la lista.

Notar que en este diseño no sabemos nada exactamente sobre que hace un evento. Y este es el inconveniente del diseño, como "separar las cosas que cambian de las que continúan igual". O, para usar mi termino, el "vector de cambio" son las diferentes acciones de los varios tipos de objetos. Evento, y expresar diferentes acciones creando diferentes subclases de Eventos.

Aquí es donde las clases internas entran en juego. Ellos permiten dos cosas:

1. Expresar la implementación de una aplicación control-framework en una clase simple, por el encapsulamiento todo lo que es único de esa implementación. Las clases internas son usadas para expresar los diferentes tipos de action() necesarios para resolver el problema. Además, el siguiente ejemplo usa clases internas privadas por lo que la implementación es completamente escondida y puede ser cambiada con impunidad.

2. Las clases internas conservan esta implementación from becoming awkard , desde que

puedes fácilmente acceder a cualquiera de los miembros de la clase "padre". Sin que esto habilite que el código pueda become unpleasant enough that you´d end up buscando una alternativa.

Considerar una implementación particular del control-framework diseñada para controlar las funciones "greenhouse".² Cada acción es completamente diferente: cambiar luces, agua, y encender o apagar termostatos, llamar al timbre, y "restart" el sistema. Pero el control-framework es diseñado para aislar fácilmente este diferente código. Para cada tipo de acción heredas un nuevo evento de la clase interna, y escribe el código de control dentro de action().

Como estipoco con una aplicación framework, la clase GreenhouseControls es heredada de un Controlador:

²Por alguna razón esto ha tenido siempre un agradable problema para resolverlo; esto viene de C++ Inside&Out, pero java permite una forma mucho mas elegante.

//: GreenhouseControls.java // This produces a specific application of the // control system, all in a single class. Inner // classes allow you to encapsulate different // functionality for each type of event. package c07.controller; public class GreenhouseControls extends Controller { private boolean light = false; private boolean water = false; private String thermostat = "Day"; private class LightOn extends Event { public LightOn(long eventTime) { super(eventTime); } public void action() { // Put hardware control code here to // physically turn on the light. light = true; } public String description() { return "Light is on"; } } private class LightOff extends Event { public LightOff(long eventTime) { super(eventTime); } public void action() { // Put hardware control code here to // physically turn off the light. light = false; } public String description() { return "Light is off"; } } private class WaterOn extends Event { public WaterOn(long eventTime) { super(eventTime); } public void action() { // Put hardware control code here water = true; } public String description() { return "Greenhouse water is on"; }

} private class WaterOff extends Event { public WaterOff(long eventTime) { super(eventTime); } public void action() { // Put hardware control code here water = false; } public String description() { return "Greenhouse water is off"; } } private class ThermostatNight extends Event { public ThermostatNight(long eventTime) { super(eventTime); } public void action() { // Put hardware control code here thermostat = "Night"; } public String description() { return "Thermostat on night setting"; } } private class ThermostatDay extends Event { public ThermostatDay(long eventTime) { super(eventTime); } public void action() { // Put hardware control code here thermostat = "Day"; } public String description() { return "Thermostat on day setting"; } } // An example of an action() that inserts a // new one of itself into the event list: private int rings; private class Bell extends Event { public Bell(long eventTime) { super(eventTime); } public void action() { // Ring bell every 2 seconds, rings times: System.out.println("Bing!"); if(--rings > 0) addEvent(new Bell( System.currentTimeMillis() + 2000));

} public String description() { return "Ring bell"; } } private class Restart extends Event { public Restart(long eventTime) { super(eventTime); } public void action() { long tm = System.currentTimeMillis(); // Instead of hard-wiring, you could parse // configuration information from a text // file here: rings = 5; addEvent(new ThermostatNight(tm)); addEvent(new LightOn(tm + 1000)); addEvent(new LightOff(tm + 2000)); addEvent(new WaterOn(tm + 3000)); addEvent(new WaterOff(tm + 8000)); addEvent(new Bell(tm + 9000)); addEvent(new ThermostatDay(tm + 10000)); // Can even add a Restart object! addEvent(new Restart(tm + 20000)); } public String description() { return "Restarting system"; } } public static void main(String[] args) { GreenhouseControls gc = new GreenhouseControls(); long tm = System.currentTimeMillis(); gc.addEvent(gc.new Restart(tm)); gc.run(); } } ///:~

Notar que luz, agua, termostato, y timbres pertenecen todas a la clase de salida GreenhouseControls, y todavía las clases interna no tienen problemas para acceder a esos campos. También, muchas de los métodos action() también envuelven algún tipo de control hardware, que envolverán llamadas a código no-Java.

La mayoría de las clases eventos parecen similares, pero Bell y Restart son especiales. Bell suena, y si esto no se hubiera ejecutado todavía suficientes veces esto añadiría un nuevo objeto Bell a la lista de Eventos, por eso sonará de nuevo mas tarde. Notar como interna clases parece herencia múltiple: Bell tiene todos

los métodos de Event y esto también aparece para tener todos los métodos de la clase de salida GreenhouseControls.

Restart es el responsable de inicializar el sistema, por eso añade los eventos apropiados. Por supuesto, una forma mas flexible de ejemplo esto es avoid hard-coding los eventos en vez de leerlos del fichero. (Un ejercicio en el capítulo 10 te pedirá modificar este ejemplo para hacer justamente esto). Desde que Restart() es otro objeto evento puedes tambien añadir un objeto Restart con Restart.action() por eso el sistema regularmente restarts el mismo. Y todo lo que necesitas hacer en main() es crear un objeto GreenhouseControls y añadir un objeto Restart para que funcione.

Este ejemplo te llevará a apreciar el valor de las clases interna, especialmente cuando se usan con un control framework. Aunque, en la segunda parte del capitulo 13 veremos como son usados las clases internas elegantemente para describir las acciones de un interface gráfico de un usuario. Al tiempo que terminas esta sección debería ser completamente convincente.

Constructores y polimorfismo

Como es usual, los contructores son diferentes de los otros tipos de métodos. Esto es también verdad cuando el polimorfismo es envuelto. Incluso cuando los constructores no son polimorficos (aunque puedes tener un tipo de "contructor virtual", como veremos en el capitulo 11), es importante comprender la forma de que trabajan los constructores en jerarquías complejas y con polimorfismo. Esto te ayudará a avoid unpleasant entanglements .

Orden de las llamadas a constructores

El orden de las llamadas a constructores fue discutida en el capitulo 4, pero esto fue antes de que la herencia y el polimorfismo fuera introducido.

Un constructor para la clase base es siempre llamado en el constructor para una clase derivada, chaining upward so that un constructor para todas las clases base es llamado. Este se asegura que el constructor tiene un trabajo especial: ver que el objeto sea construido correctamente. Una clase derivada tiene acceso solo a estos propios miembros, y no a los de las clases base (esos miembros son típicamente primados). Solo el constructor de la clase-base tiene el conocimiento adecuado y acceso a inicializar sus propios elementos.

Entonces, es esencial que todos los constructores sean llamados, de otro modo el objeto no será construido correctamente. Esto es por que el compilador forza una llamada a un constructor para cada porción de una clase derivada. Esto llamará "silenciosamente" al constructor por defecto si no especificas un constructor de clase-base en el cuerpo del constructor de la clase-derivada. Si no hay constructor por defecto, el compilador protestará. (En el caso de que una clase no tuviera constructores, el compilador automáticamente sintetizará un constructor por

defecto.)

Echemos un vistazo a un ejemplo que enseña los efectos de composición, herencia, y polimorfismo para la construcción:

//: Sandwich.java // Order of constructor calls class Meal { Meal() { System.out.println("Meal()"); } } class Bread { Bread() { System.out.println("Bread()"); } } class Cheese { Cheese() { System.out.println("Cheese()"); } } class Lettuce { Lettuce() { System.out.println("Lettuce()"); } } class Lunch extends Meal { Lunch() { System.out.println("Lunch()");} } class PortableLunch extends Lunch { PortableLunch() { System.out.println("PortableLunch()"); } } class Sandwich extends PortableLunch { Bread b = new Bread(); Cheese c = new Cheese(); Lettuce l = new Lettuce(); Sandwich() { System.out.println("Sandwich()"); } public static void main(String[] args) { new Sandwich(); } } ///:~

Este ejemplo crea una clase compleja de salida de otras clases, y cada clase tiene

un constructor que se anuncia a si mismo. La clase importante es Sandwich, que refleja 3 niveles de herencia (4, si contamos la herencia implícita del objeto) y 3 objetos miembros. Cuando un objeto Sandwich es creado en main(), la salida es:

Meal() Lunch() PortableLunch() Bread() Cheese() Lettuce() Sandwich()

Esto significa que el orden de llamada al constructor para un objeto complejo como sigue:

1. El constructor de la clase-base se llama. Este paso se repite recursivamente hasta que el raiz de la jerarquía se construye primero, seguido por la siguiente clase-derivada, etc. Hasta que la clase mas derivada sea alcanzada.

2. Los inicializadores son llamados en el orden de declaración. 3. El cuerpo del constructor de la clase-derivada es llamada.

El orden de las llamadas al constructor es importante. Cuando heredas, sabes todo a cerca de la clase base y puede acceder a cualquier miembros públicos y protegidos de la clase base. Esto significa que debes be able to assume que todos los miembros de una clase base son validos cuando estas en una clase derivada. En un método normal, la construcción ya ha tenido lugar, por eso todos los miembros de todas partes del objeto que ha sido construido. Dentro del constructor, Aunque, debes asumir que todos los miembros que usa han sido construidos. La única forma de garantizar esto es para los constructores de clase-base para ser llamados primeros. Entonces cuando los miembros puedes acceder en la clase base han sido inicializados. "Sabiendo que todos los miembros son validos" dentro del constructor es también razón de que, siempre que sea posible, debes inicializar todos los objetos miembro (que es, objetos puestos en la clase usando la composición) a su punto de definición en la clase. (e.g.: b, c, y l en el ejemplo de abajo). Si sigues esta practica, ayudarás ensure que todos los miembros de la clase base y los miembros objetos del objeto actual ha sido inicializado. Desafortunadamente, esto no se maneja en muchos casos, como verás en la siguiente sección.

Herencia y finalize( )

Cuando usas la composición para crear una clase nueva, no te preocupes nunca por finalizar los objetos miembro de esa clase. Cada miembro es un objeto

independiente y así es basura collected and finalized regardless of whether sucede a un miembro de tu clase. Con la herencia, aunque debes override finalize() in the clase derivada si no tienes ningún clanup especial que deba suceder como parte de la colección de basura. Cuando override finalize() en una clase heredada, es importante recordar llamar la versión clase-base de finalize(), de otro modo la finalización de la clase-base no ocurrirá. El siguiente ejemplo provee esto:

//: Frog.java // Testing finalize with inheritance class DoBaseFinalization { public static boolean flag = false; } class Characteristic { String s; Characteristic(String c) { s = c; System.out.println( "Creating Characteristic " + s); } protected void finalize() { System.out.println( "finalizing Characteristic " + s); } } class LivingCreature { Characteristic p = new Characteristic("is alive"); LivingCreature() { System.out.println("LivingCreature()"); } protected void finalize() { System.out.println( "LivingCreature finalize"); // Call base-class version LAST! if(DoBaseFinalization.flag) try { super.finalize(); } catch(Throwable t) {} } } class Animal extends LivingCreature { Characteristic p = new Characteristic("has heart"); Animal() {

System.out.println("Animal()"); } protected void finalize() { System.out.println("Animal finalize"); if(DoBaseFinalization.flag) try { super.finalize(); } catch(Throwable t) {} } } class Amphibian extends Animal { Characteristic p = new Characteristic("can live in water"); Amphibian() { System.out.println("Amphibian()"); } protected void finalize() { System.out.println("Amphibian finalize"); if(DoBaseFinalization.flag) try { super.finalize(); } catch(Throwable t) {} } } public class Frog extends Amphibian { Frog() { System.out.println("Frog()"); } protected void finalize() { System.out.println("Frog finalize"); if(DoBaseFinalization.flag) try { super.finalize(); } catch(Throwable t) {} } public static void main(String[] args) { if(args.length != 0 && args[0].equals("finalize")) DoBaseFinalization.flag = true; else System.out.println("not finalizing bases"); new Frog(); // Instantly becomes garbage System.out.println("bye!"); // Must do this to guarantee that all // finalizers will be called: System.runFinalizersOnExit(true); } } ///:~

La clase DoBaseFinalization simplemente contiene un indicador que indica a cada clase en la jerarquía al llamar a super.finalize(). Este indicador esta basado en un argumento de línea de comando, por eso puedes ver el comportamiento con y sin finalización de la clase-base.

Cada clase en la jerarquía también contiene un objeto miembro de la clase Characteristic. Veremos que los regardless of whether finalizadores de la clase base son llamados, los objetos miembros de Characteristic son siempre finalizados.

Cada método finalize() overridden debe tener acceso al menos a los miembros protegidos desde que el método finalize() en la clase Object esta protegida y el compilador no te permitirá reducir el acceso durante la herencia. ("Amistosamente" es menos accesible que protegido.)

En Frog.main(), el indicador DoBaseFinalization esta configurada y un objeto simple Frog es creado. Recuerde que la colección de basura y en particular la finalización puede no ocurrir para ningún objeto particular por eso para forzar esto, System.runFinalizersOnExit(true) añade el overhead extra para garantizar que la finalizar tiene lugar. Sin la finalización de la clase-base, la salida es:

not finalizing bases Creating Characteristic is alive LivingCreature() Creating Characteristic has heart Animal() Creating Characteristic can live in water Amphibian() Frog() bye! Frog finalize finalizing Characteristic is alive finalizing Characteristic has heart finalizing Characteristic can live in water

Puedes ver que, realmente, no son llamados los finalizadores para la clase base de Frog. Pero si añade el argumento "finalize" en la línea de comando, consigues:

Creating Characteristic is alive LivingCreature() Creating Characteristic has heart Animal() Creating Characteristic can live in water

Amphibian() Frog() bye! Frog finalize Amphibian finalize Animal finalize LivingCreature finalize finalizing Characteristic is alive finalizing Characteristic has heart finalizing Characteristic can live in water

Aunque el orden de los objetos miembro están finalizados es el mismo orden en que fueron creados, técnicamente el orden de finalización de objetos esta inespecificado. Con las clases base, Aunque, tienes control sobre el orden de finalización. El mejor orden para usar es el que se muestra aquí, que es inverso al orden de inicialización. Siguiendo la forma usada en C++ para destructores, deberías permitir que las clases derivadas en la primera finalización, entonces finaliza la clase base. Esto es por que la finalización de la clase derivada podría llamar a algunos métodos en la clase base que requiere que los componentes de la clase base están todavía "vivas", por eso debes no destruirlos prematuramente.

Funcionamiento de los métodos polimorficos dentro de los constructores

La jerarquía de las llamadas a constructores nos trae un dilema interesante. ¿Qué sucede si estas dentro de un constructor y llamas a un método dynamically-bounddel objeto que s esta construyendo? Dentro de un método ordinario puedes imaginar que sucederá o la llamada al dynamically-bound es resuelta en tiempo de ejecución por que el objeto no puede saber si pertenece a la clase el método está dentro o alguna clase derivada de ella. Puedes pensar esto es que podría suceder dentro de los constructores.

Este no es exactamente el caso. Si llamas a un método dynamically-bound dentro de un constructor, la definición overridden para ese método es usada aunque, el efecto puede ser inesperado, y puede conllevar algunos errores difíciles de encontrar.

Conceptualmente, el trabajo del constructor es traer el objeto a la existenica (que es duro una ordinaria hazaña). Dentro de cualquier constructor, el objeto puede ser solo parcialmente formado y solo puedes saber que los objetos de la clase-base han sido inicializados, pero no puedes saber que clases son heredados. Una llamada a un método dynamically-bound, Aunque, "adelante", o "detrás" dentro de la jerarquía de herencia. Este llama un método en una clase derivada. Si haces esto dentro de un constructor, llamas a un método que puedas manipular miembros que no hayan sido inicializados todavía y una receta para el desastre.

Puedes ver el problema en el ejemplo siguiente:

//: PolyConstructors.java // Constructors and polymorphism // don't produce what you might expect. abstract class Glyph { abstract void draw(); Glyph() { System.out.println("Glyph() before draw()"); draw(); System.out.println("Glyph() after draw()"); } } class RoundGlyph extends Glyph { int radius = 1; RoundGlyph(int r) { radius = r; System.out.println( "RoundGlyph.RoundGlyph(), radius = " + radius); } void draw() { System.out.println( "RoundGlyph.draw(), radius = " + radius); } } public class PolyConstructors { public static void main(String[] args) { new RoundGlyph(5); } } ///:~

En Glyph, el método draw() es abstracto, por eso esta diseñado para ser sobreescrito. Realmente, estas forzado para que lo sobreescriba en Round Glyph. Pero el constructor Glyph llama a este método, y la llamada termina, en RoundGlyph.draw() que parecería que hace el intento. Pero mire la salida:

Glyph() before draw() RoundGlyph.draw(), radius = 0 Glyph() after draw() RoundGlyph.RoundGlyph(), radius = 5

Cuando el constructor de Glyph llama a draw(), el valor de radius no está todavía inicializado a 1. Es cero, esto resultará, probablemente o un punto o nada será pintado en la pantalla, y estará staring intentando to figure out porque el programa no funcionará.

El orden de inicialización descrita en la sección previa isn´t quite complete , y que es la llave para resolver el misterio. El actual proceso de inicialización es:

1. El almacenamiento señalado para los objetos es inicializado a 0 binario antes de que nada suceda.

2. Los constructores clase-base son llamados como se describió anteriormente. En este punto, el método overridden draw() es llamado (si, antes de que sea llamado el constructor de RoundGlyph) que describe un radio de valor de cero, debido al paso 1.

3. Los inicializadores de miembros son llamados en el orden de declaración. 4. El cuerpo de los constructores de la clase-derivada es llamada.

Hay una razón para este, es que todo es al menos inicializado a cero (o, cero significa para este particular tipo de dato) y no figura como basura. Esto incluye los manejadores de objeto que son embedbed dentro de una clase vía composición. Por eso si olvidas inicializar que el manejador conseguirá una excepción en tiempo de ejecución. Todo lo demás tiene 0, que es usualmente el valor a telltale cuando locking at output .

Por otro lado, deberías extrañarte de este programa. Has hecho unas cosas perfectamente lógicas y su funcionamiento es misteriosamente erroneo, sin protesta del compilador (C++ produce funcionamiento mas racional en esta situación.) Errores como esto, podrían ser fácilmente aburridos y que llevaría tiempo descubrir.

Como resultado, una buena guía en línea para constructores es, hacer lo menos posible para poner el objeto en el estado bueno, y si puede evitarse, no hay ningún método." El único método seguro es llamar dentro un constructor es este que es final en la clase base. (Eso también es aplicable a método privados que son automáticamente finales). Estos no pueden ser overridden y así no puede producir este tipo de sorpresa.

Diseñando con herencia

Una vez hemos aprendido a cerca del polimorfismo, puede parecer que todo debe ser heredado por que el polimorfismo es una inteligente herramienta. Esto puede ser una carga para tus diseños; de echo si eliges la herencia primero cuando estas usando una clase existente para hacer nuevas clases con clases puede ser complicado.

Un mejor ejemplo es elegir primero composición, cuando esto no es obvio cual debemos usar la composición no fuerza al diseño en una jerarquía de herencia.

Pero la composición es también mas flexible desde que es posible elegir dinámicamente un tipo (y su funcionamiento) cuando usas composición, como una herencia requiere un tipo exacto conocido en tiempo de compilación. El siguiente ejemplo ilustra esto:

//: Transmogrify.java // Dynamically changing the behavior of // an object via composition. interface Actor { void act(); } class HappyActor implements Actor { public void act() { System.out.println("HappyActor"); } } class SadActor implements Actor { public void act() { System.out.println("SadActor"); } } class Stage { Actor a = new HappyActor(); void change() { a = new SadActor(); } void go() { a.act(); } } public class Transmogrify { public static void main(String[] args) { Stage s = new Stage(); s.go(); // Prints "HappyActor" s.change(); s.go(); // Prints "SadActor" } } ///:~

Un objeto Stage contiene un manejador para un Actor, que es inicializado a un objeto HappyActor. Esto significa que go() produce un funcionamiento particular. Pero desde que un manejador puede ser re-bound a un objeto diferente en tiempo de compilación, el manejador para el objeto SadActor puede ser sustituido en "a" y entonces el funcionamiento producido por go() cambia. Incluso ganas en flexibilidad dinámica en tiempo de ejecución. En contraste, no puedes decidir en heredar diferentemente en tiempo de ejecución; que debe ser completamente

determinado en tiempo de compilación.

Una guía en línea general es usar la herencia para expresar diferencias en su funcionamiento, y variables miembro para expresar variaciones en el estado." En el ejemplo de abajo, son usados tanto: 2 clases diferentes son heredados para expresar la diferencia en el método act(), y Stage usa composición para permitir que el estado sea cambiando. En este caso, este cambio es el estado sucede para producir un cambio en su funcionamiento.

Herencia pura vs. extension

Cuando estudiamos la herencia, podría parecer que la forma mas clara de crear una jerarquía de herencia es tomar el ejemplo puro. Esto es, solo con método que han sido establecidos en la clase base o interface que serán overridden en la clase derivada, como se ve en este diagrama:

Este puede ser llamado una relación "ia-a" pura por la interface de una clase establecida que es. La herencia garantiza que ninguna clase derivada tendrá el interface de la clase base y nada menos. Si sigues el diagrama de abajo, las clases derivadas tendrán también no mas que el interface de la clase base.

Esto puede a traves de una sustitución pura, por que los objetos de la clase derivada pueden ser perfectamente sustituidos por la clase base, y nunca necesitarás saber ninguna información extra a cerca de las subclases cuando estás usándolas:

Esto es, la clase base puede recibir cualquier mensaje que puedas mandar a la clase derivada ya que las dos tienen exactamente el mismo interface. Todo lo que necesitas hacer es upcast de la clase derivada y nunca volver a mirara que tipo exacto de objeto es con el que estas tratando. Todo es manejado a través del polimorfismo.

Cuando ves esta forma, parecerá una relación "is-a" pura es la única forma sensible para hacer cosas, y ningún otro diseño indica pensamiento "barroso" y es por definición "broken". Esto es también una trampa. Tan pronto como empieces a pensar de esta forma, volverás y descubrirás que extendido el interface (con, desafortunadamente, la palabra clave extiende parece promover) es la perfecta solución a un problema particular. Esto podría ser llamado una relacción "is-like-a" por que la clase derivada es como la clase base y esto tiene fundamentalmente el mismo interface y pero esto tiene otras caracteristicas que requieren métodos adicionales para implementar:

Mientras esto sea también un ejemplo útil y sensible (depende de la situación) esto tiene una desventaja la parte extendida del interface en la clase derivada no esta disponible desde la clase base, por lo que una vez upcast no puedes llamar los nuevos métodos:

Si no estas upcasting en este caso, no te preocupará pero con frecuencia te encontrarás en una situación en la que necesitas redescubrir el tipo exacto del objeto, por eso puedes acceder a los métodos extendidos de este tipo. La sección

siguiente enseña como se hace esto.

Downcasting y identificación de tipos en tiempo de ejecución

Desde que pierdes la información del tipo especifico por un upcast (moviéndose en la jerarquía de herencia), este se asegura que para recuperar la información del tipo y esto es, moverse abajo en la jerarquía de herencia y usa un downcast . Como sea, saber que un upcast es siempre seguro; la clase base no puede tener un interface mas grande que el de la derivada, entonces todos los mensajes que se mandan a través del interface de la clase base es garantizado que será aceptado. Pero con un downcast , no puedes realmente saber que "shape" (por ejemplo) es actualmente un circulo. Esto puede en vez de ser un triángulo o un cuadrado u otro tipo.

Para resolver este problema debe existir alguna forma de garantizar que un downcast es correcto, por eso no cast accidentalmente a un tipo erróneo y luego mandar un mensaje que el objeto no puede aceptar. Esto no seria seguro.

En algunos lenguajes (como C++) deber permitir una operación especial para conseguir un downcast de tipo seguro, pero en Java todos los cast son chequeados. Incluso cuando parecen proporcionados por un parentesco ordinario en un cast , en tiempo de ejecución este cast es chequeado para asegurarse de que es de echo el tipo que pensamos que es. Si no lo es, tendrás una ClassCastException. Este acto de chequear los tipos en tiempo de ejecución es llamando identificación de tipo en tiempo de ejecución (ITTE). El próximo ejemplo demuestra el funcionamiento de (ITTE):

//: RTTI.java // Downcasting & Run-Time Type

// Identification (RTTI) import java.util.*; class Useful { public void f() {} public void g() {} } class MoreUseful extends Useful { public void f() {} public void g() {} public void u() {} public void v() {} public void w() {} } public class RTTI { public static void main(String[] args) { Useful[] x = { new Useful(), new MoreUseful() }; x[0].f(); x[1].g(); // Compile-time: method not found in Useful: //! x[1].u(); ((MoreUseful)x[1]).u(); // Downcast/RTTI ((MoreUseful)x[0]).u(); // Exception thrown } } ///:~

Como en el diagrama, MoreUseful extiende el interface de Useful. Pero desde que es heredado, puede ser también upcast a un Useful. Puedes ver este echo en la inicialización del array x en main(). Desde que ambos objetos en el array son de la clase Useful, puedes mandar los f() y g() a ambos, y si intentas llamar al método u() (que existe solo en MoreUseful) obtendrás un error en tiempo de compilación.

Si quieres acceder al interface extendido del objeto MoreUseful, puedes intentar downcast . Si es el tipo correcto, será satisfactorio. De otro modo obtendrás un ClassCastException. No necesitas escribir ningún código especial para esta excepción, desde que indica un error al programador que puede suceder en cualquier sitio de un programa.

Hay mas de ITTE que un simple cast . Por ejemplo, hay una forma de ver que tipo es con el que estas tratando antes de intentar downcast it . Todo el capitulo 11 es dedicado a estudiar los diferentes aspectos de Java de identificación de tipos en tiempo de ejecución.

Resumen

Polimorfismo significa "diferentes formas". En la programación orientada a objetos, tienes la misma cara (el mismo interface en la clase base) y diferentes formas de usar esa cara: las diferentes versiones de los métodos dynamically-bound .

Hemos visto en este capitulo que es imposible comprender o incluso crear un ejemplo de polimorfismo sin usar datos de abstracción y herencia. El polimorfismo es una característica que no puede ser visto aislado (como una orden switch, por ejemplo), pero en vez de funcionar solo como se planeo, como parte de un "gran-cuadro" de clases de relaciones. La gente suele confundirse por otros, caracteristicas de Java no orientadas a objetos, como método overloading que son algunas veces presentados como objeto orientado. No se engañe: si no es late binding , no es polimorfismo.

Para usar polimorfimso, y así las técnicas orientadas a objetos, efectivamente en tus programas debes expandir tu visión de programar para incluir no solamente miembros y mensajes de clase individuales pero tambien las diferentes clases comunes y sus relaciones con cada otro. Aunque requiere un esfuerzo significante, es un preciado esfuerzo, por que los resultados son mas rápidos que el desarrollo de programas mejores organizados y codificados, programas extensibles, y código mas fácil de mantener.

Ejercicios

1. Añade un nuevo método a la clase base Shapes.java que imprima un mensaje, pero no lo sobreescribas en la clase derivada. Explica que ocurre. Ahora sobreescríbelo en una de las clases derivadas pero no en las otra y observa lo que ocurre. Finalmente, sobreescr íbelo en todas las clases derivadas.

2. Añade un nuevo tipo de Shape a Shapes.java y verifica en el main() que el polimorfismo funciona para tu nuevo tipo como lo hacía para los viejos.

3. Cambia Music3.java para que what() sea predominante sobre el método toString()de Object . Intenta imprimir el objeto Instrument usando System.out.println() (sin ningún casting).

4. Añade una nuevo tipo de Instrument a Music3.java y verifica que el polimorfismo funciona para tu nuevo tipo.

5. Modifica Music3.java para que cree objetos tipo Instrument aleatoriamente de la forma que Shapes.java lo hace.

6. Crear una jerarquía de herencia de Rodent: Mouse, Gerbil, Hamster, etc. En la clase base se proveen métodos que son comunes a todos los Rodents y override esto en las clase derivadas para permitir diferentes funcionamientos dependiente de un tipo especifico de Rodent. Crear un array de Rodent, llenarlo con diferentes tipo específicos de Rodents, y llame a los métodos de la clase base para ver que sucede.

7. Cambiar el ejercicio 6 parar que Rodent sea una clase abstracta. Transforma los

métodos de Rodent en abstract en la medida que sea posible. 8. Crea una clase como abstract sin incluir ningún método abstracto y verifica que no

puedes crear ninguna llamada a esa clase. 9. Añade la clase Pickle a Sandwich.java .

10. Modifica el ejercicio 6 para que muestre el orden de inicialización de las clases bases y derivadas. Ahora, añade un objeto miembro a las clases base y derivadas, y observa el orden en el cual la inicialización ocurre en la construcción de los objetos.

11. Crea una jerarquía de herencia de tercer nivel. Cada clase en la jerarquía debe tener un método finalize() y debe llamar debidamente a la versión de finalize() de la clase base. Demostrar que tu jerarquía funciona correctamente.

12. Crear una clase base con dos métodos. En el primero, llama al segundo. De ella hereda una clase y sobreescribe el segundo método. Crea un objeto de la clase derivada, haz un "upcast" hacia la clae base y llama al primer método. Explica lo que ocurre.

13. Crea una clase con un método abstract imprime() que sea sobreescrito en una clase derivada. La versión sobreescrita del método imprime el valor de un entero definido en la clase derivada. Como valor inicial, dale un valor distinto de cero. En el constructor de la clase base, llama a este método. En main() , crea un objeto de la clase derivada y llama a su imprime() . Explica los resultados.

14. Siguiendo el ejemplo en Transmogrify.java , crea una clase Starship que contenga una referencia a AlertStatus que pueda indicar tres estados diferentes. Incluye métodos para cambiar los estados.

15. Crea una clase abstracta sin métodos. Deriva de ella una clase y añade un método. Crea un método estático que haga una referencia a la clase base, haz un "downcasts" hacia la clase derivada y llama al método. En el main() , demuestra como trabaja. Ahora pon la declaración de abstracta para el método en la clase base, lo que elimina la necesidad de hacer un "downcasts".