1. Introducción

En este tutorial, abordaremos los fundamentos del manejo de excepciones en Java, así como algunas de sus particularidades.

2. Principios Básicos

2.1. ¿Qué Es?

Para comprender mejor las excepciones y el manejo de ellas, hagamos una comparación con la vida real.

Imagina que ordenamos un producto en línea, pero en el camino hay un problema en la entrega. Una buena empresa puede manejar este problema y redirigir elegantemente nuestro paquete para que aún llegue a tiempo.

De manera similar, en Java, el código puede experimentar errores mientras ejecuta nuestras instrucciones. Un buen manejo de excepciones puede manejar los errores y redirigir el programa de manera que el usuario aún tenga una experiencia positiva.

2.2. ¿Por Qué Usarlo?

Normalmente, escribimos código en un entorno idealizado: el sistema de archivos siempre contiene nuestros archivos, la red está saludable y la JVM siempre tiene suficiente memoria. A veces llamamos a esto el "camino feliz".

Sin embargo, en producción, los sistemas de archivos pueden corromperse, las redes pueden fallar y las JVM pueden quedarse sin memoria. El bienestar de nuestro código depende de cómo maneje los "caminos infelices".

Debemos manejar estas condiciones porque afectan negativamente al flujo de la aplicación y generan excepciones:

public static List<Jugador> obtenerJugadores() throws IOException {
    Path ruta = Paths.get("jugadores.dat");
    List<String> jugadores = Files.readAllLines(ruta);

    return jugadores.stream()
      .map(Jugador::new)
      .collect(Collectors.toList());
}

Este código elige no manejar la IOException, sino pasarla hacia arriba en la pila de llamadas. En un entorno idealizado, el código funciona bien.

Pero, ¿qué podría pasar en producción si falta jugadores.dat?

Exception in thread "main" java.nio.file.NoSuchFileException: players.dat <-- players.dat file doesn't exist
    at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
    at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
    // ... más traza de la pila
    at java.nio.file.Files.readAllLines(Unknown Source)
    at java.nio.file.Files.readAllLines(Unknown Source)
    at Excepciones.obtenerJugadores(Excepciones.java:12) <-- La excepción ocurre en el método obtenerJugadores(), en la línea 12
    at Excepciones.main(Excepciones.java:19) <-- obtenerJugadores() es llamado por main(), en la línea 19

Sin manejar esta excepción, ¡un programa por lo demás saludable podría dejar de ejecutarse por completo! Necesitamos asegurarnos de que nuestro código tenga un plan para cuando las cosas salgan mal.

También cabe destacar otro beneficio aquí, y es la propia traza de la pila. Gracias a esta traza, a menudo podemos identificar el código ofensor sin necesidad de utilizar un depurador.

3. Jerarquía de Excepciones

En última instancia, las excepciones son simplemente objetos de Java, y todas ellas extienden de Throwable:

Hay tres categorías principales de condiciones excepcionales:

• Excepciones verificadas
• Excepciones no verificadas / Excepciones en tiempo de ejecución
• Errores

Las excepciones en tiempo de ejecución y las excepciones no verificadas se refieren a lo mismo y a menudo se pueden usar de manera intercambiable.

3.1. Excepciones Verificadas

Las excepciones verificadas son excepciones que el compilador de Java nos exige manejar. Debemos o bien declarar explícitamente que lanzaremos la excepción hacia arriba en la pila de llamadas, o debemos manejarla nosotros mismos. Hablaremos más sobre ambos en un momento.

La documentación de Oracle nos dice que debemos usar excepciones verificadas cuando razonablemente esperamos que el llamante de nuestro método pueda recuperarse.

Algunos ejemplos de excepciones verificadas son IOException y ServletException.

3.2. Excepciones No Verificadas

Las excepciones no verificadas son excepciones que el compilador de Java no nos exige manejar.

En pocas palabras, si creamos una excepción que extiende de RuntimeException, será no verificada; de lo contrario, será verificada.

Y aunque esto suena conveniente, la documentación de Oracle nos dice que hay buenas razones para ambos conceptos, como diferenciar entre un error situacional (verificado) y un error de uso (no verificado).

Algunos ejemplos de excepciones no verificadas son NullPointerException, IllegalArgumentException y SecurityException.

3.3. Errores

Los errores representan condiciones graves y generalmente irreparables, como una incompatibilidad de biblioteca, una recursión infinita o fugas de memoria.

Y aunque no extienden RuntimeException, también son no verificados.

En la mayoría de los casos, sería extraño que manejáramos, instanciáramos o extendiéramos Error(s). Por lo general, queremos que estos se propaguen hasta arriba.

Algunos ejemplos de errores son StackOverflowError y OutOfMemoryError.

4. Manejo de Excepciones

En la API de Java, hay muchos lugares donde las cosas pueden salir mal, y algunos de estos lugares están marcados con excepciones, ya sea en la firma o en el Javadoc:

/**
 * @exception FileNotFoundException ...
 */
public Scanner(String fileName) throws FileNotFoundException {
   // ...
}

Como mencionamos un poco antes, cuando llamamos a estos métodos "arriesgados", debemos manejar las excepciones verificadas y podemos manejar las no verificadas. Java nos ofrece varias formas de hacer esto:

4.1. throws

La forma más simple de "manejar" una excepción es relanzarla:

public int obtenerPuntuacionJugador(String archivoJugador)
  throws FileNotFoundException {
 
    Scanner contenido = new Scanner(new File(archivoJugador));
    return Integer.parseInt(contenido.nextLine());
}

Dado que FileNotFoundException es una excepción verificada, esta es la forma más sencilla de satisfacer al compilador, pero significa que cualquiera que llame a nuestro método ahora también debe manejarla.

parseInt puede lanzar una NumberFormatException, pero como es una excepción no verificada, no estamos obligados a manejarla.

4.2. try-catch

Si queremos intentar manejar la excepción nosotros mismos, podemos usar un bloque try-catch. Podemos manejarlo volviendo a lanzar nuestra excepción:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        Scanner contenido = new Scanner(new File(archivoJugador));
        return Integer.parseInt(contenido.nextLine());
    } catch (FileNotFoundException noArchivo) {
        throw new IllegalArgumentException("Archivo no encontrado");
    }
}

O realizando pasos de recuperación:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        Scanner contenido = new Scanner(new File(archivoJugador));
        return Integer.parseInt(contenido.nextLine());
    } catch ( FileNotFoundException noArchivo ) {
        logger.warn("Archivo no encontrado, restableciendo puntuación.");
        return 0;
    }
}

4.3. finally

Hay momentos en los que tenemos código que debe ejecutarse independientemente de si se produce una excepción, y aquí es donde entra la palabra clave finally.

En nuestros ejemplos hasta ahora, ha habido un error molesto acechando en las sombras, que es que Java, por defecto, no devolverá los identificadores de archivos al sistema operativo.

Ciertamente, ya sea que podamos leer el archivo o no, queremos asegurarnos de hacer la limpieza adecuada.

Probemos esto de la manera "perezosa" primero:

public int obtenerPuntuacionJugador(String archivoJugador)
  throws FileNotFoundException {
    Scanner contenido = null;
    try {
        contenido = new Scanner(new File(archivoJugador));
        return Integer.parseInt(contenido.nextLine());
    } finally {
        if (contenido != null) {
            contenido.close();
        }
    }
}

Aquí, el bloque finally indica qué código queremos que Java ejecute independientemente de lo que suceda al intentar leer el archivo.

Incluso si se lanza una FileNotFoundException hacia arriba en la pila de llamadas, Java llamará al contenido de finally antes de hacerlo.

También podemos manejar la excepción y asegurarnos de que nuestros recursos se cierren:

public int obtenerPuntuacionJugador(String archivoJugador) {
    Scanner contenido;
    try {
        contenido = new Scanner(new File(archivoJugador));
        return Integer.parseInt(contenido.nextLine());
    } catch (FileNotFoundException noArchivo ) {
        logger.warn("Archivo no encontrado, restableciendo puntuación.");
        return 0; 
    } finally {
        try {
            if (contenido != null) {
                contenido.close();
            }
        } catch (IOException io) {
            logger.error("No se pudo cerrar el lector!", io);
        }
    }
}

Debido a que close también es un método "arriesgado", también necesitamos capturar su excepción.

Esto puede parecer bastante complicado, pero necesitamos cada pieza para manejar correctamente cada problema potencial que pueda surgir.

4.4. try-with-resources

Afortunadamente, a partir de Java 7, podemos simplificar la sintaxis anterior cuando trabajamos con elementos que extienden AutoCloseable:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try (Scanner contenido = new Scanner(new File(archivoJugador))) {
      return Integer.parseInt(contenido.nextLine());
    } catch (FileNotFoundException e ) {
      logger.warn("Archivo no encontrado, restableciendo puntuación.");
      return 0;
    }
}

Cuando colocamos referencias que son AutoCloseable en la declaración try, entonces no necesitamos cerrar el recurso nosotros mismos.

Aún podemos usar un bloque finally para realizar cualquier otro tipo de limpieza que deseemos.

En próximas publicaciones, veremos un artículo dedicado a try-with-resources para explorarlo en mayor profundidad.

4.5. Múltiples Bloques catch

A veces, el código puede generar más de una excepción, y podemos tener más de un bloque catch para manejar cada una individualmente:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try (Scanner contenido = new Scanner(new File(archivoJugador))) {
        return Integer.parseInt(contenido.nextLine());
    } catch (IOException e) {
        logger.warn("¡No se pudo cargar el archivo del jugador!", e);
        return 0;
    } catch (NumberFormatException e) {
        logger.warn("¡El archivo del jugador está corrupto!", e);
        return 0;
    }
}

Los bloques catch múltiples nos brindan la oportunidad de manejar cada excepción de manera diferente, si es necesario.

También nota aquí que no capturamos FileNotFoundException, y eso se debe a que extiende IOException. Dado que estamos capturando IOException, Java considerará que cualquiera de sus subclases también está manejada.

Sin embargo, supongamos que necesitamos tratar FileNotFoundException de manera diferente a la IOException más general:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try (Scanner contenido = new Scanner(new File(archivoJugador)) ) {
        return Integer.parseInt(contenido.nextLine());
    } catch (FileNotFoundException e) {
        logger.warn("¡Archivo del jugador no encontrado!", e);
        return 0;
    } catch (IOException e) {
        logger.warn("¡No se pudo cargar el archivo del jugador!", e);
        return 0;
    } catch (NumberFormatException e) {
        logger.warn("¡El archivo del jugador está corrupto!", e);
        return 0;
    }
}

Java nos permite manejar excepciones de subclases por separado, recuerda colocarlas más arriba en la lista de catch.

4.6. Bloques catch de Unión

Cuando sabemos que la forma en que manejamos los errores será la misma, Java 7 introdujo la capacidad de capturar múltiples excepciones en el mismo bloque:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try (Scanner contenido = new Scanner(new File(archivoJugador))) {
        return Integer.parseInt(contenido.nextLine());
    } catch (IOException | NumberFormatException e) {
        logger.warn("Error al cargar la puntuación.", e);
        return 0;
    }
}

5. Lanzamiento de Excepciones

Si no queremos manejar la excepción nosotros mismos o queremos generar nuestras propias excepciones para que otros las manejen, entonces necesitamos familiarizarnos con la palabra clave throw.

Supongamos que tenemos la siguiente excepción verificada que hemos creado nosotros mismos:

public class ExcepcionTiempoAgotado extends Exception {
    public ExcepcionTiempoAgotado(String mensaje) {
        super(mensaje);
    }
}

y tenemos un método que podría tomar mucho tiempo en completarse:

public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) {
    // ... operación potencialmente larga
}

5.1. Lanzamiento de una Excepción Verificada

Al igual que con la devolución de un método, podemos hacer throw en cualquier punto.

Por supuesto, deberíamos lanzar cuando intentamos indicar que algo ha salido mal:

public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) throws ExcepcionTiempoAgotado {
    while ( !demasiadoTiempo ) {
        // ... operación potencialmente larga
    }
    throw new ExcepcionTiempoAgotado("Esta operación tardó demasiado");
}

Dado que ExcepcionTiempoAgotado es verificada, también debemos usar la palabra clave throws en la firma para que los llamadores de nuestro método sepan que deben manejarla.

5.2. Lanzamiento de una Excepción No Verificada

Si queremos hacer algo como validar la entrada, podemos usar una excepción no verificada:

public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) throws ExcepcionTiempoAgotado {
    if (!esNombreDeArchivoValido(archivoJugadores)) {
        throw new IllegalArgumentException("¡El nombre de archivo no es válido!");
    }
   
    // ...
}

Dado que IllegalArgumentException no es verificada, no tenemos que marcar el método, aunque podemos hacerlo si lo deseamos.

Algunos marcan el método de todos modos como una forma de documentación.

5.3. Envoltura y Relanzamiento

También podemos elegir relanzar una excepción que hemos capturado:

public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) 
  throws IOException {
    try { 
        // ...
    } catch (IOException io) { 		
        throw io;
    }
}

O hacer una envoltura y relanzamiento:

public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) 
  throws ExcepcionCargaJugador {
    try { 
        // ...
    } catch (IOException io) { 		
        throw new ExcepcionCargaJugador(io);
    }
}

Esto puede ser útil para consolidar muchas excepciones diferentes en una.

5.4. Relanzamiento de Throwable o Exception

Ahora, un caso especial.

Si las únicas excepciones posibles que un bloque de código podría generar son excepciones no verificadas, entonces podemos capturar y relanzar Throwable o Exception sin agregarlas a la firma de nuestro método:

public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) {
    try {
        throw new NullPointerException();
    } catch (Throwable t) {
        throw t;
    }
}

Aunque simple, el código anterior no puede lanzar una excepción verificada y, debido a eso, incluso si estamos relanzando una excepción verificada, no tenemos que marcar la firma con una cláusula throws.

Esto es útil con clases y métodos de proxy. Puedes encontrar más información al respecto aquí.

5.5. Herencia

Cuando marcamos métodos con una palabra clave throws, afecta cómo las subclases pueden anular nuestro método.

En la circunstancia en la que nuestro método lanza una excepción verificada:

public class Excepciones {
    public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) 
      throws ExcepcionTiempoAgotado {
        // ...
    }
}

Una subclase puede tener una firma "menos arriesgada":

public class MenosExcepciones extends Excepciones {	
    @Override
    public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) {
        // anulado
    }
}

Pero no una firma "más riesgosa":

public class MasExcepciones extends Excepciones {		
    @Override
    public List<Jugador> cargarTodosLosJugadores(String archivoJugadores) throws MiExcepcionVerificada {
        // anulado
    }
}

Esto se debe a que los contratos se determinan en tiempo de compilación por el tipo de referencia. Si creo una instancia de MasExcepciones y la guardo en Excepciones:

Excepciones excepciones = new MasExcepciones();
excepciones.cargarTodosLosJugadores("archivo");

Entonces la JVM solo me indicará que capture ExcepcionTiempoAgotado, lo cual es incorrecto ya que he dicho que MasExcepciones#cargarTodosLosJugadores lanza una excepción diferente.

En resumen, las subclases pueden lanzar menos excepciones verificadas que su superclase, pero no más.

6. Anti-Patrones

6.1. Tragar Excepciones

Ahora, hay otra manera en la que podríamos haber satisfecho al compilador:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        // ...
    } catch (Exception e) {} // <== captura y traga
    return 0;
}

Lo anterior se llama tragar (swallowing) una excepción. La mayoría de las veces, sería un poco malo hacer esto porque no aborda el problema y evita que otro código también pueda abordarlo.

Hay momentos en los que hay una excepción verificada que estamos seguros de que simplemente nunca ocurrirá. En esos casos, al menos deberíamos agregar un comentario indicando que hemos comido intencionalmente la excepción:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        // ...
    } catch (IOException e) {
        // esto nunca sucederá
    }
}

Otra forma de "tragar" una excepción es imprimir la excepción en el flujo de errores:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        // ...
    } catch (Exception e) {
        e.printStackTrace();
    }
    return 0;
}

Hemos mejorado un poco nuestra situación al menos escribiendo el error en algún lugar para un diagnóstico posterior.

Sería mejor, sin embargo, usar un registrador:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        // ...
    } catch (IOException e) {
        logger.error("No se pudo cargar la puntuación", e);
        return 0;
    }
}

Aunque es muy conveniente manejar las excepciones de esta manera, debemos asegurarnos de no tragar información importante que los llamadores de nuestro código podrían usar para solucionar el problema.

Finalmente, podemos tragar inadvertidamente una excepción al no incluirla como una causa cuando estamos lanzando una nueva excepción:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        // ...
    } catch (IOException e) {
        throw new ExcepcionPuntuacionJugador();
    }
}

Aquí, nos felicitamos por alertar a nuestro llamador sobre un error, pero no incluimos IOException como la causa. Debido a esto, hemos perdido información importante que los llamadores u operadores podrían usar para diagnosticar el problema.

Sería mejor hacer:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        // ...
    } catch (IOException e) {
        throw new ExcepcionPuntuacionJugador(e);
    }
}

Observa la sutil diferencia de incluir IOException como la causa de ExcepcionPuntuacionJugador.

6.2. Uso de return en un Bloque finally

Otra manera de tragar excepciones es retornar desde el bloque finally. Esto es perjudicial porque, al retornar abruptamente, la JVM descartará la excepción, incluso si fue lanzada por nuestro código:

public int obtenerPuntuacionJugador(String archivoJugador) {
    int puntuacion = 0;
    try {
        throw new IOException();
    } finally {
        return puntuacion; // <== la IOException se descarta
    }
}

De acuerdo con la Especificación del Lenguaje Java:

• Si la ejecución del bloque try se completa abruptamente por cualquier otro motivo X, entonces se ejecuta el bloque finally, y luego hay una elección.

• Si el bloque finally se completa normalmente, entonces la declaración try se completa abruptamente por la razón X.

• Si el bloque finally se completa abruptamente por la razón Y, entonces la declaración try se completa abruptamente por la razón Y (y la razón X se descarta).

6.3. Uso de throw en un Bloque finally

Similar al uso de return en un bloque finally, la excepción lanzada en un bloque finally tomará precedencia sobre la excepción que surge en el bloque catch.

Esto "borrará" la excepción original del bloque try, y perdemos toda esa información valiosa:

public int obtenerPuntuacionJugador(String archivoJugador) {
    try {
        // ...
    } catch ( IOException io ) {
        throw new IllegalStateException(io); // <== devorada por el bloque finally
    } finally {
        throw new OtraExcepcion();
    }
}

6.4. Uso de throw como un goto

Algunas personas también sucumben a la tentación de usar throw como una declaración goto:

public void hacerAlgo() {
    try {
        // montón de código
        throw new MiExcepcion();
        // segundo montón de código
    } catch (MiExcepcion e) {
        // tercer montón de código
    }		
}

Esto es extraño porque el código está intentando usar excepciones para el control de flujo en lugar de para el manejo de errores.

7. Excepciones y Errores Comunes

Aquí hay algunas excepciones y errores comunes con los que todos nos encontramos de vez en cuando:

7.1. Excepciones Verificadas

• IOException: Esta excepción suele indicar que algo en la red, el sistema de archivos o la base de datos falló.

7.2. Excepciones de Tiempo de Ejecución

• ArrayIndexOutOfBoundsException: Esta excepción significa que intentamos acceder a un índice de array que no existe, como al intentar obtener el índice 5 de un array de longitud 3.

• ClassCastException: Esta excepción significa que intentamos realizar una conversión ilegal, como intentar convertir una String en una List. Usualmente podemos evitarlo realizando comprobaciones defensivas con instanceof antes de hacer la conversión.

• IllegalArgumentException: Esta excepción es una forma genérica de decir que uno de los parámetros proporcionados al método o constructor es inválido.

• IllegalStateException: Esta excepción es una forma genérica de decir que nuestro estado interno, como el estado de nuestro objeto, es inválido.

• NullPointerException: Esta excepción significa que intentamos referenciar un objeto null. Usualmente podemos evitarlo realizando comprobaciones defensivas contra null o utilizando Optional.

• NumberFormatException: Esta excepción significa que intentamos convertir una String en un número, pero la String contenía caracteres no válidos, como intentar convertir 13f37 en un número.

7.3. Errores

• StackOverflowError: Este error significa que la traza de la pila es demasiado grande. Esto a veces puede ocurrir en aplicaciones masivas; sin embargo, generalmente significa que hay una recursión infinita en nuestro código.

• NoClassDefFoundError: Este error significa que una clase no se pudo cargar ya sea porque no está en el classpath o debido a un fallo en la inicialización estática.

• OutOfMemoryError: Este error significa que la JVM no tiene más memoria disponible para asignar más objetos. A veces, esto se debe a una fuga de memoria.

8. Conclusión

En este artículo, hemos repasado los conceptos básicos del manejo de excepciones, así como algunos ejemplos de prácticas buenas y malas.

1. Introducción

En este tutorial, aprenderemos qué son los enumerados (enums) en Java, los problemas que resuelven y cómo algunos de sus patrones de diseño pueden utilizarse en la práctica.

Java 5 introdujo por primera vez la palabra clave enum. Esta denota un tipo especial de clase que siempre extiende la clase java.lang.Enum. Para la documentación oficial sobre su uso, podemos dirigirnos a la documentación.

Las constantes definidas de esta manera hacen que el código sea más legible, permiten la verificación en tiempo de compilación, documentan la lista de valores aceptados de antemano y evitan comportamientos inesperados debido a valores no válidos que se pasan.

Aquí hay un ejemplo rápido y simple de un enumerado que define el estado de un pedido de pizza; el estado del pedido puede ser ORDENADO, LISTO o ENTREGADO:

public enum EstadoPizza {
    ORDENADO,
    LISTO,
    ENTREGADO; 
}

Además, los enumerados vienen con muchos métodos útiles que de otra manera tendríamos que escribir si estuviéramos usando constantes tradicionales public static final.

2. Métodos Personalizados en Enumerados

Ahora que tenemos una comprensión básica de qué son los enumerados y cómo podemos usarlos, llevaremos nuestro ejemplo anterior al siguiente nivel definiendo algunos métodos adicionales de la API en el enumerado:

public class Pizza {
    private EstadoPizza estado;
    public enum EstadoPizza {
        ORDENADO,
        LISTO,
        ENTREGADO;
    }

    public boolean esEntregable() {
        return obtenerEstado() == EstadoPizza.LISTO;
    }
    
    // Métodos que establecen y obtienen la variable de estado.
}

3. Comparación de Tipos de Enumerados Usando el Operador "=="

Dado que los tipos de enumerados aseguran que solo exista una instancia de las constantes en la JVM, podemos usar de manera segura el operador "" para comparar dos variables, como hicimos en el ejemplo anterior. Además, el operador "" proporciona seguridad en tiempo de compilación y tiempo de ejecución.

Primero, analizaremos la seguridad en tiempo de ejecución en el siguiente fragmento, donde usaremos el operador "==" para comparar estados. Cualquiera de los valores puede ser null y no obtendremos un NullPointerException. Por el contrario, si usamos el método equals, obtendremos un NullPointerException:

if (testPz.obtenerEstado().equals(Pizza.EstadoPizza.ENTREGADO)); 
if (testPz.obtenerEstado() == Pizza.EstadoPizza.ENTREGADO);

En cuanto a la seguridad en tiempo de compilación, veamos un ejemplo donde determinaremos que un enumerado de un tipo diferente es igual al compararlo usando el método equals. Esto se debe a que los valores del enumerado y el método obtenerEstado coinciden coincidentemente; sin embargo, lógicamente la comparación debería ser falsa. Evitamos este problema usando el operador "==".

El compilador señalará la comparación como un error de incompatibilidad:

if (testPz.obtenerEstado().equals(TestColor.VERDE));
if (testPz.obtenerEstado() == TestColor.VERDE);

4. Uso de Tipos Enumerados en Switch

Podemos usar tipos enumerados en instrucciones switch también:

public int obtenerTiempoEntregaEnDias() {
    switch (estado) {
        case ORDENADO: return 5;
        case LISTO: return 2;
        case ENTREGADO: return 0;
    }
    return 0;
}

5. Campos, Métodos y Constructores en Enumerados

Podemos definir constructores, métodos y campos dentro de tipos enumerados, lo que los hace muy poderosos.

A continuación, ampliemos el ejemplo anterior implementando la transición de una etapa de un pedido de pizza a otra. Veremos cómo podemos eliminar las instrucciones if y switch utilizadas anteriormente:

public class Pizza {

    private EstadoPizza estado;
    public enum EstadoPizza {
        ORDENADO (5) {
            @Override
            public boolean esOrdenado() {
                return true;
            }
        },
        LISTO (2) {
            @Override
            public boolean esListo() {
                return true;
            }
        },
        ENTREGADO (0) {
            @Override
            public boolean esEntregado() {
                return true;
            }
        };

        private int tiempoEntrega;

        public boolean esOrdenado() { return false; }

        public boolean esListo() { return false; }

        public boolean esEntregado() { return false; }

        public int obtenerTiempoEntrega() {
            return tiempoEntrega;
        }

        EstadoPizza (int tiempoEntrega) {
            this.tiempoEntrega = tiempoEntrega;
        }
    }

    public boolean esEntregable() {
        return this.estado.esListo();
    }

    public void imprimirTiempoEntrega() {
        System.out.println("El tiempo de entrega es de " + 
          this.obtenerEstado().obtenerTiempoEntrega() + " días");
    }
    
    // Métodos que establecen y obtienen la variable de estado.
}

El fragmento de prueba a continuación demuestra cómo funciona esto:

@Test
public void dadoPedidoPizza_cuandoListo_entoncesEntregable() {
    Pizza testPz = new Pizza();
    testPz.setEstado(Pizza.EstadoPizza.LISTO);
    assertTrue(testPz.esEntregable());
}

6. EnumSet y EnumMap

6.1. EnumSet

El EnumSet es una implementación especializada de Set destinada a usarse con tipos Enum.

En comparación con un HashSet, es una representación muy eficiente y compacta de un conjunto particular de constantes Enum, gracias a la Representación Interna de Vector de Bits que se utiliza. También proporciona una alternativa segura al tipo basado en int tradicional llamado "bit flags", lo que nos permite escribir código conciso y más legible.

El EnumSet es una clase abstracta que tiene dos implementaciones, RegularEnumSet y JumboEnumSet, una de las cuales se elige según la cantidad de constantes en el enumerado en el momento de la instanciación.

Por lo tanto, es una buena idea usar este conjunto siempre que deseemos trabajar con una colección de constantes Enum en la mayoría de los escenarios (como subconjuntos, adiciones, eliminaciones y operaciones masivas como containsAll y removeAll), y usar Enum.values() si solo queremos iterar sobre todas las constantes posibles.

En el fragmento de código a continuación, podemos ver cómo usar EnumSet para crear un subconjunto de constantes:

public class Pizza {

    private static EnumSet<EstadoPizza> estadosPizzaNoEntregada =
      EnumSet.of(EstadoPizza.ORDENADO, EstadoPizza.LISTO);

    private EstadoPizza estado;

    public enum EstadoPizza {
        // ...
    }

    public boolean esEntregable() {
        return this.estado.esListo();
    }

    public void imprimirTiempoEntrega() {
        System.out.println("El tiempo de entrega es de " + 
          this.obtenerEstado().obtenerTiempoEntrega() + " días");
    }

    public static List<Pizza> obtenerTodasLasPizzasNoEntregadas(List<Pizza> input) {
        return input.stream().filter(
          (s) -> estadosPizzaNoEntregada.contains(s.obtenerEstado()))
            .collect(Collectors.toList());
    }

    public void entregar() { 
        if (esEntregable()) { 
            ConfiguracionSistemaEntregaPizza.obtenerInstancia().obtenerEstrategiaEntrega()
              .entregar(this); 
            this.setEstado(EstadoPizza.ENTREGADO); 
        } 
    }
    
    // Métodos que establecen y obtienen la variable de estado.
}

Ejecutar la siguiente prueba demuestra el poder de la implementación EnumSet de la interfaz Set:

@Test
public void dadoPedidosPizzas_cuandoRecuperandoPizzasNoEntregadas_entoncesRecuperadasCorrectamente() {
    List<Pizza> listaPizzas = new ArrayList<>();
    Pizza pizza1 = new Pizza();
    pizza1.setEstado(Pizza.EstadoPizza.ENTREGADO);

    Pizza pizza2 = new Pizza();
    pizza2.setEstado(Pizza.EstadoPizza.ORDENADO);

    Pizza pizza3 = new Pizza();
    pizza3.setEstado(Pizza.EstadoPizza.ORDENADO);

    Pizza pizza4 = new Pizza();
    pizza4.setEstado(Pizza.EstadoPizza.LISTO);

    listaPizzas.add(pizza1);
    listaPizzas.add(pizza2);
    listaPizzas.add(pizza3);
    listaPizzas.add(pizza4);

    List<Pizza> pizzasNoEntregadas = Pizza.obtenerTodasLasPizzasNoEntregadas(listaPizzas); 
    assertTrue(pizzasNoEntregadas.size() == 3); 
}

6.2. EnumMap

EnumMap es una implementación especializada de Map destinada a usarse con constantes Enum como claves. En comparación con su contraparte HashMap, es una implementación eficiente y compacta que se representa internamente como un array:

EnumMap<Pizza.EstadoPizza, Pizza> mapa;

Veamos un ejemplo de cómo podemos usarlo en la práctica:

public static EnumMap<EstadoPizza, List<Pizza>> agruparPizzasPorEstado(List<Pizza> listaPizzas) {
    EnumMap<EstadoPizza, List<Pizza>> pizzasPorEstado = new EnumMap<EstadoPizza, List<Pizza>>(EstadoPizza.class);
    
    for (Pizza pizza : listaPizzas) {
        EstadoPizza estado = pizza.obtenerEstado();

        if (pizzasPorEstado.containsKey(estado)) {
            pizzasPorEstado.get(estado).add(pizza);
        } else {
            List<Pizza> nuevaListaPizzas = new ArrayList<Pizza>();
            
            nuevaListaPizzas.add(pizza);
            pizzasPorEstado.put(estado, nuevaListaPizzas);
        }
    }
    
    return pizzasPorEstado;
}

Ejecutar la siguiente prueba demuestra el poder de la implementación EnumMap de la interfaz Map:

@Test
public void dadoPedidosPizzas_cuandoLlamamosAgruparPorEstado_entoncesAgrupadosCorrectamente() {
    List<Pizza> listaPizzas = new ArrayList<>();
    Pizza pizza1 = new Pizza();
    pizza1.setEstado(Pizza.EstadoPizza.ENTREGADO);

    Pizza pizza2 = new Pizza();
    pizza2.setEstado(Pizza.EstadoPizza.ORDENADO);

    Pizza pizza3 = new Pizza();
    pizza3.setEstado(Pizza.EstadoPizza.ORDENADO);

    Pizza pizza4 = new Pizza();
    pizza4.setEstado(Pizza.EstadoPizza.LISTO);

    listaPizzas.add(pizza1);
    listaPizzas.add(pizza2);
    listaPizzas.add(pizza3);
    listaPizzas.add(pizza4);

    EnumMap<Pizza.EstadoPizza, List<Pizza>> mapa = Pizza.agruparPizzasPorEstado(listaPizzas);
    assertTrue(mapa.get(Pizza.EstadoPizza.ENTREGADO).size() == 1);
    assertTrue(mapa.get(Pizza.EstadoPizza.ORDENADO).size() == 2);
    assertTrue(mapa.get(Pizza.EstadoPizza.LISTO).size() == 1);
}

7. Implementar Patrones de Diseño Usando Enums

7.1. Patrón Singleton

Normalmente, implementar una clase usando el patrón Singleton es bastante no trivial. Los enums proporcionan una manera rápida y fácil de implementar singletons.

Además, dado que la clase enum implementa la interfaz Serializable bajo el capó, la clase está garantizada como un singleton por la JVM. Esto es a diferencia de la implementación convencional, donde tenemos que asegurarnos de que no se creen nuevas instancias durante la deserialización.

En el fragmento de código a continuación, vemos cómo podemos implementar un patrón singleton:

public enum ConfiguracionSistemaEntregaPizza {
    INSTANCE;
    ConfiguracionSistemaEntregaPizza() {
        // Configuración de inicialización que implica
        // la anulación de los valores predeterminados como la estrategia de entrega
    }

    private EstrategiaEntregaPizza estrategiaEntrega = EstrategiaEntregaPizza.NORMAL;

    public static ConfiguracionSistemaEntregaPizza obtenerInstancia() {
        return INSTANCE;
    }

    public EstrategiaEntregaPizza obtenerEstrategiaEntrega() {
        return estrategiaEntrega;
    }
}

7.2. Patrón de Estrategia

Convencionalmente, el patrón de estrategia (Strategy) se escribe teniendo una interfaz que es implementada por diferentes clases.

Agregar una nueva estrategia significa agregar una nueva clase de implementación. Con enums, podemos lograr esto con menos esfuerzo y agregar una nueva implementación significa simplemente definir otra instancia con alguna implementación.

El fragmento de código a continuación muestra cómo implementar el patrón Strategy:

public enum EstrategiaEntregaPizza {
    EXPRESS {
        @Override
        public void entregar(Pizza pizza) {
            System.out.println("La pizza se entregará en modo express");
        }
    },
    NORMAL {
        @Override
        public void entregar(Pizza pizza) {
            System.out.println("La pizza se entregará en modo normal");
        }
    };

    public abstract void entregar(Pizza pizza);
}

Luego, agregamos el siguiente método a la clase Pizza:

public void entregar() {
    if (esEntregable()) {
        ConfiguracionSistemaEntregaPizza.obtenerInstancia().getEstrategiaEntrega()
          .entregar(this);
        this.setEstado(Pizza.EstadoPizza.ENTREGADO);
    }
}

@Test
public void dadoPedidoPizza_cuandoEntregado_entoncesPizzaSeEntregaYEstadoCambia() {
    Pizza pizza = new Pizza();
    pizza.setEstado(Pizza.EstadoPizza.LISTO);
    pizza.entregar();
    assertTrue(pizza.obtenerEstado() == Pizza.EstadoPizza.ENTREGADO);
}

8. Java 8 y Enums

Podemos reescribir la clase Pizza en Java 8 y ver cómo los métodos obtenerTodasLasPizzasNoEntregadas() y agruparPizzasPorEstado() se vuelven tan concisos con el uso de lambdas y las API de Stream:

public static List<Pizza> obtenerTodasLasPizzasNoEntregadas(List<Pizza> input) {
    return input.stream().filter(
      (s) -> !estadosPizzaEntregada.contains(s.obtenerEstado()))
        .collect(Collectors.toList());
}

public static EnumMap<EstadoPizza, List<Pizza>> 
  agruparPizzasPorEstado(List<Pizza> listaPizzas) {
    EnumMap<EstadoPizza, List<Pizza>> mapa = listaPizzas.stream().collect(
      Collectors.groupingBy(Pizza::obtenerEstado,
      () -> new EnumMap<>(EstadoPizza.class), Collectors.toList()));
    return mapa;
}

9. Representación JSON de Enum

Usando las librerias Jackson, es posible tener una representación JSON de los tipos enum como si fueran POJOs (Plain Old Java Object, es decir, los viejos y confiables objetos planos de Java). En el fragmento de código a continuación, veremos cómo podemos usar las anotaciones de Jackson para lo mismo:

@JsonFormat(shape = JsonFormat.Shape.OBJECT)
public enum EstadoPizza {
    ORDENADO (5) {
        @Override
        public boolean esOrdenado() {
            return true;
        }
    },
    LISTO (2) {
        @Override
        public boolean esListo() {
            return true;
        }
    },
    ENTREGADO (0) {
        @Override
        public boolean esEntregado() {
            return true;
        }
    };

    private int tiempoEntrega;

    public boolean esOrdenado() {return false;}

    public boolean esListo() {return false;}

    public boolean esEntregado(){return false;}

    @JsonProperty("tiempoEntrega")
    public int obtenerTiempoEntrega() {
        return tiempoEntrega;
    }

    private EstadoPizza (int tiempoEntrega) {
        this.tiempoEntrega = tiempoEntrega;
    }
}

Podemos usar la clase Pizza y EstadoPizza de la siguiente manera:

```java
Pizza pizza = new Pizza();
pizza.setEstado(Pizza.EstadoPizza.LISTO);
System.out.println(Pizza.getJsonString(pizza));

Esto generará la siguiente representación JSON del estado de las pizzas:

{
  "estado" : {
    "tiempoEntrega" : 2,
    "listo" : true,
    "ordenado" : false,
    "entregado" : false
  },
  "entregable" : true
}

Para obtener más información sobre Jackson, puedes consultar su documentación.

10. Conclusión

En este artículo, exploramos el enum de Java, desde los conceptos básicos del lenguaje hasta casos de uso del mundo real más avanzados e interesantes.

1. Introducción

La sobrecarga y sobrescritura de métodos son conceptos clave del lenguaje de programación Java, y como tales, merecen un análisis en profundidad.

En este artículo, aprenderemos los conceptos básicos de estos conceptos y veremos en qué situaciones pueden ser útiles.

2. Sobrecarga de Métodos

La sobrecarga de métodos (overload) es un mecanismo poderoso que nos permite definir API de clases cohesivas. Para comprender mejor por qué la sobrecarga de métodos es una característica tan valiosa, veamos un ejemplo simple.

Supongamos que hemos escrito una clase de utilidad ingenua que implementa diferentes métodos para multiplicar dos números, tres números, y así sucesivamente.

Si hemos dado a los métodos nombres confusos o ambiguos, como multiplicar2(), multiplicar3(), multiplicar4(), entonces esa sería una API de clase mal diseñada. Aquí es donde entra en juego la sobrecarga de métodos.

En pocas palabras, podemos implementar la sobrecarga de métodos de dos maneras diferentes:

• implementando dos o más métodos que tienen el mismo nombre pero toman un número diferente de argumentos
• implementando dos o más métodos que tienen el mismo nombre pero toman argumentos de diferentes tipos

2.1. Número de Argumentos Diferentes

La clase Multiplicador muestra, en pocas palabras, cómo sobrecargar el método multiplicar() simplemente definiendo dos implementaciones que toman un número diferente de argumentos:

public class Multiplicador {
    
    public int multiplicar(int a, int b) {
        return a * b;
    }
    
    public int multiplicar(int a, int b, int c) {
        return a * b * c;
    }
}

2.2. Argumentos de Tipos Diferentes

De manera similar, podemos sobrecargar el método multiplicar() haciendo que acepte argumentos de diferentes tipos:

public class Multiplicador {
    
    public int multiplicar(int a, int b) {
        return a * b;
    }
    
    public double multiplicar(double a, double b) {
        return a * b;
    }
}

Además, es legítimo definir la clase Multiplicador con ambos tipos de sobrecarga de métodos:

public class Multiplicador {
    
    public int multiplicar(int a, int b) {
        return a * b;
    }
    
    public int multiplicar(int a, int b, int c) {
        return a * b * c;
    }
    
    public double multiplicar(double a, double b) {
        return a * b;
    }

Es importante destacar, sin embargo, que no es posible tener dos implementaciones de métodos que difieran solo en sus tipos de retorno.

Para entender por qué, consideremos el siguiente ejemplo:

public int multiplicar(int a, int b) { 
    return a * b; 
}
 
public double multiplicar(int a, int b) { 
    return a * b; 
}

En este caso, el código simplemente no se compilaría debido a la ambigüedad en la llamada al método: el compilador no sabría qué implementación de multiplicar() llamar.

2.3. Promoción de Tipos

Una característica interesante proporcionada por la sobrecarga de métodos es la llamada promoción de tipos.

En términos simples, un tipo dado se promociona implícitamente a otro cuando no hay coincidencia entre los tipos de los argumentos pasados al método sobrecargado y una implementación específica del método.

Para comprender con más claridad cómo funciona la promoción de tipos, consideremos las siguientes implementaciones del método multiplicar():

public double multiplicar(int a, long b) {
    return a * b;
}

public int multiplicar(int a, int b, int c) {
    return a * b * c;

Ahora, llamar al método con dos argumentos de tipo int resultará en que el segundo argumento se promocione a long, ya que en este caso no hay una implementación coincidente del método con dos argumentos de tipo int.

Veamos una prueba unitaria rápida para demostrar la promoción de tipos:

@Test
public void cuandoLlamamosMultiplicarSinCoincidir_entoncesPromocionamosTipo() {
    assertThat(multiplicador.multiplicar(10, 10)).isEqualTo(100.0);
}

Por otro lado, si llamamos al método con una implementación coincidente, la promoción de tipos simplemente no tiene lugar:

@Test
public void cuandoLlamamosMultiplicarCoincidiendo_entoncesNoPromocionamosTipo() {
    assertThat(multiplicador.multiplicar(10, 10, 10)).isEqualTo(1000);
}

Aquí tienes un resumen de las reglas de promoción de tipos que se aplican a la sobrecarga de métodos:

• byte se puede promocionar a short, int, long, float o double
• short se puede promocionar a int, long, float o double
• char se puede promocionar a int, long, float o double
• int se puede promocionar a long, float o double
• long se puede promocionar a float o double
• float se puede promocionar a double

2.4. Vinculación Estática

La capacidad de asociar una llamada de método específica al cuerpo del método se conoce como vinculación.

En el caso de la sobrecarga de métodos, la vinculación se realiza estáticamente en tiempo de compilación, por lo que se llama vinculación estática.

El compilador puede establecer eficazmente la vinculación en tiempo de compilación simplemente comprobando las firmas de los métodos.

3. Sobrescritura de Métodos

La sobrescritura de métodos (override) nos permite proporcionar implementaciones detalladas en las subclases para los métodos definidos en una clase base.

Si bien la sobrescritura de métodos es una característica poderosa, considerando que es una consecuencia lógica del uso de la herencia, uno de los pilares más importantes de la POO, cuándo y dónde utilizarla debe analizarse cuidadosamente, caso por caso.

Veamos ahora cómo utilizar la sobrescritura de métodos creando una relación simple de herencia ("es-un").

Aquí está la clase base:

public class Vehiculo {
    
    public String acelerar(long mph) {
        return "El vehículo acelera a: " + mph + " MPH.";
    }
    
    public String detener() {
        return "El vehículo se ha detenido.";
    }
    
    public String correr() {
        return "El vehículo está en movimiento.";
    }
}

Y aquí hay una subclase creada de manera forzada:

public class Coche extends Vehiculo {

    @Override
    public String acelerar(long mph) {
        return "El coche acelera a: " + mph + " MPH.";
    }
}

En la jerarquía anterior, simplemente hemos sobrescrito el método acelerar() para proporcionar una implementación más refinada para el subtipo Coche.

Aquí, queda claro que si una aplicación utiliza instancias de la clase Vehículo, también puede trabajar con instancias de Coche, ya que ambas implementaciones del método acelerar() tienen la misma firma y el mismo tipo de retorno.

Escribamos algunas pruebas unitarias para comprobar las clases Vehículo y Coche:

@Test
public void cuandoLlamamosAcelerar_entoncesComprobamos() {
    assertThat(vehiculo.acelerar(100))
      .isEqualTo("El vehículo acelera a: 100 MPH.");
}
    
@Test
public void cuandoLlamamosCorrer_entoncesComprobamos() {
    assertThat(vehiculo.correr())
      .isEqualTo("El vehículo está en movimiento.");
}
    
@Test
public void cuandoLlamamosDetener_entoncesComprobamos() {
    assertThat(vehiculo.detener())
      .isEqualTo("El vehículo se ha detenido.");
}

@Test
public void cuandoLlamamosAcelerar_entoncesComprobamos() {
    assertThat(coche.acelerar(80))
      .isEqualTo("El coche acelera a: 80 MPH.");
}
    
@Test
public void cuandoLlamamosCorrer_entoncesComprobamos() {
    assertThat(coche.correr())
      .isEqualTo("El vehículo está en movimiento.");
}
    
@Test
public void cuandoLlamamosDetener_entoncesComprobamos() {
    assertThat(coche.detener())
      .isEqualTo("El vehículo se ha detenido.");
}

Ahora, veamos algunas pruebas unitarias que muestran cómo los métodos correr() y detener(), que no se han sobrescrito, devuelven valores iguales tanto para Coche como para Vehículo:

@Test
public void dadasInstanciasVehiculoCoche_cuandoLlamamosCorrer_entoncesSonIguales() {
    assertThat(vehiculo.correr()).isEqualTo(coche.correr());
}
 
@Test
public void dadasInstanciasVehiculoCoche_cuandoLlamamosDetener_entoncesSonIguales() {
   assertThat(vehiculo.detener()).isEqualTo(coche.detener());
}

En nuestro caso, tenemos acceso al código fuente de ambas clases, por lo que podemos ver claramente que llamar al método acelerar() en una instancia base de Vehículo y llamar a acelerar() en una instancia de Coche devolverá valores diferentes para el mismo argumento.

Por lo tanto, la siguiente prueba demuestra que el método sobrescrito se invoca para una instancia de Coche:

@Test
public void cuandoLlamamosAcelerarConElMismoArgumento_entoncesNoSonIguales() {
    assertThat(vehiculo.acelerar(100))
      .isNotEqualTo(coche.acelerar(100));
}

3.1. Substitución de Tipos

Un principio fundamental en la POO es el de la substitución de tipos, que está estrechamente relacionado con el Principio de Substitución de Liskov (LSP).

En pocas palabras, el LSP establece que si una aplicación trabaja con un tipo base dado, también debería funcionar con cualquiera de sus subtipos. De esta manera, se conserva adecuadamente la substitución de tipos.

El mayor problema con la sobrescritura de métodos es que algunas implementaciones específicas de métodos en las clases derivadas podrían no adherirse completamente al LSP y, por lo tanto, no conservar la substitución de tipos.

Por supuesto, es válido hacer que un método sobrescrito acepte argumentos de diferentes tipos y devuelva un tipo diferente, pero con plena adherencia a estas reglas:

• Si un método en la clase base toma argumento(s) de un tipo dado, el método sobrescrito debería tomar el mismo tipo o un supertipo (también conocido como argumentos contravariantes).
• Si un método en la clase base devuelve void, el método sobrescrito debería devolver void.
• Si un método en la clase base devuelve un primitivo, el método sobrescrito debería devolver el mismo primitivo.
• Si un método en la clase base devuelve un cierto tipo, el método sobrescrito debería devolver el mismo tipo o un subtipo (también conocido como tipo de retorno covariante).
• Si un método en la clase base lanza una excepción, el método sobrescrito debe lanzar la misma excepción o un subtipo de la excepción de la clase base.

3.2. Vinculación Dinámica

Dado que la sobrescritura de métodos solo se puede implementar con la herencia, donde hay una jerarquía de un tipo base y subtipos, el compilador no puede determinar en tiempo de compilación qué método llamar, ya que tanto la clase base como las subclases definen los mismos métodos.

Como consecuencia, el compilador necesita verificar el tipo de objeto para saber qué método debe ser invocado.

Dado que esta verificación ocurre en tiempo de ejecución, la sobrescritura de métodos es un ejemplo típico de vinculación dinámica.

4. Conclusión

En este tutorial, aprendimos cómo implementar la sobrecarga de métodos y la sobrescritura de métodos, y exploramos algunas situaciones típicas en las que son útiles.

1. Introducción

En este breve tutorial, echaremos un vistazo a la palabra clave super en Java.

En pocas palabras, podemos usar la palabra clave super para acceder a la clase padre.

Exploremos las aplicaciones de esta palabra clave fundamental en el lenguaje.

2. La Palabra Clave super con Constructores

Podemos usar super() para llamar al constructor por defecto de la clase padre. Debe ser la primera declaración en un constructor.

En nuestro ejemplo, usamos super(mensaje) con el argumento de tipo String:

public class SubClase extends SuperClase {

    public SubClase(String mensaje) {
        super(mensaje);
    }
}

Creemos una instancia de la clase hija y veamos lo que sucede detrás:

SubClase hijo = new SubClase("mensaje desde la clase hija");

La palabra clave new invoca el constructor de SubClase, que a su vez llama primero al constructor de la clase padre y le pasa el argumento de tipo String.

3. Acceso a Variables de la Clase Padre

Creemos una clase padre con la variable de instancia mensaje:

public class SuperClase {
    String mensaje = "clase super";

    // constructor por defecto

    public SuperClase(String mensaje) {
        this.mensaje = mensaje;
    }
}

Ahora, creemos una clase hija con una variable del mismo nombre:

public class SubClase extends SuperClase {

    String mensaje = "clase hija";

    public void obtenerMensajePadre() {
        System.out.println(super.mensaje);
    }
}

Podemos acceder a la variable de la clase padre desde la clase hija utilizando la palabra clave super.

4. La Palabra Clave 'super' con la Sobrescritura de Métodos

En la siguiente lección, hablaremos sobre la sobrescritura de métodos y entraremos en más detalle. Por el momento, veamos este ejemplo:

Agreguemos un método de instancia a nuestra clase padre:

public class SuperClase {

    String mensaje = "clase super";

    public void imprimirMensaje() {
        System.out.println(mensaje);
    }
}

Y sobrescribamos el método imprimirMensaje() en nuestra clase hija:

public class SubClase extends SuperClase {

    String mensaje = "clase hija";

    public SubClase() {
        super.imprimirMensaje();
        imprimirMensaje();
    }

    public void imprimirMensaje() {
        System.out.println(mensaje);
    }
}

Podemos usar super para acceder al método sobrescrito desde la clase hija. super.imprimirMensaje() en el constructor llama al método de la clase padre de SuperClase.

5. Conclusión

En este artículo, hemos explorado la palabra clave super en más profundidad.

1. Introducción

En este tutorial, echaremos un vistazo a la palabra clave this en Java.

En Java, la palabra clave this es una referencia al objeto actual cuyo método se está llamando.

Exploraremos cómo y cuándo podemos usar esta palabra clave.

2. Desambiguación de Sombreado de Campos

La palabra clave this es útil para desambiguar y diferenciar las variables de instancia de los parámetros locales. La razón más común es cuando tenemos parámetros de constructor con el mismo nombre que los campos de instancia:

public class PruebaPalabraClave {

    private String nombre;
    private int edad;
    
    public PruebaPalabraClave(String nombre, int edad) {
        this.nombre = nombre;
        this.edad = edad;
    }
}

Como podemos ver aquí, estamos usando this con los campos nombre y edad de instancia para distinguirlos de los parámetros.

Otro uso es utilizar this con el ocultamiento o sombreado de parámetros en el ámbito local.

3. Referencia a Constructores de la Misma Clase

Desde un constructor, podemos usar this() para llamar a un constructor diferente de la misma clase. Aquí, usamos this() para la concatenación de constructores y reducir el uso de código.

El caso de uso más común es llamar a un constructor por defecto desde un constructor parametrizado:

public PruebaPalabraClave(String nombre, int edad) {
    this();
    
    // el resto del código
}

O podemos llamar al constructor parametrizado desde el constructor sin argumentos y pasar algunos argumentos:

public PruebaPalabraClave() {
    this("Manu", 31);
}

Ten en cuenta que this() debe ser la primera declaración en el constructor, de lo contrario, se producirá un error de compilación.

4. Pasar this como Parámetro

Aquí tenemos el método imprimirInstancia(), donde se define el argumento thisPalabraClave:

public PruebaPalabraClave() {
    imprimirInstancia(this);
}

public void imprimirInstancia(PruebaPalabraClave thisPalabraClave) {
    System.out.println(thisPalabraClave);
}

Dentro del constructor, invocamos el método imprimirInstancia(). Con this, pasamos una referencia a la instancia actual.

5. Devolver this

También podemos usar la palabra clave this para devolver la instancia de la clase actual desde el método.

Aquí tienes un ejemplo práctico completo de cómo se implementa en el patrón de diseño constructor (builder). Este ejemplo tiene solo una clase, CuentaBancaria, que contiene un constructor como una clase interna static:

public class CuentaBancaria {
    
    private String nombre;
    private String numeroCuenta;
    private String correoElectronico;
    private boolean boletín;

    // constructores/getters
    
    public static class BuilderCuentaBancaria {
        // código del builder
    }
}

Observa que todos los modificadores de acceso en los campos se declaran como private, ya que no queremos que los objetos externos accedan a ellos directamente.

El constructor también es private para que solo el Builder asignado a esta clase pueda acceder a él. Todas las propiedades establecidas en el constructor se extraen del objeto constructor que proporcionamos como argumento.

Hemos definido BuilderCuentaBancaria en una clase interna static:

public static class BuilderCuentaBancaria {
    
    private String nombre;
    private String numeroCuenta;
    private String correoElectronico;
    private boolean boletin;
    
    public BuilderCuentaBancaria(String nombre, String numeroCuenta) {
        this.nombre = nombre;
        this.numeroCuenta = numeroCuenta;
    }

    public BuilderCuentaBancaria conCorreoElectronico(String correoElectronico) {
        this.correoElectronico = correoElectronico;
        return this;
    }

    public BuilderCuentaBancaria desearBoletin(boolean boletin) {
        this.boletin = boletin;
        return this;
    }
    
    public CuentaBancaria construir() {
        return new CuentaBancaria(this);
    }
}

Observa que hemos declarado el mismo conjunto de campos que contiene la clase externa. Cualquier campo obligatorio se requiere como argumentos para el constructor de la clase interna, mientras que los campos opcionales restantes se pueden especificar mediante los métodos establecedores.

Esta implementación también admite el enfoque de diseño fluido al hacer que los métodos establecedores devuelvan el objeto builder.

Finalmente, el método de construcción llama al constructor privado de la clase externa y se pasa a sí mismo como argumento. La CuentaBancaria devuelta se instanciará con los parámetros establecidos por el BuilderCuentaBancaria.

Veamos un ejemplo rápido del patrón builder en acción:

CuentaBancaria nuevaCuenta = new CuentaBancaria
  .BuilderCuentaBancaria("Toni", "55318560231")
  .conCorreoElectronico("toni@montana.com")
  .desearBoletin(true)
  .construir();

6. La Palabra Clave this Dentro de la Clase Interna

También usamos 'this' para acceder a la instancia de la clase externa desde dentro de la clase interna:

public class PruebaPalabraClave {

    private String nombre;

    class EstaClaseInterna {

        boolean esClaseInterna = true;

        public EstaClaseInterna() {
            PruebaPalabraClave thisPalabraClave = PruebaPalabraClave.this;
            String cadenaExterna = PruebaPalabraClave.this.nombre;
        }
    }
}

Aquí, dentro del constructor, podemos obtener una referencia a la instancia de PruebaPalabraClave con la llamada a PruebaPalabraClave.this. Incluso podemos acceder a las variables de instancia como el campo PruebaPalabraClave.this.nombre.

7. Conclusión

En este artículo, hemos explorado la palabra clave this en Java en profundidad.

1. Introducción

Herencia y composición, junto con abstracción, encapsulación y polimorfismo, son fundamentos de la programación orientada a objetos (POO, o en inglés, OOP).

En este tutorial, cubriremos los conceptos básicos de herencia y composición, y nos centraremos en identificar las diferencias entre los dos tipos de relaciones.

2. Conceptos Básicos de la Herencia

La herencia es un mecanismo poderoso pero a menudo sobrecargado y mal utilizado.

En pocas palabras, con la herencia, una clase base (también conocida como tipo base) define el estado y el comportamiento común para un tipo dado y permite que las subclases (también conocidas como subtipos) proporcionen versiones especializadas de ese estado y comportamiento.

Para tener una idea clara de cómo trabajar con la herencia, creemos un ejemplo ingenuo: una clase base Persona que define los campos y métodos comunes para una persona, mientras que las subclases Camarera y Actriz proporcionan implementaciones adicionales y detalladas de métodos.

Aquí está la clase Persona:

public class Persona {
    private final String nombre;

    // otros campos, constructores estándar, getters

Y estas son las subclases:

public class Camarera extends Persona {

    public String servirEntrada(String tapa) {
        return "Sirviendo una ración de " + tapa;
    }

    // métodos/constructores adicionales
}

public class Actriz extends Persona {

    public String leerGuión(String película) {
        return "Leyendo el guión de " + película;
    }

    // métodos/constructores adicionales

Además, creemos una prueba unitaria para verificar que las instancias de las clases Camarera y Actriz también son instancias de Persona, demostrando así que se cumple la condición "es-un" a nivel de tipo:

@Test
public void dadaInstanciaCamarera_cuandoComprobamosTipo_entoncesEsInstanciaDePersona() {
    assertThat(new Camarera("María", "maria@dominio.com", 24))
        .isInstanceOf(Persona.class);
}

@Test
public void dadaInstanciaActriz_cuandoComprobamosTipo_entoncesEsInstanciaDePersona() {
    assertThat(new Actriz("Cristina", "cristina@dominio.com", 35))
        .isInstanceOf(Persona.class);
}

Es importante destacar aquí el aspecto semántico de la herencia. Además de reutilizar la implementación de la clase Persona, hemos creado una relación "es-un" bien definida entre el tipo base Persona y los subtipos Camarera y Actriz. Las camareras y actrices son, efectivamente, personas.

Esto puede llevarnos a preguntarnos: ¿en qué casos es apropiado utilizar la herencia?

Si los subtipos cumplen con la condición "es-un" y principalmente proporcionan funcionalidad aditiva más abajo en la jerarquía de clases, entonces la herencia es el camino a seguir.

Por supuesto, la sobrescritura de métodos está permitida siempre que los métodos sobrescritos preserven la sustituibilidad entre el tipo base y el subtipo promovida por el Principio de Sustitución de Liskov.

Además, debemos tener en cuenta que los subtipos heredan la API del tipo base, lo cual en algunos casos puede ser excesivo o simplemente indeseable.

De lo contrario, deberíamos usar composición en su lugar.

3. Herencia en Patrones de Diseño

Si bien el consenso es que debemos favorecer la composición sobre la herencia siempre que sea posible, existen algunos casos típicos en los que la herencia tiene su lugar.

3.1 El Patrón de Supertipo de Capa

En este caso, utilizamos la herencia para mover el código común a una clase base (el supertipo).

Aquí hay una implementación básica de este patrón en la capa de dominio:

public class Entidad {
    
    protected long id;
    
    // setters
}

public class Usuario extends Entidad {
    
    // campos y métodos adicionales   
}

Podemos aplicar el mismo enfoque a las otras capas del sistema, como las capas de servicio y persistencia.

3.2 El Patrón de Método de Plantilla

En el patrón de método de plantilla, podemos usar una clase base para definir las partes invariantes de un algoritmo y luego implementar las partes variantes en las subclases:

public abstract class ConstructorDeComputadora {
    
    public final Computadora construirComputadora() {
        agregarProcesador();
        agregarMemoria();
    }
    
    public abstract void agregarProcesador();
    
    public abstract void agregarMemoria();
}

public class ConstructorDeComputadoraEstandar extends ConstructorDeComputadora {

    @Override
    public void agregarProcesador() {
        // implementación del método
    }
    
    @Override
    public void agregarMemoria() {
        // implementación del método
    }
}

4. Conceptos Básicos de la Composición

La composición es otro mecanismo proporcionado por la POO para reutilizar la implementación.

En pocas palabras, la composición nos permite modelar objetos que están formados por otros objetos, definiendo así una relación "tiene-un" entre ellos.

Además, la composición es la forma más fuerte de asociación, lo que significa que los objetos que componen o están contenidos por un objeto se destruyen también cuando se destruye ese objeto.

Para comprender mejor cómo funciona la composición, supongamos que necesitamos trabajar con objetos que representan computadoras.

Una computadora está compuesta por diferentes componentes, como el microprocesador, la memoria, una tarjeta de sonido y más, por lo que podemos modelar tanto la computadora como cada uno de sus componentes como clases individuales.

Así es como podría verse una implementación simple de la clase Computadora:

public class Computadora {

    private Procesador procesador;
    private Memoria memoria;
    private TarjetaDeSonido tarjetaDeSonido;

    // getters/setters/constructores estándar
    
    public Optional<TarjetaDeSonido> getTarjetaDeSonido() {
        return Optional.ofNullable(tarjetaDeSonido);
    }
}

Las siguientes clases modelan un microprocesador, la memoria y una tarjeta de sonido (las interfaces se omiten por brevedad):

public class ProcesadorEstandar implements Procesador {

    private String modelo;
    
    // getters/setters estándar
}

public class MemoriaEstandar implements Memoria {
    
    private String marca;
    private String capacidad;
    
    // constructores estándar, getters, toString
}

public class TarjetaDeSonidoEstandar implements TarjetaDeSonido {
    
    private String marca;

    // constructores estándar, getters, toString
}

Es fácil entender las motivaciones detrás de dar prioridad a la composición sobre la herencia. En todos los escenarios en los que es posible establecer una relación semánticamente correcta de "tiene-un" entre una clase dada y otras, la composición es la elección correcta.

En el ejemplo anterior, Computadora cumple con la condición de "tiene-un" con las clases que modelan sus componentes.

También es importante señalar que en este caso, el objeto Computadora tiene la propiedad de los objetos contenidos solo si los objetos no se pueden reutilizar en otra Computadora. Si pueden, estaríamos utilizando agregación en lugar de composición, donde la propiedad no está implícita.

5. Composición Sin Abstracción

Alternativamente, podríamos haber definido la relación de composición codificando las dependencias de la clase Computadora en lugar de declararlas en el constructor:

public class Computadora {

    private ProcesadorEstandar procesador
        = new ProcesadorEstandar("Intel I3");
    private MemoriaEstandar memoria
        = new MemoriaEstandar("Kingston", "1TB");
    
    // campos/métodos adicionales
}

Por supuesto, esto sería un diseño rígido y fuertemente acoplado, ya que haríamos que la clase Computadora dependiera fuertemente de implementaciones específicas de Procesador y Memoria.

No estaríamos aprovechando el nivel de abstracción proporcionado por las interfaces y la inyección de dependencias.

Con el diseño inicial basado en interfaces, obtenemos un diseño con bajo acoplamiento, que también es más fácil de probar.

6. Conclusión

En este artículo, aprendimos los fundamentos de la herencia y la composición en Java, y exploramos en profundidad las diferencias entre los dos tipos de relaciones ("es-un" vs. "tiene-un").

1. Introducción

Uno de los principios fundamentales de la Programación Orientada a Objetos: la herencia, nos permite reutilizar código existente o extender un tipo de clase existente.

En pocas palabras, en Java, una clase puede heredar de otra clase y múltiples interfaces, mientras que una interfaz puede heredar de otras interfaces.

En este artículo, comenzaremos con la necesidad de la herencia, pasando a cómo funciona la herencia con clases e interfaces.

Luego, cubriremos cómo los nombres de variables/métodos y los modificadores de acceso afectan a los miembros que se heredan.

Y al final, veremos qué significa heredar un tipo.

2. La Necesidad de la Herencia

Imagina, como fabricante de coches, que ofreces múltiples modelos de coches a tus clientes. Aunque diferentes modelos de coches pueden ofrecer diferentes características como un techo corredizo o ventanas a prueba de balas, todos incluirían componentes y características comunes, como el motor y las ruedas.

Tiene sentido crear un diseño básico y extenderlo para crear sus versiones especializadas, en lugar de diseñar cada modelo de coche por separado, desde cero.

De manera similar, con la herencia, podemos crear una clase con características y comportamientos básicos y crear sus versiones especializadas mediante la creación de clases que heredan esta clase base. De la misma manera, las interfaces pueden extender interfaces existentes.

Notaremos el uso de varios términos para referirse a un tipo que es heredado por otro tipo, específicamente:

• un tipo base también se llama tipo super o padre
• un tipo derivado se denomina tipo extendido, subtipo o hijo

3. Herencia de Clase

3.1. Extender una Clase

Una clase puede heredar de otra clase y definir miembros adicionales.

Comencemos definiendo una clase base Coche:

public class Coche {
    int ruedas;
    String modelo;
    void arrancar() {
        // Verificar partes esenciales
    }
}

La clase CocheBlindado puede heredar los miembros de la clase Coche usando la palabra clave extends en su declaración:

public class CocheBlindado extends Coche {
    int ventanasAntibalas;
    void arrancarConControlRemoto() {
	// este vehículo se puede arrancar con un control remoto
    }
}

Ahora podemos decir que la clase CocheBlindado es una subclase de Coche, y esta última es una superclase de CocheBlindado.

Las clases en Java admiten herencia simple; la clase CocheBlindado no puede extender múltiples clases.

Además, ten en cuenta que en ausencia de una palabra clave extends, una clase hereda implícitamente la clase java.lang.Object.

Una subclase hereda los miembros protected y public no estáticos de la superclase. Además, los miembros con acceso default (package-private) se heredan si las dos clases están en el mismo paquete.

Por otro lado, los miembros private y static de una clase no se heredan.

3.2. Acceso a Miembros Padre desde una Clase Hija

Para acceder a propiedades o métodos heredados, simplemente podemos usarlos directamente:

public class CocheBlindado extends Coche {
    public String registrarModelo() {
        return modelo;
    }

Ten en cuenta que no necesitamos una referencia a la superclase para acceder a sus miembros.

4. Herencia de Interfaz

4.1. Implementar Múltiples Interfaces

Aunque las clases pueden heredar solo de una clase, pueden implementar múltiples interfaces.

Imagina que el CocheBlindado que definimos en la sección anterior es necesario para un superespía. Entonces, la compañía fabricante de coches pensó en agregar funcionalidades de vuelo y flotación:

public interface Flotable {
    void flotarEnAgua();
}

public interface Volable {
    void volar();
}

public class CocheBlindado extends Coche implements Flotable, Volable {
    public void flotarEnAgua() {
        System.out.println("¡Puedo flotar!");
    }

    public void volar() {
        System.out.println("¡Puedo volar!");
    }
}

En el ejemplo anterior, notamos el uso de la palabra clave implements para heredar de una interfaz.

4.2. Problemas con la Herencia Múltiple

Java permite la herencia múltiple mediante interfaces.

Hasta Java 7, esto no era un problema. Las interfaces solo podían definir métodos abstract, es decir, métodos sin ninguna implementación. Entonces, si una clase implementaba múltiples interfaces con la misma firma de método, no era un problema. La clase que implementaba finalmente solo tenía un método que implementar.

Veamos cómo esta ecuación simple cambió con la introducción de métodos default en las interfaces con Java 8.

A partir de Java 8, las interfaces podían optar por definir implementaciones default para sus métodos (una interfaz todavía puede definir métodos abstract). Esto significa que si una clase implementa múltiples interfaces que definen métodos con la misma firma, la clase hija heredaría implementaciones separadas. Esto suena complejo y no está permitido.

Java no permite la herencia de múltiples implementaciones de los mismos métodos definidos en interfaces separadas.

Aquí tienes un ejemplo:

public interface Flotable {
    default void reparar() {
    	System.out.println("Reparando objeto flotante");	
    }
}

public interface Volable {
    default void reparar() {
    	System.out.println("Reparando objeto volador");	
    }
}

public class CocheBlindado extends Coche implements Flotable, Volable {
    // esto no se compilará
}

Si deseamos implementar ambas interfaces, tendremos que sobrescribir el método reparar.

Si las interfaces en los ejemplos anteriores definen variables con el mismo nombre, por ejemplo, duracion, no podemos acceder a ellas sin preceder el nombre de la variable con el nombre de la interfaz:

public interface Flotable {
    int duracion = 10;
}

public interface Volable {
    int duracion = 20;
}

public class CocheBlindado extends Coche implements Flotable, Volable {
 
    public void unMetodo() {
    	System.out.println(duracion); // no se compilará
    	System.out.println(Flotable.duracion); // muestra 10
    	System.out.println(Volable.duracion); // muestra 20
    }
}

4.3. Interfaces que Extienden Otras Interfaces

Una interfaz puede extender múltiples interfaces. Aquí tienes un ejemplo:

public interface Flotable {
    void flotarEnAgua();
}

interface Volable {
    void volar();
}

public interface NaveEspacial extends Flotable, Volable {
    void controlRemoto();
}

Una interfaz hereda otras interfaces usando la palabra clave extends. Las clases usan la palabra clave implements para heredar una interfaz.

5. Heredar Tipo

Cuando una clase hereda de otra clase o interfaces, además de heredar sus miembros, también hereda su tipo. Esto también se aplica a una interfaz que hereda otras interfaces.

Este es un concepto muy poderoso que permite a los desarrolladores programar a una interfaz (clase base o interfaz), en lugar de programar a sus implementaciones.

Por ejemplo, imagina una situación en la que una organización mantiene una lista de los coches propiedad de sus empleados. Por supuesto, todos los empleados pueden poseer diferentes modelos de coches. Entonces, ¿cómo podemos referirnos a diferentes instancias de coches? Aquí está la solución:

public class Empleado {
    private String nombre;
    private Coche coche;
    
    // constructor estándar
}

Dado que todas las clases derivadas de Coche heredan el tipo Coche, las instancias de clases derivadas se pueden referir mediante una variable de tipo Coche:

Empleado e1 = new Empleado("Toni", new CocheBlindado());
Empleado e2 = new Empleado("Paco", new CocheDeCarreras());
Empleado e3 = new Empleado("Rubén", new Ferrari());

6. Miembros Ocultos de la Clase

6.1. Miembros de Instancia Ocultos

¿Qué sucede si tanto la superclase como la subclase definen una variable o método con el mismo nombre? No te preocupes, aún podemos acceder a ambos. Sin embargo, debemos hacer nuestro intento claro para Java, prefijando la variable o el método con las palabras clave this o super.

La palabra clave this se refiere a la instancia en la que se utiliza. La palabra clave super se refiere a la instancia de la clase padre:

public class CocheBlindado extends Coche {
    private String modelo;
    public String obtenerUnValor() {
    	return super.modelo;   // devuelve el valor de modelo definido en la clase base Coche
    	// return this.modelo;   // devolverá el valor de modelo definido en CocheBlindado
    	// return modelo;   // devolverá el valor de modelo definido en CocheBlindado
    }
}

Muchos desarrolladores usan las palabras clave this y super para indicar explícitamente a qué variable o método se refieren. Sin embargo, usarlas con todos los miembros puede hacer que nuestro código parezca desordenado.

6.2. Miembros static Ocultos

¿Qué sucede cuando nuestra clase base y las subclases definen variables y métodos estáticos con el mismo nombre? ¿Podemos acceder a un miembro static desde la clase base en la clase derivada, de la misma manera en que lo hacemos para las variables de instancia?

Averigüémoslo usando un ejemplo:

public class Coche {
    public static String mensaje() {
        return "Coche";
    }
}

public class CocheBlindado extends Coche {
    public static String mensaje() {
        return super.mensaje(); // esto no se compilará.
    }
}

No, no podemos. Los miembros estáticos pertenecen a una clase y no a las instancias. Entonces no podemos usar la palabra clave super no estática en mensaje().

Dado que los miembros estáticos pertenecen a una clase, podemos modificar la llamada anterior de la siguiente manera:

return Coche.mensaje();

Considera el siguiente ejemplo en el que tanto la clase base como la clase derivada definen un método static mensaje() con la misma firma:

public class Coche {
    public static String mensaje() {
        return "Coche";
    }
}

public class CocheBlindado extends Coche {
    public static String mensaje() {
        return "CocheBlindado";
    }
}

Así es como podemos llamarlos:

Coche primero = new CocheBlindado();
CocheBlindado segundo = new CocheBlindado();

Para el código anterior, primero.mensaje() mostrará Coche y segundo.mensaje() mostrará CocheBlindado. El mensaje estático que se llama depende del tipo de variable utilizada para referirse a la instancia de CocheBlindado.

7. Conclusión

En este artículo, cubrimos un aspecto fundamental del lenguaje Java: la herencia.

Vimos cómo Java admite la herencia simple con clases y la herencia múltiple con interfaces, y discutimos las complejidades de cómo funciona este mecanismo en el lenguaje.

1. Introducción

En este tutorial, vamos a hablar sobre las interfaces en Java. También veremos cómo Java las utiliza para implementar polimorfismo y la herencia múltiple.

2. ¿Qué Son las Interfaces en Java?

En Java, una interfaz es un tipo abstracto que contiene una colección de métodos y variables constantes. Es uno de los conceptos fundamentales en Java y se utiliza para lograr la abstracción, polimorfismo y la herencia múltiple.

Veamos un ejemplo simple de una interfaz en Java:

public interface Electronico {

    // Variable constante
    String LED = "LED";

    // Método abstracto
    int getConsumoDeElectricidad();

    // Método estático
    static boolean esEficienteDesdeElPuntoDeVistaEnergetico(String tipoElectronico) {
        if (tipoElectronico.equals(LED)) {
            return true;
        }
        return false;
    }

    // Método predeterminado
    default void imprimirDescripcion() {
        System.out.println("Descripción Electrónica");
    }
}

Podemos implementar una interfaz en una clase Java utilizando la palabra clave implements.

A continuación, creemos también una clase Computadora que implemente la interfaz Electronico que acabamos de crear:

public class Computadora implements Electronico {

    @Override
    public int getConsumoDeElectricidad() {
        return 1000;
    }
}

2.1 Reglas para Crear Interfaces

En una interfaz, se nos permite usar:

• Variables constantes
• Métodos abstract
• Métodos static
• Métodos default

También debemos recordar que:

• No podemos instanciar interfaces directamente.
• Una interfaz puede estar vacía, sin métodos ni variables.
• No podemos usar la palabra clave final en la definición de la interfaz, ya que dará como resultado un error de compilación.
• Todas las declaraciones de interfaz deben tener el modificador de acceso public o default; el modificador abstract se agregará automáticamente por el compilador.
• Un método de interfaz no puede ser protected o final.
• Hasta Java 9, los métodos de interfaz no podían ser privados; sin embargo, Java 9 introdujo la posibilidad de definir métodos privados en interfaces.
• Las variables de interfaz son public, static y final por definición; no se nos permite cambiar su visibilidad.

3. ¿Qué Podemos Lograr Usándolas?

3.1 Funcionalidad de Comportamiento

Utilizamos interfaces para agregar cierta funcionalidad de comportamiento que puede ser utilizada por clases no relacionadas. Por ejemplo, Comparable, Comparator y Cloneable son interfaces de Java que pueden ser implementadas por clases no relacionadas. A continuación, se muestra un ejemplo de la interfaz Comparator que se utiliza para comparar dos instancias de la clase Empleado:

public class Empleado {

    private double salario;

    public double getSalario() {
        return salario;
    }

    public void setSalario(double salario) {
        this.salario = salario;
    }
}

public class ComparadorDeSalarioEmpleado implements Comparator<Empleado> {

    @Override
    public int compare(Empleado empleadoA, Empleado empleadoB) {
        if (empleadoA.getSalario() < empleadoB.getSalario()) {
            return -1;
        } else if (empleadoA.getSalario() > empleadoB.getSalario()) { 
            return 1;
        } else {
            return 0;
        }
    }
}

3.2 Herencia Múltiple

Las clases Java admiten la herencia singular. Sin embargo, mediante el uso de interfaces, también podemos implementar la herencia múltiple.

Por ejemplo, en el siguiente ejemplo, notamos que la clase Coche implementa las interfaces Volar y Transformar. Al hacerlo, hereda los métodos volar y transformar:

public interface Transformar {
    void transformar();
}

public interface Volar {
    void volar();
}

public class Coche implements Volar, Transformar {

    @Override
    public void volar() {
        System.out.println("¡Puedo Volar!");
    }

    @Override
    public void transformar() {
        System.out.println("¡Puedo Transformarme!");
    }
}

3.3 Polimorfismo

Comencemos haciendo la pregunta: ¿qué es el polimorfismo? Es la capacidad de un objeto para tomar diferentes formas durante la ejecución. Para ser más específicos, es la ejecución del método sobrescrito que está relacionado con un tipo de objeto específico en tiempo de ejecución.

En Java, podemos lograr el polimorfismo utilizando interfaces. Por ejemplo, la interfaz Forma puede tomar diferentes formas: puede ser un Circulo o un Cuadrado.

Comencemos definiendo la interfaz Forma:

public interface Forma {
    String nombre();
}

Ahora también creemos la clase Circulo:

public class Círculo implements Forma {

    @Override
    public String nombre() {
        return "Círculo";
    }
}

Y también la clase Cuadrado:

public class Cuadrado implements Forma {

    @Override
    public String nombre() {
        return "Cuadrado";
    }
}

Finalmente, es hora de ver el polimorfismo en acción utilizando nuestra interfaz Forma y sus implementaciones. Creemos algunas instancias de objetos Forma, agréguelas a una List y, finalmente, imprima sus nombres en un bucle:

List<Forma> formas = new ArrayList<>();
Forma formaCirculo =

 new Círculo();
Forma formaCuadrado = new Cuadrado();

formas.add(formaCirculo);
formas.add(formaCuadrado);

for (Forma forma : formas) {
    System.out.println(forma.nombre());
}

4. Métodos default en Interfaces

Las interfaces tradicionales en Java 7 y anteriores no ofrecen compatibilidad inversa.

Lo que esto significa es que si tienes código heredado escrito en Java 7 o anterior, y decides agregar un método abstract a una interfaz existente, entonces todas las clases que implementen esa interfaz deben sobrescribir el nuevo método abstract. De lo contrario, el código se romperá.

Java 8 resolvió este problema al introducir el método default, que es opcional y puede implementarse a nivel de la interfaz.

5. Reglas de Herencia de Interfaces

Para lograr la herencia múltiple a través de interfaces, debemos recordar algunas reglas. Veamos estas en detalle.

5.1 Interfaz que Extiende Otra Interfaz

Cuando una interfaz extiende (extends) otra interfaz, hereda todos los métodos abstractos de esa interfaz. Comencemos creando dos interfaces, TieneColor y Forma:

public interface TieneColor {
    String obtenerColor();
}

public interface Caja extends TieneColor {
    int obtenerAltura();
}

En el ejemplo anterior, Caja hereda de TieneColor utilizando la palabra clave extends. Al hacerlo, la interfaz Caja hereda obtenerColor. Como resultado, la interfaz Caja ahora tiene dos métodos: obtenerColor y obtenerAltura.

5.2 Clase Abstracta que Implementa una Interfaz

Cuando una clase abstracta implementa una interfaz, hereda todos sus métodos abstract y default. Consideremos la interfaz Transformar y la clase abstracta Vehículo que la implementa:

public interface Transformar {
    
    void transformar();

    default void imprimirEspecificaciones(){
        System.out.println("Especificaciones de Transformación");
    }
}

public abstract class Vehículo implements Transformar {}

En este ejemplo, la clase Vehículo hereda dos métodos: el método abstracto transformar y el método default imprimirEspecificaciones.

6. Interfaces Funcionales

Java ha tenido muchas interfaces funcionales desde sus primeros días, como Comparable (desde Java 1.2) y Runnable (desde Java 1.0).

Java 8 introdujo nuevas interfaces funcionales como Predicate, Consumer y Function. Para obtener más información sobre estas, visita nuestro tutorial sobre Interfaces Funcionales en Java 8 en futuras lecciones.

7. Conclusión

En este tutorial, ofrecimos una visión general de las interfaces en Java y hablamos sobre cómo usarlas para lograr polimorfismo y la herencia múltiple.

1. Introducción

Java 8 introdujo algunas características completamente nuevas, incluyendo expresiones lambda, interfaces funcionales, referencias de métodos, flujos, Optional y métodos static y default en interfaces.

Algunas de estas características las cubriremos en otros artículos. No obstante, los métodos static y default en interfaces merecen un análisis más profundo por sí mismos.

En este tutorial, aprenderemos cómo utilizar los métodos static y default en interfaces y discutiremos algunas situaciones en las que pueden ser útiles.

2. Por Qué las Interfaces Necesitan Métodos default

Al igual que los métodos regulares de las interfaces, los métodos default son implícitamente públicos; no es necesario especificar el modificador public.

A diferencia de los métodos regulares de las interfaces, los declaramos con la palabra clave default al principio de la firma del método y proporcionan una implementación.

Veamos un ejemplo sencillo:

public interface MiInterfaz {
    
    // métodos regulares de la interfaz
    
    default void metodoPredeterminado() {
        // implementación del método default
    }
}

La razón por la cual la versión Java 8 incluyó métodos default es bastante obvia.

En un diseño típico basado en abstracciones, donde una interfaz tiene una o múltiples implementaciones, si se agregan uno o más métodos a la interfaz, todas las implementaciones también se verán obligadas a implementarlos. De lo contrario, el diseño simplemente se romperá.

Los métodos default de las interfaces son una forma eficiente de abordar este problema. Nos permiten agregar nuevos métodos a una interfaz que están automáticamente disponibles en las implementaciones. Por lo tanto, no necesitamos modificar las clases que las implementan.

De esta manera, se conserva la compatibilidad hacia atrás sin tener que refactorizar los implementadores.

3. Métodos default de la Interfaz en Acción

Para comprender mejor la funcionalidad de los métodos default de la interfaz, creemos un ejemplo sencillo.

Supongamos que tenemos una interfaz Vehículo ingenua y solo una implementación. Podría haber más, pero mantengámoslo simple:

public interface Vehiculo {
    
    String obtenerMarca();
    
    String acelerar();
    
    String desacelerar();
    
    default String activarAlarma() {
        return "Activando la alarma del vehículo.";
    }
    
    default String desactivarAlarma() {
        return "Desactivando la alarma del vehículo.";
    }
}

Ahora escribamos la clase que implementa:

public class Coche implements Vehiculo {

    private String marca;
    
    // constructores/getters
    
    @Override
    public String obtenerMarca() {
        return marca;
    }
    
    @Override
    public String acelerar() {
        return "El coche está acelerando.";
    }
    
    @Override
    public String desacelerar() {
        return "El coche está desacelerando.";
    }
}

Finalmente, definamos una clase main típica, que crea una instancia de Coche y llama a sus métodos:

public static void main(String[] args) { 
    Vehiculo coche = new Coche("Aston Martin");
    System.out.println(coche.obtenerMarca());
    System.out.println(coche.acelerar());
    System.out.println(coche.desacelerar());
    System.out.println(coche.activarAlarma());
    System.out.println(coche.desactivarAlarma());
}

Por favor, ten en cuenta cómo los métodos default, activarAlarma() y desactivarAlarma(), de nuestra interfaz Vehiculo están automáticamente disponibles en la clase Coche.

Además, si en algún momento decidimos agregar más métodos default a la interfaz Vehiculo, la aplicación seguirá funcionando y no tendremos que obligar a la clase a proporcionar implementaciones para los nuevos métodos.

El uso más común de los métodos default de la interfaz es proporcionar incrementalmente funcionalidad adicional a un tipo dado sin descomponer las clases que la implementan.

Además, podemos usarlos para proporcionar funcionalidad adicional en torno a un método abstracto existente:

public interface Vehiculo {
    
    // métodos adicionales de la interfaz 
    
    double obtenerVelocidad();
    
    default double obtenerVelocidadEnKMH(double velocidad) {
       // conversión      
    }
}

4. Reglas de Herencia de Múltiples Interfaces

Los métodos default de la interfaz son una característica bastante buena, pero hay algunas advertencias que vale la pena mencionar. Dado que Java permite que las clases implementen múltiples interfaces, es importante saber qué sucede cuando una clase implementa varias interfaces que definen los mismos métodos default.

Para comprender mejor este escenario, definamos una nueva interfaz Alarma y refactoricemos la clase Coche:

public interface Alarma {

    default String activarAlarma() {
        return "Activando la alarma.";
    }
    
    default String desactivarAlarma() {
        return "Desactivando la alarma.";
    }
}

Con esta nueva interfaz que define su propio conjunto de métodos default, la clase Coche implementaría tanto Vehiculo como Alarma:

public class Coche implements Vehiculo, Alarma {
    // ...
}

En este caso, el código simplemente no se compilará, ya que hay un conflicto causado por la herencia de múltiples interfaces (también conocido como el Problema del Diamante). La clase Coche heredaría ambos conjuntos de métodos default. Entonces, ¿cuáles deberíamos llamar?

Para resolver esta ambigüedad, debemos proporcionar explícitamente una implementación para los métodos:

@Override
public String activarAlarma() {
    // implementación personalizada
}
    
@Override
public String desactivarAlarma() {
    // implementación personalizada
}

También podemos hacer que nuestra clase utilice los métodos default de una de las interfaces.

Veamos un ejemplo que utiliza los métodos default de la interfaz Vehiculo:

@Override
public String activarAlarma() {
    return Vehiculo.super.activarAlarma();
}

@Override
public String desactivarAlarma() {
    return Vehiculo.super.desactivarAlarma();
}

De manera similar, podemos hacer que la clase utilice los métodos default definidos dentro de la interfaz Alarma:

@Override
public String activarAlarma() {
    return Alarma.super.activarAlarma();
}

@Override
public String desactivarAlarma() {
    return Alarma.super.desactivarAlarma();
}

Incluso es posible hacer que la clase Coche utilice ambos conjuntos de métodos default:

@Override
public String activarAlarma() {
    return Vehiculo.super.activarAlarma() + " " + Alarma.super.activarAlarma();
}
    
@Override
public String desactivarAlarma() {
    return Vehiculo.super.desactivarAlarma() + " " + Alarma.super.desactivarAlarma();
}

5. Métodos static de la Interfaz

Además de declarar métodos default en las interfaces, Java 8 también nos permite definir e implementar métodos static en las interfaces.

Dado que los métodos static no pertenecen a un objeto en particular, no forman parte de la API de las clases que implementan la interfaz; por lo tanto, deben ser llamados usando el nombre de la interfaz precediendo el nombre del método.

Para comprender cómo funcionan los métodos static en las interfaces, refactoricemos la interfaz Vehiculo y agreguemos un método de utilidad static a ella:

public interface Vehiculo {
    
    // métodos regulares / predeterminados de la interfaz
    
    static int obtenerPotencia(int rpm, int torque) {
        return (rpm * torque) / 1337;
    }
}

Definir un método static dentro de una interfaz es idéntico a definirlo en una clase. Además, un método static puede ser invocado dentro de otros métodos static y default.

Supongamos que queremos calcular la potencia de un motor de un vehículo dado. Solo llamamos al método obtenerPotencia():

Vehiculo.obtenerPotencia(1000, 400));

La idea detrás de los métodos static de la interfaz es proporcionar un mecanismo simple que nos permita aumentar el grado de cohesión de un diseño reuniendo métodos relacionados en un solo lugar sin tener que crear un objeto.

Lo mismo se puede hacer con clases abstractas. La principal diferencia es que las clases abstractas pueden tener constructores, estado y comportamiento.

Además, los métodos static en las interfaces permiten agrupar métodos de utilidad relacionados sin tener que crear clases de utilidad artificiales que sean simplemente marcadores de posición para métodos static.

6. Conclusión

En este artículo, exploramos a fondo el uso de métodos static y default de la interfaz en Java 8. A primera vista, esta característica puede parecer un poco desordenada, especialmente desde la perspectiva de un purista orientado a objetos. Idealmente, las interfaces no deberían encapsular comportamiento, y solo deberíamos usarlas para definir la API pública de un cierto tipo.

Sin embargo, cuando se trata de mantener la compatibilidad hacia atrás con código existente, los métodos static y default son un buen compromiso.

1. Introducción

En este tutorial, exploraremos en detalle el modificador static del lenguaje Java.

Descubriremos cómo podemos aplicar la palabra clave static a variables, métodos, bloques y clases anidadas, y qué diferencia marca.

2. La Anatomía de la Palabra Clave static

En el lenguaje de programación Java, la palabra clave static significa que el miembro en particular pertenece a un tipo en sí mismo, en lugar de pertenecer a una instancia de ese tipo.

Esto significa que crearemos solo una instancia de ese miembro estático que se comparte entre todas las instancias de la clase.

Podemos aplicar la palabra clave a variables, métodos, bloques y clases anidadas.

3. Los Campos static (o Variables de Clase)

En Java, cuando declaramos un campo como static, se crea exactamente una copia de ese campo y se comparte entre todas las instancias de esa clase.

No importa cuántas veces instanciemos una clase. Siempre habrá una sola copia del campo static perteneciente a ella. El valor de este campo static se comparte entre todos los objetos de la misma clase.

Desde la perspectiva de la memoria, las variables estáticas se almacenan en la memoria heap.

3.1. Ejemplo del Campo static

Supongamos que tenemos una clase Coche con varios atributos (variables de instancia).

Cada vez que creamos nuevos objetos a partir de esta plantilla Coche, cada nuevo objeto tendrá su copia distintiva de estas variables de instancia.

Sin embargo, supongamos que queremos una variable que mantenga el conteo del número de objetos Coche instanciados y se comparta entre todas las instancias para que puedan acceder a ella e incrementarla al inicializarse.

Ahí es donde entran en juego las variables static:

public class Coche {
    private String nombre;
    private String motor;
    
    public static int cantidadDeCoches;
    
    public Coche(String nombre, String motor) {
        this.nombre = nombre;
        this.motor = motor;
        cantidadDeCoches++;
    }

    // getters y setters
}

Ahora, por cada objeto de esta clase que instanciemos, la misma copia de la variable cantidadDeCoches se incrementará.

Entonces, para este caso, esto será cierto:

@Test
public void cuandoSeInicializanObjetosDeCoche_LaCuentaEstaticaAumenta() {
    new Coche("Seat", "Panda");
    new Coche("Porsche", "Taycan");
 
    assertEquals(2, Coche.cantidadDeCoches);
}

3.2. Razones para Usar Campos static

Aquí hay algunas razones por las cuales querríamos usar campos static:

• Cuando el valor de la variable es independiente de los objetos.
• Cuando se supone que el valor debe ser compartido entre todos los objetos.

3.3. Puntos Clave a Recordar

Dado que las variables static pertenecen a una clase, podemos acceder a ellas directamente utilizando el nombre de la clase. Por lo tanto, no necesitamos ninguna referencia a un objeto.

Solo podemos declarar variables static a nivel de clase.

Podemos acceder a campos static sin inicializar un objeto.

Finalmente, podemos acceder a campos static utilizando una referencia a un objeto (como ford.cantidadDeCoches++). Pero debemos evitar esto porque se vuelve difícil determinar si es una variable de instancia o una variable de clase. En su lugar, siempre debemos referirnos a las variables static utilizando el nombre de la clase (Coche.cantidadDeCoches++).

4. Los Métodos static (o Métodos de Clase)

Al igual que con los campos static, los métodos static también pertenecen a una clase en lugar de a un objeto. Por lo tanto, podemos llamarlos sin crear un objeto de la clase en la que residen.

4.1. Ejemplo del Método static

Generalmente, usamos métodos static para realizar una operación que no depende de la creación de una instancia.

Para compartir código entre todas las instancias de esa clase, lo escribimos en un método static:

static void establecerCantidadDeCoches(int cantidadDeCoches) {
    Coche.cantidadDeCoches = cantidadDeCoches;
}

También comúnmente usamos métodos static para crear clases de utilidad o ayudantes para que podamos obtenerlos sin crear un nuevo objeto de esas clases.

Como ejemplos, podemos observar las clases de utilidad de Collections o Math en JDK, StringUtils de Apache o CollectionUtils del framework Spring y notar que todos sus métodos de utilidad son static.

4.2. Razones para Usar Métodos static

Echemos un vistazo a algunas razones por las que querríamos usar métodos static:

• Para acceder/manipular variables estáticas y otros métodos estáticos que no dependen de objetos.
• Los métodos static se usan ampliamente en clases de utilidad y ayudantes.

4.3. Puntos Clave a Recordar

Los métodos static en Java se resuelven en tiempo de compilación. Dado que la sobrescritura de métodos es parte del polimorfismo en tiempo de ejecución, los métodos static no pueden ser sobrescritos.

Los métodos abstractos no pueden ser static.

Los métodos static no pueden usar las palabras clave this o super.

Las siguientes combinaciones de métodos y variables de instancia y de clase son válidas:

• Los métodos de instancia pueden acceder directamente tanto a los métodos de instancia como a las variables de instancia.
• Los métodos de instancia también pueden acceder directamente a variables y métodos static.
• Los métodos static pueden acceder a todas las variables static y a otros métodos static.
• Los métodos static no pueden acceder directamente a variables de instancia y métodos de instancia. Necesitan alguna referencia de objeto para hacerlo.

4.4. Llamar a un Método No static en un Método static en Java

Para llamar a un método no estático en un método static, debemos usar una instancia de la clase que contiene el método no estático. Este es un caso de uso común al llamar a un método no estático en el método static main(), por ejemplo.

Consideremos un ejemplo de la clase Coche que presentamos anteriormente en este artículo y que define los siguientes métodos:

public String getNombre() {
    return nombre;
}

public String getMotor() {
    return motor;
}

public static String getInformacionDeCoches(Coche coche) {
    return coche.getNombre() + "-" + coche.getMotor();
}

Como podemos ver, estamos llamando a los métodos getNombre() y getMotor(), que son métodos no estáticos, en el método static getInformacionDeCoches(). Esto solo es posible porque usamos una instancia del objeto Coche para acceder a estos métodos. De lo contrario, obtendríamos este mensaje de error: "Non-static method ‘getNombre()’ cannot be referenced from a static context" ("Método no estático 'getNombre()' no puede ser referenciado desde un contexto estático").

5. Bloques static

Usamos un bloque static para inicializar variables static. Aunque podemos inicializar variables static directamente durante la declaración, hay situaciones en las que necesitamos realizar un procesamiento multilineal. En tales casos, los bloques static son útiles.

5.1. El Ejemplo del Bloque static

Por ejemplo, supongamos que queremos inicializar un objeto List con algunos valores predefinidos.

Esto se vuelve fácil con bloques static:

public class DemoBloqueEstatico {
    public static List<String> rangos = new LinkedList<>();

    static {
        rangos.add("Oro");
        rangos.add("Platino");
        rangos.add("Diamante");
    }
    
    static {
        rangos.add("Master");
        rangos.add("Grand Master");
    }
}

No sería posible inicializar un objeto List con todos los valores iniciales junto con la declaración. Por eso hemos utilizado el bloque static aquí.

5.2. Razones para Usar Bloques static

A continuación, algunas razones para usar bloques static:

• Si la inicialización de variables static requiere alguna lógica adicional aparte de la asignación.
• Si la inicialización de variables static propensas a errores y necesita manejo de excepciones.

5.3. Puntos Clave a Recordar

Una clase puede tener varios bloques static.

Los campos static y los bloques static se resuelven y ejecutan en el mismo orden en que están presentes en la clase.

6. Una Clase static

Java nos permite crear una clase dentro de otra clase. Proporciona una forma de agrupar elementos que solo utilizaremos en un solo lugar. Esto ayuda a mantener nuestro código más organizado y legible.

En general, la arquitectura de clases anidadas se divide en dos tipos:

• Las clases anidadas que declaramos como static se llaman clases anidadas static.
• Las clases anidadas que no son static se llaman clases internas.

La diferencia principal entre estas dos es que las clases internas tienen acceso a todos los miembros de la clase contenedora (incluidos los private), mientras que las clases anidadas static solo tienen acceso a miembros static de la clase externa.

De hecho, las clases anidadas static se comportan exactamente como cualquier otra clase de nivel superior, pero están contenidas en la única clase que las accederá, para proporcionar una mejor comodidad en el empaquetado.

6.1. Ejemplo de Clase static

El enfoque más ampliamente utilizado para crear objetos singleton es a través de una clase anidada static:

public class Singleton  {
    private Singleton() {}

    private static class SingletonHolder {
        public static final Singleton instancia = new Singleton();
    }

    public static Singleton obtenerInstancia() {
        return SingletonHolder.instancia;
    }
}

Usamos este método porque no requiere sincronización y es fácil de aprender e implementar.

Otro ejemplo de clase anidada static, donde se muestra la visibilidad entre los miembros de la clase principal y anidada, y viceversa:

public class Pizza {

    private static String cantidadCocinada;
    private boolean esMasaDelgada;

    public static class ContadorVentasDePizza {

        private static String cantidadOrdenada;
        public static String cantidadEntregada;

        ContadorVentasDePizza() {
            System.out.println("Campo estático de la clase contenedora es "
              + Pizza.cantidadCocinada);
            System.out.println("Campo no estático de la clase contenedora es "
              + new Pizza().esMasaDelgada);
        }
    }

    Pizza() {
        System.out.println("Campo no estático público de la clase estática es "
          + ContadorVentasDePizza.cantidadEntregada);
        System.out.println("Campo no estático privado de la clase estática es "
          + ContadorVentasDePizza.cantidadOrdenada);
    }

    public static void main(String[] a) {
        new Pizza.ContadorVentasDePizza();
    }
}

El resultado cuando ejecutamos el método principal es:

Campo estático de la clase contenedora es null
Campo no estático de la clase contenedora es false
Campo no estático público de la clase estática es null
Campo no estático privado de la clase estática es null

6.2. Razones para Usar una Clase static

Veamos algunas razones para usar clases anidadas static en nuestro código:

• Agrupar clases que solo se usarán en un lugar aumenta la encapsulación.
• Acercamos el código al único lugar que lo utilizará. Esto aumenta la legibilidad y facilita el mantenimiento.
• Si una clase anidada no requiere acceso a los miembros de instancia de su clase contenedora, es mejor declararla como static. De esta manera, no estará acoplada a la clase externa y, por lo tanto, será más óptima, ya que no requerirá memoria heap o memoria stack.

6.3. Puntos Clave a Recordar

Básicamente, una clase anidada static no tiene acceso a ningún miembro de instancia de la clase contenedora. Solo puede acceder a través de una referencia de objeto.

Las clases anidadas static pueden acceder a todos los miembros estáticos de la clase contenedora, incluidos los privados.

La especificación de programación de Java no nos permite declarar la clase de nivel superior como static. Solo las clases dentro de las clases (clases anidadas) pueden ser declaradas como static.

7. Comprendiendo el Error "Non-static variable cannot be referenced from a static context"

Por lo general, este error ocurre cuando usamos una variable no estática dentro de un contexto estático.

Como vimos anteriormente, las variables estáticas pertenecen a la clase y se cargan en el momento de la carga de la clase. Por otro lado, necesitamos crear un objeto para hacer referencia a las variables no estáticas.

Por lo tanto, el compilador de Java se queja porque se necesita un objeto para llamar o usar variables no estáticas.

Ahora que sabemos qué causa el error, ilustrémoslo con un ejemplo:

public class MiClase { 
    int variableDeInstancia = 0; 
    
    public static void metodoEstatico() { 
        System.out.println(variableDeInstancia); 
    } 
    
    public static void main(String[] args) {
        MiClase.metodoEstatico();
    }
} 

Como podemos ver, estamos usando variableDeInstancia, que es una variable no estática, dentro del método estático metodoEstatico.

Como resultado, obtendremos el error "Non-static variable cannot be referenced from a static context" (No se puede hacer referencia a una variable no estática desde un contexto estático).

8. Conclusión

En este artículo, vimos en acción la palabra clave static.

También discutimos las razones y ventajas de usar campos estáticos, métodos estáticos, bloques estáticos y clases anidadas estáticas.

Finalmente, aprendimos qué provoca que el compilador falle con el error "No se puede hacer referencia a una variable no estática desde un contexto estático".

1. Introducción

Si bien la herencia nos permite reutilizar código existente, a veces necesitamos establecer limitaciones a la extensibilidad por diversas razones; la palabra clave final nos permite hacer precisamente eso.

En este tutorial, examinaremos lo que significa la palabra clave final para clases, métodos y variables.

2. Clases final

Las clases marcadas como final no pueden ser extendidas. Si observamos el código de las bibliotecas centrales de Java, encontraremos muchas clases finales allí. Un ejemplo es la clase String.

Consideremos la situación si pudiéramos extender la clase String, sobrescribir cualquiera de sus métodos y sustituir todas las instancias de String con las instancias de nuestra subclase específica de String.

El resultado de las operaciones sobre objetos String se volvería entonces impredecible. Y dado que la clase String se utiliza en todas partes, eso sería inaceptable. Es por eso que la clase String está marcada como final.

Cualquier intento de heredar de una clase final provocará un error del compilador. Para demostrar esto, creemos la clase final Gato:

public final class Gato {
    private int peso;
    // getter y setter estándar
}

Y tratemos de extenderla:

public class GatoNegro extends Gato {
}

Veremos el error del compilador:

The type GatoNegro cannot subclass the final class Gato

Nota que la palabra clave final en una declaración de clase no significa que los objetos de esta clase sean inmutables. Podemos cambiar libremente los campos del objeto Gato:

Gato gato = new Gato();
gato.setPeso(1);

assertEquals(1, gato.getPeso());

Simplemente no podemos extenderla.

Si seguimos estrictamente las reglas de un buen diseño, debemos crear y documentar una clase con cuidado o declararla final por razones de seguridad. Sin embargo, debemos tener cuidado al crear clases finales.

Observa que hacer que una clase sea final significa que ningún otro programador puede mejorarla. Imagina que estamos utilizando una clase y no tenemos el código fuente de la misma, y hay un problema con uno de sus métodos.

Si la clase es final, no podemos extenderla para sobrescribir el método y solucionar el problema. En otras palabras, perdemos la extensibilidad, uno de los beneficios de la programación orientada a objetos.

3. Métodos final

Los métodos marcados como final no pueden ser sobrescritos (override). Cuando diseñamos una clase y sentimos que un método no debe ser sobrescrito, podemos hacer que este método sea final. También podemos encontrar muchos métodos finales en las bibliotecas centrales de Java.

A veces no necesitamos prohibir completamente la extensión de una clase, sino solo evitar la sobrescritura de algunos métodos. Un buen ejemplo de esto es la clase Thread. Es legal extenderla y así crear una clase de hilo personalizada. Pero su método isAlive() es final.

Este método comprueba si un hilo está vivo. Es imposible sobrescribir correctamente el método isAlive() por muchas razones. Una de ellas es que este método es nativo. El código nativo se implementa en otro lenguaje de programación y a menudo es específico del sistema operativo y el hardware en el que se ejecuta.

Creemos una clase Perro y hagamos que su método sonido() sea final:

public class Perro {
    public final void sonido() {
        // ...
    }
}

Ahora extendamos la clase Perro e intentemos sobrescribir su método sonido():

public class PerroNegro extends Perro {
    public void sonido() {
    }
}

Veremos el error del compilador:

- overrides 
com.javamagician.final.Perro.sonido
- Cannot override the final method from Perro
sonido() method is final and can’t be overridden

Si algunos métodos de nuestra clase son llamados por otros métodos, deberíamos considerar hacer que los métodos llamados sean final. De lo contrario, sobrescribirlos puede afectar el trabajo de los llamadores y causar resultados sorprendentes.

Si nuestro constructor llama a otros métodos, generalmente deberíamos declarar estos métodos como final por la razón mencionada anteriormente.

¿Cuál es la diferencia entre hacer que todos los métodos de la clase sean final y marcar la clase en sí como final? En el primer caso, podemos extender la clase y agregar nuevos métodos a ella.

En el segundo caso, no podemos hacerlo.

4. Variables final

Las variables marcadas como final no pueden ser reasignadas. Una vez que una variable final se inicializa, no se puede alterar.

4.1. Variables Primitivas final

Declaremos una variable primitiva final i, luego asignemos 0 a ella.

Y tratemos de asignarle un valor de 1:

public void cuandoAsignamosVariableFinal_entoncesSoloUnaVez() {
    final int i = 0;
    // ...
    i = 1;
}

El compilador dice:

The final local variable i may already have been assigned

4.2. Variables de Referencia final

Si tenemos una variable de referencia final, tampoco podemos reasignarla. Pero esto no significa que el objeto al que hace referencia sea inmutable. Podemos cambiar libremente las propiedades de este objeto.

Para demostrar esto, declaremos la variable de referencia final gato e inicialicémosla:

final Gato gato = new Gato();

Si intentamos reasignarla, veremos un error del compilador:

The final local variable gato cannot be assigned. It must be blank and not using a compound assignment

Pero podemos cambiar las propiedades de la instancia de Gato:

gato.setPeso(4);

assertEquals(4, gato.getPeso());

4.3. Campos final

Los campos final pueden ser constantes o campos de escritura única. Para distinguirlos, debemos hacernos una pregunta: ¿incluiríamos este campo si fuéramos a serializar el objeto? Si no, entonces no es parte del objeto, sino una constante.

Ten en cuenta que según las convenciones de nomenclatura, las constantes de clase deben estar en mayúsculas, con componentes separados por el carácter de subrayado ("_"):

static final int ANCHO_MAXIMO = 1337;

Ten en cuenta que cualquier campo final debe inicializarse antes de que el constructor se complete.

Para campos static final, esto significa que podemos inicializarlos:

• al declararlos, como se muestra en el ejemplo anterior
• en el bloque de inicialización estática

Para campos final de instancia, esto significa que podemos inicializarlos:

• al declararlos
• en el bloque de inicialización de instancia
• en el constructor

De lo contrario, el compilador nos dará un error.

4.4. Argumentos final

La palabra clave final también es legal para ponerla antes de los argumentos de un método. Un argumento final no se puede cambiar dentro de un método:

public void metodoConArgumentosFinales(final int x) {
    x = 0;
}

La asignación anterior provoca el error del compilador:

The final local variable x cannot be assigned. It must be blank and not using a compound assignment

5. Conclusión

En este artículo, aprendimos lo que significa la palabra clave final para clases, métodos y variables. Aunque es posible que no utilicemos la palabra clave final con frecuencia en nuestro código interno, puede ser una buena solución de diseño.

1. Introducción

Se requiere que todos los lenguajes de programación orientados a objetos (OOP) exhiban cuatro características básicas: abstracción, encapsulación, herencia y polimorfismo.

En este artículo, cubrimos dos tipos fundamentales de polimorfismo: el polimorfismo estático o de tiempo de compilación y el polimorfismo dinámico o de tiempo de ejecución. El polimorfismo estático se aplica durante la compilación, mientras que el polimorfismo dinámico se realiza en tiempo de ejecución.

2. Polimorfismo Estático

Según Wikipedia, el polimorfismo estático es una imitación del polimorfismo que se resuelve en tiempo de compilación y, por lo tanto, elimina la necesidad de búsquedas en tablas virtuales en tiempo de ejecución.

Por ejemplo, nuestra clase FicheroTexto en una aplicación de gestión de archivos puede tener tres métodos con la misma firma que el método leer():

public class FicheroTexto extends FicheroGenerico {
    //...

    public String leer() {
        return this.getContent()
          .toString();
    }

    public String leer(int limite) {
        return this.getContent()
          .toString()
          .substring(0, limite);
    }

    public String leer(int inicio, int fin) {
        return this.getContent()
          .toString()
          .substring(inicio, fin);
    }
}

Durante la compilación del código, el compilador verifica que todas las invocaciones del método leer correspondan al menos a uno de los tres métodos definidos anteriormente.

3. Polimorfismo Dinámico

Con el polimorfismo dinámico, la Java Virtual Machine (JVM) maneja la detección del método apropiado para ejecutar cuando una subclase se asigna a su forma principal. Esto es necesario porque la subclase puede anular algunos o todos los métodos definidos en la clase principal.

En una aplicación hipotética de gestión de archivos, definamos la clase principal para todos los archivos llamada FicheroGenerico:

public class FicheroGenerico {
    private String nombre;

    //...

    public String obtenerInformacion() {
        return "Implementación de Fichero Genérico";
    }
}

También podemos implementar una clase FicheroImagen que extiende FicheroGenerico pero anula el método obtenerInformacion() y agrega más información:

public class FicheroImagen extends FicheroGenerico {
    private int altura;
    private int ancho;

    //... métodos getter y setter
    
    public String obtenerInformacion() {
        return "Implementación de Fichero de Imagen";
    }
}

Cuando creamos una instancia de FicheroImagen y la asignamos a una clase FicheroGenerico, se realiza una conversión implícita. Sin embargo, la JVM mantiene una referencia a la forma real de FicheroImagen.

La construcción anterior es análoga a la anulación de métodos. Podemos confirmarlo invocando el método obtenerInformacion() de la siguiente manera:

public static void main(String[] args) {
    FicheroGenerico ficheroGenerico = new FicheroImagen("EjemploFicheroImagen", 200, 100, 
      new BufferedImage(100, 200, BufferedImage.TYPE_INT_RGB)
      .toString()
      .getBytes(), "v1.0.0");
    logger.info("Información del Fichero: \n" + ficheroGenerico.obtenerInformacion());
}

Como era de esperar, ficheroGenerico.obtenerInformacion() activa el método obtenerInformacion() de la clase FicheroImagen, como se ve en la salida a continuación:

Información del Fichero: 
Implementación de Fichero de Imagen

4. Otras Características Polimórficas en Java

Además de estos dos tipos principales de polimorfismo en Java, existen otras características en el lenguaje de programación Java que exhiben polimorfismo. Discutamos algunas de estas características.

4.1. Coerción

La coerción polimórfica trata sobre la conversión implícita de tipo realizada por el compilador para evitar errores de tipo. Un ejemplo típico se ve en la concatenación de un entero y una cadena:

String cadena = "cadena" + 2;

4.2. Sobrecarga de Operadores

La sobrecarga de operadores o métodos se refiere a una característica polimórfica en la que un mismo símbolo u operador tiene diferentes significados (formas) según el contexto.

Por ejemplo, el símbolo de suma (+) se puede usar tanto para la adición matemática como para la concatenación de Strings. En ambos casos, solo el contexto (es decir, los tipos de argumentos) determina la interpretación del símbolo:

String cadena = "2" + 2;
int suma = 2 + 2;
System.out.printf(" cadena = %s\n suma = %d\n", cadena, suma);

Salida:

cadena = 22
suma = 4

4.3. Parámetros Polimórficos

El polimorfismo paramétrico permite que el nombre de un parámetro o método en una clase se asocie con diferentes tipos. Tenemos un ejemplo típico a continuación, donde definimos contenido como una String y luego como un Integer:

public class FicheroTexto extends FicheroGenerico {
    private String contenido;
    
    public String establecerDelimitadorDeContenido() {
        int contenido = 100;
        this.contenido = this.contenido + contenido;
    }
}

También es importante tener en cuenta que la declaración de parámetros polimórficos puede llevar a un problema conocido como "variable hiding" (ocultación de variables), donde la declaración local de un parámetro siempre anula la declaración global de otro parámetro con el mismo nombre.

Para resolver este problema, a menudo es aconsejable utilizar referencias globales, como la palabra clave this, para señalar variables globales dentro de un contexto local.

4.4. Subtipos Polimórficos

El subtipo polimórfico permite asignar varios subtipos a un tipo y esperar que todas las invocaciones en el tipo activen las definiciones disponibles en el subtipo.

Por ejemplo, si tenemos una colección de FicheroGenerico y llamamos al método obtenerInformacion() en cada uno de ellos, podemos esperar que la salida sea diferente según el subtipo del que se derivó cada elemento en la colección:

FicheroGenerico [] ficheros = {new FicheroImagen("EjemploFicheroImagen", 200, 100, 
  new BufferedImage(100, 200, BufferedImage.TYPE_INT_RGB).toString() 
  .getBytes(), "v1.0.0"), new FicheroTexto("EjemploFicheroTexto", 
  "Este es un contenido de texto de ejemplo", "v1.0.0")};
 
for (int i = 0; i < ficheros.length; i++) {
    ficheros[i].obtenerInformacion();
}

El polimorfismo de subtipo se hace posible mediante una combinación de conversión ascendente y enlace tardío. La conversión ascendente implica la conversión de la jerarquía de herencia de un supertipo a un subtipo:

FicheroImagen ficheroImagen = new FicheroImagen();
FicheroGenerico fichero = ficheroImagen;

El efecto resultante de lo anterior es que los métodos específicos de FicheroImagen no se pueden invocar en el nuevo FicheroGenerico convertido hacia arriba. Sin embargo, los métodos en el subtipo anulan los métodos similares definidos en el supertipo.

Para resolver el problema de no poder invocar métodos específicos del subtipo al convertir hacia arriba a un supertipo, podemos hacer una conversión hacia abajo de la herencia de un supertipo a un subtipo. Esto se hace mediante:

FicheroImagen ficheroImagen = (FicheroImagen) fichero;

La estrategia de enlace tardío ayuda al compilador a resolver cuál método activar después de la conversión hacia arriba (upcasting). En el caso de ficheroImagen.obtenerInformacion frente a fichero.obtenerInformacion en el ejemplo anterior, el compilador mantiene una referencia al método obtenerInformacion de FicheroImagen.

5. Problemas con el Polimorfismo

Echemos un vistazo a algunas ambigüedades en el polimorfismo que podrían llevar a errores en tiempo de ejecución si no se verifican adecuadamente.

5.1. Identificación de Tipo Durante la Conversión Hacia Abajo

Recuerda que anteriormente perdimos el acceso a algunos métodos específicos del subtipo después de realizar una conversión hacia arriba. Aunque pudimos resolver esto con una conversión hacia abajo, esto no garantiza una verificación real del tipo.

Por ejemplo, si realizamos una conversión hacia arriba y luego una conversión hacia abajo:

FicheroGenerico fichero = new FicheroGenerico();
FicheroImagen ficheroImagen = (FicheroImagen) fichero;
System.out.println(ficheroImagen.getAltura());

Notamos que el compilador permite una conversión hacia abajo de un FicheroGenerico a un FicheroImagen, incluso cuando la clase en realidad es un FicheroGenerico y no un FicheroImagen.

En consecuencia, si intentamos invocar el método getAltura() en la clase ficheroImagen, obtenemos una excepción de ClassCastException ya que FicheroGenerico no define el método getAltura:

Excepción en el subproceso "main" java.lang.ClassCastException:
FicheroGenerico no se puede convertir en FicheroImagen

Para resolver este problema, la JVM realiza una verificación de información de tipo en tiempo de ejecución (siglas en inglés RTTI). También podemos intentar una identificación explícita del tipo utilizando la palabra clave instanceof de la siguiente manera:

FicheroImagen ficheroImagen;
if (fichero instanceof FicheroImagen) {
    ficheroImagen = (FicheroImagen) fichero;
}

Lo anterior ayuda a evitar una excepción de ClassCastException en tiempo de ejecución. Otra opción que se puede usar es envolver la conversión dentro de un bloque try-catch y capturar la excepción de ClassCastException.

Es importante tener en cuenta que la verificación de RTTI es costosa debido al tiempo y los recursos necesarios para verificar eficazmente que un tipo sea correcto. Además, el uso frecuente de la palabra clave instanceof generalmente implica un diseño deficiente.

5.2. Problema de la Clase Base Frágil

Según Wikipedia, las clases base o superclases se consideran frágiles si las modificaciones aparentemente seguras en una clase base pueden hacer que las clases derivadas funcionen incorrectamente.

Consideremos una declaración de una superclase llamada FicheroGenerico y su subclase FicheroTexto:

public class FicheroGenerico {
    private String contenido;

    void escribirContenido(String contenido) {
        this.contenido = contenido;
    }
    void toString(String str) {
        str.toString();
    }
}

public class FicheroTexto extends FicheroGenerico {
    @Override
    void escribirContenido(String contenido) {
        toString(contenido);
    }
}

Cuando modificamos la clase FicheroGenerico de la siguiente manera:

public class FicheroGenerico {
    //...

    void toString(String str) {
        escribirContenido(str);
    }
}

Observamos que la modificación anterior deja a FicheroTexto en una recursión infinita en el método escribirContenido(), lo que eventualmente provoca un desbordamiento de la pila.

Para abordar un problema de clase base frágil, podemos usar la palabra clave final para evitar que las subclases anulen el método escribirContenido(). La documentación adecuada también puede ayudar. Y, por último, la composición generalmente debe preferirse sobre la herencia.

6. Conclusión

En este artículo, discutimos el concepto fundamental del polimorfismo, centrándonos en ventajas y desventajas.

1. Introducción

Existen muchos casos en los que, al implementar un contrato, deseamos posponer algunas partes de la implementación para completarlas más tarde. Esto se puede lograr fácilmente en Java a través de las clases abstractas.

En este tutorial, aprenderemos los conceptos básicos de las clases abstractas en Java y en qué casos pueden ser útiles.

2. Conceptos Clave para Clases Abstractas

Antes de profundizar en cuándo usar una clase abstracta, veamos sus características más relevantes:

• Definimos una clase abstracta con el modificador abstract que precede a la palabra clave class.
• Se puede heredar de una clase abstracta, pero no se puede instanciar.
• Si una clase define uno o más métodos abstract, entonces la clase en sí debe declararse como abstract.
• Una clase abstract puede declarar métodos tanto abstractos como concretos.
• Una subclase derivada de una clase abstract debe implementar todos los métodos abstract de la clase base o ser ella misma abstract.

Para comprender mejor estos conceptos, crearemos un ejemplo simple.

Supongamos que nuestra clase abstracta base define la API abstracta de un juego de mesa:

public abstract class JuegoDeMesa {

    //... declaraciones de campos, constructores

    public abstract void jugar();

    //... métodos concretos
}

Luego, podemos crear una subclase que implemente el método jugar:

public class Damas extends JuegoDeMesa {

    public void jugar() {
        //... implementación
    }
}

3. Cuándo Usar Clases Abstractas

Ahora, analicemos algunos escenarios típicos en los que deberíamos preferir las clases abstractas sobre interfaces y clases concretas:

• Queremos encapsular alguna funcionalidad común en un solo lugar (reutilización de código) que múltiples subclases relacionadas compartirán.
• Necesitamos definir parcialmente una API que nuestras subclases puedan ampliar y refinar fácilmente.
• Las subclases necesitan heredar uno o más métodos o campos comunes con modificadores de acceso protegidos.

Es importante tener en cuenta que todos estos escenarios son buenos ejemplos de adherencia completa basada en herencia al principio de Abierto/Cerrado.

Además, dado que el uso de clases abstractas trata implícitamente con tipos base y subtipos, también estamos aprovechando el polimorfismo.

Ten en cuenta que la reutilización de código es una razón muy convincente para usar clases abstractas, siempre y cuando se preserve la relación "es un" dentro de la jerarquía de clases.

Desde Java 8 se agregó otro matiz con los métodos por defecto (default), que a veces pueden reemplazar la necesidad de crear una clase abstracta por completo.

4. Ejemplo de Jerarquía de Lectores de Archivos

Para comprender con mayor claridad la funcionalidad que aportan las clases abstractas, veamos otro ejemplo.

4.1 Definir una Clase Abstracta Base

Entonces, si quisiéramos tener varios tipos de lectores de archivos, podríamos crear una clase abstracta que encapsule lo que es común en la lectura de archivos:

public abstract class LectorDeArchivoBase {
    
    protected Path rutaArchivo;
    
    protected LectorDeArchivoBase(Path rutaArchivo) {
        this.rutaArchivo = rutaArchivo;
    }
    
    public Path obtenerRutaArchivo() {
        return rutaArchivo;
    }
    
    public List<String> leerArchivo() throws IOException {
        return Files.lines(rutaArchivo)
          .map(this::mapearLineaArchivo).collect(Collectors.toList());
    }
    
    protected abstract String mapearLineaArchivo(String linea);
}

Observa que hemos declarado rutaArchivo como protegida para que las subclases puedan acceder a ella si es necesario. Más importante aún, hemos dejado algo sin hacer: cómo analizar realmente una línea de texto del contenido del archivo.

Nuestro plan es simple: si nuestras clases concretas no tienen una forma especial de almacenar la ruta del archivo o de recorrer el archivo, cada una tendrá una forma especial de transformar cada línea.

A simple vista, LectorDeArchivoBase puede parecer innecesario. Sin embargo, es la base de un diseño limpio y fácilmente ampliable. A partir de él, podemos implementar fácilmente diferentes versiones de un lector de archivos que pueden centrarse en su lógica de negocio única.

4.2 Definir Subclases

Una implementación natural es probablemente una que convierte el contenido del archivo a minúsculas:

public class LectorDeArchivoMinusculas extends LectorDeArchivoBase {

    public LectorDeArchivoMinusculas(Path rutaArchivo) {
        super(rutaArchivo);
    }

    @Override
    protected String mapearLineaArchivo(String linea) {
        return linea.toLowerCase();
    }   
}

Otra podría ser una que convierte el contenido del archivo a mayúsculas:

public class LectorDeArchivoMayusculas extends LectorDeArchivoBase {

    public LectorDeArchivoMayusculas(Path rutaArchivo) {
        super(rutaArchivo);
    }

    @Override
    protected String mapearLineaArchivo(String linea) {
        return linea.toUpperCase();
    }
}

Como podemos ver en este ejemplo simple, cada subclase puede centrarse en su comportamiento único sin necesidad de especificar otros aspectos de la lectura de archivos.

4.3 Uso de una Subclase

Finalmente, usar una clase que hereda de una clase abstracta no es diferente a cualquier otra clase concreta:

@Test
public void dadoUnainstanciaDeLectorDeArchivoMinusculas_cuandoSeLlamaLeerArchivo_entoncesEsCorrecto() throws Exception {
    URL ubicacion = getClass().getClassLoader().getResource("files/test.txt")
    Path ruta = Paths.get(ubicación.toURI());
    LectorDeArchivoBase lectorMinusculas = new LectorDeArchivoMinusculas(ruta);
        
    assertThat(lectorMinusculas.leerArchivo()).isInstanceOf(List.class);
}

Por simplificación, el archivo de destino se encuentra en la carpeta src/main/resources/files. Por lo tanto, utilizamos un cargador de clases de aplicación para obtener la ruta del archivo de ejemplo. Profundizaremos más en los cargadores de clases en futuras lecciones.

5. Conclusión

En este artículo rápido, aprendimos los conceptos básicos de las clases abstractas en Java y cuándo usarlas para lograr la abstracción y encapsular la implementación común en un solo lugar.

1. Introducción

En pocas palabras, antes de que podamos trabajar con un objeto en la JVM (Java Virtual Machine), debe inicializarse.

En este tutorial, examinaremos las diversas formas en que podemos inicializar tipos primitivos y objetos.

2. Declaración vs. Inicialización

Comencemos asegurándonos de que estamos en la misma página.

La declaración es el proceso de definir la variable, junto con su tipo y nombre.

Aquí estamos declarando la variable id:

int id;

La inicialización, por otro lado, se trata de asignar un valor:

id = 1;

Para demostrarlo, crearemos una clase Usuario con propiedades de nombre e id:

public class Usuario {
    private String nombre;
    private int id;
    
    // constructor estándar, getters, setters, etc.
}

A continuación, veremos que la inicialización funciona de manera diferente según el tipo de campo que estemos inicializando.

3. Objetos vs. Tipos Primitivos

Java proporciona dos tipos de representación de datos: tipos primitivos y tipos de referencia. En esta sección, discutiremos las diferencias entre los dos en relación con la inicialización.

Java tiene ocho tipos de datos incorporados, conocidos como tipos primitivos de Java; las variables de este tipo mantienen sus valores directamente.

Los tipos de referencia mantienen referencias a objetos (instancias de clases). A diferencia de los tipos primitivos que mantienen sus valores en la memoria donde se asigna la variable, las referencias no mantienen el valor del objeto al que se refieren.

En su lugar, una referencia apunta a un objeto almacenando la dirección de memoria donde se encuentra el objeto.

Ten en cuenta que Java no nos permite descubrir cuál es la dirección de memoria física. En cambio, solo podemos usar la referencia para referirnos al objeto.

Veamos un ejemplo que declara e inicializa un tipo de referencia de nuestra clase Usuario:

@Test
public void cuandoSeInicializaConNew_entoncesLaInstanciaNoEsNula() {
    Usuario usuario = new Usuario();
 
    assertThat(usuario).isNotNull();
}

Como podemos ver, una referencia se puede asignar a un nuevo objeto utilizando la palabra clave new, que es responsable de crear el nuevo objeto Usuario.

Continuemos aprendiendo más sobre la creación de objetos.

4. Creación de Objetos

A diferencia de los tipos primitivos, la creación de objetos es un poco más compleja. Esto se debe a que no estamos agregando simplemente el valor al campo; en su lugar, activamos la inicialización utilizando la palabra clave new. Esto, a su vez, invoca a un constructor e inicializa el objeto en la memoria.

Hablemos más detenidamente sobre los constructores y la palabra clave new.

La palabra clave new es responsable de asignar memoria para el nuevo objeto a través de un constructor.

Normalmente, un constructor se usa para inicializar las variables de instancia que representan las propiedades principales del objeto creado.

Si no proporcionamos un constructor explícitamente, el compilador creará un constructor predeterminado que no tiene argumentos y simplemente asigna memoria para el objeto.

Una clase puede tener muchos constructores, siempre y cuando las listas de parámetros sean diferentes (sobrecarga o overload). Cada constructor que no llama a otro constructor en la misma clase tiene una llamada a su constructor principal, ya sea que se haya escrito explícitamente o que lo haya insertado el compilador a través de super().

Agreguemos un constructor a nuestra clase Usuario:

public Usuario(String nombre, int id) {
    this.nombre = nombre;
    this.id = id;
}

Ahora podemos usar nuestro constructor para crear un objeto Usuario con valores iniciales para sus propiedades:

Usuario usuario = new Usuario("Alice", 1);

5. Alcance de las Variables

En las siguientes secciones, veremos los diferentes tipos de alcance (scope) en los que una variable en Java puede existir y cómo esto afecta al proceso de inicialización.

5.1. Variables de Instancia y de Clase

Las variables de instancia y de clase no requieren que las inicialicemos. Tan pronto como declaramos estas variables, se les asigna un valor predeterminado:

Ahora intentemos definir algunas variables relacionadas con instancias y clases, y comprobemos si tienen un valor predeterminado o no:

@Test
public void cuandoLosValoresNoSeInicializan_entoncesElNombreDeUsuarioYElIdDevuelvenElPredeterminado() {
    Usuario usuario = new Usuario();
 
    assertThat(usuario.getNombre()).isNull();
    assertThat(usuario.getId() == 0);
}

5.2. Variables Locales

Las variables locales deben inicializarse antes de su uso, ya que no tienen un valor predeterminado y el compilador no nos permitirá usar un valor no inicializado.

Por ejemplo, el siguiente código genera un error del compilador:

public void imprimir(){
    int i;
    System.out.println(i);
}

6. La Palabra Clave final

La palabra clave final aplicada a un campo significa que el valor del campo ya no se puede cambiar después de la inicialización. De esta manera, podemos definir constantes en Java.

Agreguemos una constante a nuestra clase Usuario:

private static final int ANYO = 2000;

Las constantes deben inicializarse ya sea cuando se declaran o en un constructor.

7. Inicializadores en Java

En Java, un inicializador es un bloque de código que no tiene un nombre o tipo de datos asociado y se coloca fuera de cualquier método, constructor o bloque de código.

Java ofrece dos tipos de inicializadores, inicializadores estáticos e inicializadores de instancia. Veamos cómo podemos usar cada uno de ellos.

7.1. Inicializadores de Instancia

Podemos usar estos para inicializar variables de instancia.

Para demostrarlo, proporcionaremos un valor para un id de usuario utilizando un inicializador de instancia en nuestra clase Usuario:

{
    id = 0;
}

7.2. Bloque de Inicialización Estática

Un inicializador estático, o bloque estático, es un bloque de código que se utiliza para inicializar campos static. En otras palabras, es un inicializador simple marcado con la palabra clave static:

private static String foro;
static {
    foro = "Java";
}

8. Orden de Inicialización

Cuando escribimos código que inicializa diferentes tipos de campos, debemos tener en cuenta el orden de inicialización.

En Java, el orden de las declaraciones de inicialización es el siguiente:

1. Variables estáticas e inicializadores estáticos en orden.
2. Variables de instancia e inicializadores de instancia en orden.
3. Constructores

9. Ciclo de Vida del Objeto

Ahora que hemos aprendido cómo declarar e inicializar objetos, descubramos qué sucede con los objetos cuando no se utilizan.

A diferencia de otros lenguajes donde debemos preocuparnos por la destrucción de objetos, Java se encarga de los objetos obsoletos a través de su recolector de basura.

Todos los objetos en Java se almacenan en la memoria de la aplicación. De hecho, el montón representa un gran conjunto de memoria no utilizada asignada para nuestra aplicación Java.

Por otro lado, el 'recolector de basura' (garbage collector) es un programa Java que se encarga de la gestión automática de la memoria eliminando objetos que ya no son accesibles.

Para que un objeto Java se vuelva inaccesible, debe encontrarse en una de las siguientes situaciones:

• El objeto ya no tiene referencias que lo apunten.
• Todas las referencias que apuntan al objeto están fuera de alcance.

En conclusión, un objeto primero se crea a partir de una clase, generalmente utilizando la palabra clave new. Luego, el objeto vive su vida y nos proporciona acceso a sus métodos y campos.

Finalmente, cuando ya no es necesario, el recolector de basura lo destruye.

10. Otros Métodos para Crear Objetos

En esta sección, echaremos un breve vistazo a métodos distintos de la palabra clave new para crear objetos, y aprenderemos cómo aplicarlos, específicamente reflexión, clonación y serialización.

La reflexión es un mecanismo que podemos utilizar para inspeccionar clases, campos y métodos en tiempo de ejecución. Aquí tienes un ejemplo de cómo crear nuestro objeto Usuario utilizando reflexión:

@Test
public void cuandoSeInicializaConReflexion_entoncesLaInstanciaNoEsNula() 
  throws Exception {
    Usuario usuario = Usuario.class.getConstructor(String.class, int.class)
      .newInstance("Alicia", 2);
 
    assertThat(usuario).isNotNull();
}

En este caso, estamos utilizando la reflexión para encontrar e invocar un constructor de la clase Usuario.

El siguiente método, la clonación, es una forma de crear una copia exacta de un objeto. Para ello, nuestra clase Usuario debe implementar la interfaz Cloneable:

public class Usuario implements Cloneable { //... }

Ahora podemos usar el método clone() para crear un nuevo objeto clonado usuarioClonado que tenga los mismos valores de propiedad que el objeto usuario:

@Test
public void cuandoSeCopiaConClonación_entoncesSeCreaUnaCoincidenciaExacta() 
  throws CloneNotSupportedException {
    Usuario usuario = new Usuario("Alicia", 3);
    Usuario usuarioClonado = (Usuario) usuario.clone();
 
    assertThat(usuarioClonado).isEqualTo(usuario);
}

También podemos utilizar la clase sun.misc.Unsafe para asignar memoria a un objeto sin llamar a un constructor:

Usuario u = (Usuario) unsafeInstance.allocateInstance(Usuario.class);

11. Conclusión

En este artículo, cubrimos la inicialización de campos en Java. Luego examinamos diferentes tipos de datos en Java y cómo usarlos. También exploramos varias formas de crear objetos en Java.