Forem: Elías Canales

Tipos genéricos

Elías Canales — Tue, 02 Sep 2025 12:00:00 +0000

Los tipos genéricos son aquellas interfaces o clases qque tienen uno o más parámetros de tipo. Los parámetros de tipo van entre el signo mayor que y el signo menor que (<>).

Antes de que existieran para objetos como las listas tenías que castear cada objeto, ahora mismo eso no es necesario, siempre y cuando no uses tipos raw.

//Definiendo el tipo de la lista
List<String> l = new ArrayList<>();
l.add("1234");
String s = l.getFirst();

//Usando RAW types
List l2 = new ArrayList();
l.add("1234");
String s2 = (String) l2.getFirst();

Usar tipos raw no es recomendado, principalmente porque no podrás tener ayuda del compilador, y los errores te ocurrirán en tiempo de ejecución, los cuales son más complejos de solucionar.

Y por otro lado, en los tipos raw siempre tendrás que castear, lo cual puede llevar a algún error de ejecución, además recibirás algunas advertencias que no son agradables y que son precisamente porque podrías tener errores.

Lo mejor es saber qué estamos haciendo y a ser posible no tener ningún warning (typesafe), es la única manera de asegurar que todo funcionará como nosotros esperamos, o acercarnos lo máximo posible.

En caso de necesitar guardar distintos tipos en una misma lista, tienes varias opciones, una podría ser guardar tener una lista de Object, no es la opción más óptima, y como normalmente a esa lista querrás aplicarle alguna operación es probable que quieras usar un tipo por medio de una interfaz.

Cuando definimos una lista como hemos dicho, lo mejor es tener un tipo, de esa forma en la definición no tendremos warnings, si no sabemos el tipo o podrían ser varios, y solo vamos a hacer operaciones de lectura podemos usar “?”.

//RAW type
List warning;

//Specific type
List<String> noWarning;

//Only to read without warning
List<?> readOnly;

Al crear la lista, tenemos que decirle el tipo, aunque la mejor opción actualmente es inducirlo con tan solo poner “<>”.

//Raw type warning on creation
List<String> warning = new ArrayList();

//Infer type
List<String> noWarning = new ArrayList<>();

Referencias
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Clases anidadas mejor estáticas

Elías Canales — Mon, 01 Sep 2025 12:00:00 +0000

Para clases anidadas tenemos varios tipos, clases anidadas estaticas, clases miembro, clases locales y clases anónimas. Es importante conocer las opciones antes de decidir cuál encaja mejor y por qué.

Clases anidadas (nested classes)

Las clases anidadas son simplemente clases definidas dentro de otra clase, es algo que puede parecer raro pero tiene sentido en determinados casos. Por ejemplo, si quieres definir un Enum que solo pertenece a una clase, puedes definirlo internamente en una clase y acceder a él de la forma ClaseExterna.NombreEnum.Valor.

public class User {

    public enum Rol {
        SUPPLIER, CUSTOMER
    }

}

//La usariamos así
User.Rol.CUSTOMER

Podemos hacer la clase pública o privada. En el caso de un enum, esto depende principalmente de si necesitamos usar la clase externamente o no.

Clases miembro (member classes)

Las clases miembro son iguales a las clases anidadas estáticas, pero con la única diferencia de que no son estáticas. Tienen una referencia a la clase que las contiene y son creadas teniendo una instancia de su contenedor.

public class User {

    class Rol {

    }

}

//Instanciación peculiar
User.Rol rol new User().new Rol();

Clases locales (local classes)

Las clases locales son aquellas que se definen en un ambito local como un método. Tienen alcance solo donde son definidas. Es importante destacar que, si las definimos como no estáticas, pueden tener acceso a la instancia padre, mientras que si son estáticas, solo tendrán acceso a los atributos estáticos de la clase.

public void method() {
    class Rol {

    }

    final Rol rol = new Rol();
}

Clases anonimas (anonymous classes)

Son las clases más limitadas y se han utilizado comúnmente como “función”, por ejemplo, si querías tener una clase Runnable sin necesidad de crear una clase que implementase dicha interfaz:

new Thread(
    //Clase anonima
    new Runnable() {
    @Override
    public void run() {

    }
})

Pero con la entrada de las funciones lambda en Java 8, ahora podemos simplemente hacer:

new Thread(() -> {

})

Es mucho más limpio y se entiende mejor al leer el código.

Clases anidadas estáticas (static nested classes)

Solo las clases anidadas pueden tener el modificador de comportamiento static, las clases normales no pueden. Si hacemos una clase miembro estática, tendremos una clase anidada estática.

Puede ser instanciada de una forma más simple y será prácticamente lo mismo, con la diferencia de que esta no tiene una referencia a una instancia que la envuelva, porque es independiente.
Normalmente, este tipo de clases no suelen requerir esa vinculación, y al hacerlas estáticas, estás mejorando el rendimiento y el funcionamiento del recolector de basura de Java.

Referencias
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Herencia vs clases etiquetadas

Elías Canales — Fri, 29 Aug 2025 12:00:00 +0000

No suele ser muy habitual, pero a veces se crean clases que se basan en un enumerador para tomar decisiones en sus distintos métodos. Esto puede ser señal de clases etiquetadas.

Clases etiquetadas

Las clases etiquetadas ocurren cuando hacemos en una clase la distinción de un tipo mediante un atributo. No confundir con el estado de una clase, aunque incluso ese enfoque también podría mejorarse con clases, pero eso es una historia diferente.

Por ejemplo, si tenemos una clase que puede estar ejecutada, no ejecutada o en error, y obviamente sus métodos pueden actuar de distinta forma según el estado, esto sería parte del estado de la clase.

Sin embargo, si tenemos una clase usuario y que dentro tipo un atributo rol con los valores administrador, empleado y comprador. Es probable que estemos ante un caso de clases etiquetadas, más aún cuando no todos los atributos le pertenecen a todos los tipos de usuario.

Muy probablemente, en función de este tipo, tendremos un comportamiento distinto en los métodos o incluso en el constructor switch.

Herencia

La herencia consiste en otorgar más funcionalidad a una clase, al heredar de una clase superior. La clase hija hereda la funcionalidad de la clase padre y modifica o implementa su propia funcionalidad.

Tomando el ejemplo anterior, supongamos que no hay usuarios que no sean administrador, empleado o comprador. En ese caso, podríamos tener una clase usuario de tipo abstracta y 3 clases que heredan de usuario.

Una jerarquía de clases donde los métodos específicos están implementados en cada una de las clases, donde fuera de esto podemos hacer distinción por el tipo de la clase e incluso podemos usar sobrecarga de métodos con los tipos en otros servicios.

Conclusión

No caigas en la trampa de crear clases etiquetadas, aunque la herencia puede traer problemas, en los casos en los cuales encaja perfectamente como una de jerarquía de clases, la herencia es la mejor solución con diferencia.
Permitirá que tu clase sea más fácil de mantener y con un código más limpio.

Referencias
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

No uses interfaces para constantes

Elías Canales — Thu, 28 Aug 2025 12:00:00 +0000

El llamado como “constant interface pattern” es un antipatrón, que consiste en usar una interfaz de Java solo para definir constantes.
Esta forma de usar la interfaz va en contra del propio propósito original.

Desde mi punto de vista, se ha usado a veces la interfaz para definir constantes porque es una forma muy sencilla de tener un lugar donde centralizarlas, y además no puede ser instanciada.

Sin embargo, no es correcto hacerlo, porque el objetivo de las interfaces es definir tipos y, al usarla solo para definir constantes, no estas definiendo ningún tipo.
Además, alguien podría implementar esa interfaz, lo que podría generar problemas innecesarios en el futuro.

Puedes crear una clase no instanciable, que actuaría como una clase de utilidad, donde definir las constantes.

Pero antes de hacer eso, piensa lo siguiente:

Si las constantes pertenecen a un grupo, podrías crear una enumeración (enum)
Si las constantes están muy ligadas a una clase concreta, es mejor definirlas en esa clase

Si ninguna de las opciones anteriores satisface tus necesidades, opta por una clase no instanciable.

Referencias
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Cuando usar Abstract o Interface

Elías Canales — Wed, 27 Aug 2025 12:00:00 +0000

Java ofrece mucha versatilidad para hacer las cosas de distinta forma. Antes de Java 8 había una gran diferencia entre una clase abstracta y una interfaz. Pero lo cierto es que ahora, la diferencia es más bien pequeña.

Esto es debido principalmente a la definición de métodos por defecto de las interfaces. Antes de la versión 8 las interfaces solo tenían el contrato, pero no definían ninguna función por defecto. Por eso la diferencia era mucho mayor, ya que las clases abstractas pueden tanto definir contratos como implementaciones.

Y aunque las cosas se pueden hacer de distinta forma, a largo plazo, no hay tantas formas que garanticen mantener nuestro código limpio y fácilmente extensible. Por eso, es interesante tener en mente un enfoque a largo plazo pero sin tampoco obsesionarnos, porque los excesos tampoco son buenos.

Abstract class

Las clases abstractas son clases que no pueden instanciarse, las cuales están hechas para ser heredadas y donde las subclases deben definir los métodos del contrato a menos que la clase que herede también sea una clase abstracta.

Interface

Las interfaces son contratos, las clases pueden implementar muchos contratos, por lo que las clases pueden adquirir tipos por medio de las interfaces y hacer algo así como herencia múltiple.

Interfaz vs Abstract class

Como ya comentamos en el artículo sobre “favorecer la composición”, la herencia es peligrosa siempre que no se utiliza con mucho detenimiento. Por eso, las interfaces son mucho mas interesantes a la hora de definir tipos, nos pueden permitir guardar en un listado, elementos de un mismo tipo, o lo que es lo mismo, de una misma interfaz.

Pero tenemos que tener en cuenta, que las interfaces definen todos sus métodos como public por defecto (también permiten private pero solo son accesibles en esa interfaz), no podemos hacer métodos ocultos solo para el paquete o los que lo implementan (protected). Y tampoco podemos sobrescribir métodos estándar del objeto como equals, hashcode…

Las interfaces pueden heredar de otras interfaces, es más, pueden heredar de más de una. Con lo cual podemos juntar tipos para crear nuevos tipos más complejos, sin perder la versatilidad de tener tipos más pequeños.

Entonces, ¿Cuándo son interesantes las interfaces frente a las clases abstractas?

Cuando necesitamos que una clase implemente múltiples tipos
Cuando la funcionalidad no se ajusta a una jerarquía claramente definida, y se requiere un enfoque más flexible basado en contratos
Cuando no necesitas una implementación común
Cuando no necesitas un control detallado sobre la implementación de los métodos

Referencias

https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Favorece composición sobre herencia

Elías Canales — Tue, 26 Aug 2025 12:00:00 +0000

Cuando queremos crear una clase reutilizando la funcionalidad de otra clase, podemos pensar en usar herencia. Pero, ¿Es esta la mejor solución?

Herencia

En Java solo podemos extender de una clase, al extender tendremos la funcionalidad extra de todas las superclases, ya que, aunque solo podemos heredar de una clase, esa clase a su vez puede heredar de otra.

public abstract class Automobile {
    private final String brand;

    public String getBrand() {
        return brand;
    }
}

public class Car extends Automobile {
    private final int seats;

    public Car(String brand, int seats) {
        super(brand);
        this.seats = seats;
    }

    public int getSeats() {
        return seats;
    }
}

public class Sports extends Car {

    public Sports(String brand, int seats) {
        super(brand, seats);
    }

    @Override
    public String getBrand() {
        return null;
    }
}

La clase Sport hereda de Car y la de Car de Automobile. En este caso que las propiedades son privadas no podemos acceder directamente, pero sí que podemos alterar el método getBrand().

Aunque solo tendremos acceso a los atributos y funciones que no tengan el modificador de acceso private. Para la herencia es interesante el modificador de acceso protected, ya que permite acceder desde la clase que hereda, incluso si está en otro paquete.

La herencia rompe la encapsulación, podemos alterar el objetivo real del objeto. Al sobrescribir métodos, y dependiendo de cómo se haya diseñado el objeto, podemos alterar el funcionamiento original de la clase.

Por eso, tenemos que hacer la pregunta de si realmente necesitamos que se herede uno de los objetos fuera del paquete, pero también si es necesario que hereden de ese objeto, si realmente existe una relación de herencia entre ambos objetos (subclase y superclase)..

Encapsulación

Consiste en no permitir el acceso a propiedades, métodos o clases, utilizando los modificadores de acceso (private, default, protected y public). Con esto podemos prevenir el mal uso de nuestras clases, forzando a permitir acceder a aquello estrictamente necesario.

Composición

La composición es una forma de darle funcionalidad a nuestra clase, pero no sobrescribimos los métodos de la clase original. Estamos creando una nueva clase.
En programación se traduce básicamente en tener un atributo, si en lugar de heredar tenemos esa clase como atributo.

Veamos que pasaría si tenemos una clase que hereda de ArrayList, creamos la clase CarList, nosotros queremos tener un conteo de las marcas de los coches cuando se añade un nuevo coche a la CarList.

public class CarList extends ArrayList<Car> {

    private final HashMap<String, Integer> carBrandCount;

    public void addCar(Car car) {
        //count car brands
    }

}

A priori no hay ningún problema, tenemos nuestra CarList, donde contamos las marcas y así pues luego no tenemos que contar cada vez que nos lo pidan. Pero si tu instancias el CarList verás métodos que no tienen ningún sentido:

Tenemos el addCar que creamos nosotros, pero también tenemos addAll, add, stream…

Como dijimos antes, la herencia rompe la encapsulación, ahora pueden manipular el estado interno de nuestro objeto (la lista de los coches), con métodos que nosotros no queremos exponer o que romperían el correcto funcionamiento.

Una solución a este problema es la composición, si tenemos la lista como atributo de la clase, podemos exponer los métodos que nos interesen, y controlar el funcionamiento de nuestra CarList, y por supuesto, no utilizar la herencia.

Referencias
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Minimiza los objetos mutables

Elías Canales — Mon, 25 Aug 2025 12:00:00 +0000

Los objetos inmutables son aquellos que no pueden cambiar su estado una vez creados.

public class User {

    private final String passport;
    private final String name;
    private final String lastName;
    private final String email;
    private final String school;

    public UserManual(final String passport, final String name, 
                      final String lastName, final String email,
                      final String school) {
        this.passport = passport;
        this.name = name;
        this.lastName = lastName;
        this.email = email;
        this.school = school;
    }

También se puede conseguir con los record de Java:

public record UserRecord(String passport, String name, 
                         String lastName, String email, 
                         String school) {
}

En principio, haciendo los atributos private final y ofreciendo métodos de acceso, estos objetos permanecerán inmutables. Aunque tenemos que tener en cuenta que si pasamos otro objeto, ese sí que podría no ser inmutable.

public record Immutable(List<String> list) {
}


//Alteramos el estado interno
final Immutable actual = new Immutable(new ArrayList<>());
actual.list().add("1");

Y al igual que con una lista podemos hacer lo mismo con otros objetos que no sean inmutables. Una solución es que la gestionemos nosotros, o hacer una copia defensiva y convertirla en una lista no modificable.

No obstante, a veces sí es necesario que parte sea modificable o que pueda tener ciertas operaciones. Aunque lo mejor es que todo sea inmutable, porque te ayuda a entender mejor el código, ya que sabes que los objetos que ves no cambian de estado por el camino.

Por ejemplo, una llamada a una función podría alterar el estado de un objeto y no ser visible en la función principal. Además, los objetos inmutables son thread-safe por esa misma razón.

Que los objetos sean inmutables nos hace pensar de otra manera, y es que programar con objetos inmutables es una programación funcional, donde para poder tener un nuevo estado acabamos creando un nuevo objeto.
Mientras que en la programación imperativa se cambia el estado de los objetos.

Para hacer objetos inmutables, necesitas que no puedan heredarse, porque al heredar se podría sobrescribir su comportamiento.
Hay dos estrategias para hacer eso, una es haciendo la clase final y la otra con constructor privado y factoría estática (lo explico con más detalle en el patrón Singleton).

Los objetos inmutables deberían cumplir las siguientes propiedades:

No tener métodos que permitan modificar propiedades
No permitir que la clase pueda heredarse
Que todas las propiedades sean final
Que todas las propiedades sean private
En caso de tener propiedades que sean objetos, no deberíamos confiar en el cliente y hacer copias defensivas.

Referencias
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

No utilices atributos públicos

Elías Canales — Fri, 22 Aug 2025 12:00:00 +0000

Cuando estes definiendo tu código, piensa que cuanto menos acceso se tenga a tus clases, métodos o atributos, más fácil será hacer modificaciones y menos partes de tu código se verán afectadas.

De ahí nace la idea de no dejar tus atributos como públicos. Aunque siempre hay excepciones. Más adelante hablaremos de esas excepciones, ahora centrémonos en las ventajas de no hacerlo público, y seguramente alguna vez te has preguntado qué sentido tiene tener getter y setter (llenando tus clases de métodos ‘vacios’).

Lo cierto es que, la mayoría de las veces, eso no tiene ningún sentido, porque esos métodos no aportan gran cosa.
Tenemos la suerte de que pueden ser generados por librerías como Lombok.

Pero la idea de esos métodos nace principalmente de que podemos hacer acciones, tanto al obtener como al establecer valor.

Aunque no sea lo ideal, imagina que una de tus clases es muy utilizada a través de sus métodos setter y getter.
En uno de los desarrollos te has dado cuenta que necesitas cambiar el tipo. Quieres cambiarlo para todo el código porque encuentras que a largo plazo es una muy buena solución.

Si el atributo es público, tendrás que cambiar todos los lugares donde se usa. En cambio, si accedes mediante métodos, puedes usar sobrecarga para seguir devolviendo o estableciendo el valor como antes, sin tocar el código cliente, modificando solo tu clase.

Como te dije antes hay excepciones, la excepción es cuando la clase tiene acceso de paquete privado. Es decir, a una clase podemos ponerle el modificador de acceso public o dejarla sin modificador de acceso.

Cuando la dejamos sin modificador, entonces tenemos una clase de acceso privado que solo es accesible en ese paquete (por supuesto, también podemos tener clases anidadas en ese caso esto también aplica).
Cuando la clase es de acceso privado, somos nosotros los que controlamos en un pequeño espacio (el paquete), quien y cómo la utiliza, y por tanto, podemos usar el acceso público.

En principio para las clases inmutables, deberíamos hacer lo mismo que con las clases mutables, para poder beneficiarnos de las mismas ventajas.

Referencias
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Implementando Comparable

Elías Canales — Thu, 21 Aug 2025 12:00:00 +0000

La interfaz Comparable no solo permite saber si dos objetos son iguales, además, podemos saber cual es menor o mayor. Esta interfaz debe ser implementada explícitamente, a diferencia de equals() que se hereda de Object.

public int compareTo(T otro)

Con esta interfaz habilitamos el uso de funciones que necesitan de objetos comparables. Por ejemplo, los algoritmos de ordenación necesitan poder comparar objetos y saber si es igual, mayor o menor.

También hay clases que para poder funcionar deben de poder comparar objetos, por ejemplo, TreeSet. Si construyes un TreeSet con objetos que no implementan la interfaz Comparable, veras que te dará una advertencia, básicamente porque no va a funcionar correctamente.

new TreeSet<>(Comparator.comparingInt(User::age));

Aunque también esta la opción de pasar una función de comparación, pero tienes que tener en cuenta que si en otro punto del código, vas a volver a necesitarlo, lo mejor sería implementarla directamente en el objeto.

El contrato de esta interfaz debería cumplir:

Tener simetría: Tenemos un objeto X y uno Y, si hacemos X.compareTo(Y) y obtenemos un mayor a 0. Cuando hagamos un Y.compareTo(X) tenemos que obtener un número negativo. Esto asegura que si X es mayor que Y, entonces Y sera menor que X. (Relativo a esto si X.compareTo(Y) da excepción, Y.compareTo(X) también debería dar excepción).
Propiedad transitiva: Si tenemos que X > Y > Z entonces X > Z. Por lo que, X.compareTo(Y) > 0, y Y.compareTo(Z) > 0, entonces X.compareTo(Z) > 0.
Por último, si dos objetos son iguales X.compareTo(Y) == 0. Entonces, el resultado contra un tercer objeto de X y Y debe ser igual. signo(X.compareTo(Z)) == signo(Y.compareTo(Z))
Es recomendable que si dos objetos son iguales para el equals() que también lo sean para el compareTo (X.compareTo(Y) == Y.compareTo(X)).

Cuando pongo que es mayor/menor a 0 o que se mira el signo(), es porque el compareTo no va a devolver 0, 1 y -1. Va a devolver 0, mayor a 0 o menor a 0.

Para implementar este método iremos evaluando cada una de las propiedades más relevantes del objeto, hasta encontrar una que no sea igual, y devolveremos la respuesta.

private static final Comparator<Box> COMPARATOR = 
  Comparator.comparingInt(Box::model)
        .thenComparingDouble(Box::width)
        .thenComparingDouble(Box::length)
        .thenComparingDouble(Box::height);

@Override
public int compareTo(Box b) {
    return COMPARATOR.compare(this, b);
}

A la hora de comparar es mejor utilizar los métodos estáticos de los tipos para comparar que usar '<' y '>'.

Referencias

https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/Comparable.html#compareTo(T)
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Siempre sobrescribe toString()

Elías Canales — Wed, 20 Aug 2025 12:00:00 +0000

Salvo que estes usando una clase de tipo record, necesitaras sobrescribir el toString() para que tenga sentido cuando estes debugeando o un test te falle y lo que veas en pantalla sea:

Expected :User@6c3f5566
Actual :User@12405818

La utilidad es 0, obviamente siempre que puedas utilizar clases inmutables record sera mucho mejor, pero si necesitas crear clases, en ese caso sobrescribe directamente el toString().

Lo normal es que todos los atributos del equals() esten en el toString(), el único caso en el cual, algún atributo podría no estar completo en el toString(), es cuando quieres enmascarar o ocultar, algún dato. Pero en ese caso también habría que valorar si tiene sentido tener ese dato y de esa forma en el equals().

Los atributos que salen en el equals() deberían ser accesibles por los desarrolladores, porque si quisieran sobrescribir el toString() o mostrarlo de otra forma tendrían que extraer la información del toString() lo que es propenso a cometer errores.

Este método puedes generarlo de forma automática, por ejemplo, usando Lombok, o bien usando ReflectionToStringBuilder ambos te permiten excluir atributos.

Si quisieras enmascarar atributos, creo que la mejor opción es crear una clase especifica para ese atributo y sobrescribir su toString().

public record Prueba(int a, Account num) {}

public record Account(String num) {

    @Override
    public String toString() {
        return mask(num);
    }
}

Referencias

https://commons.apache.org/proper/commons-lang//apidocs/org/apache/commons/lang3/builder/ReflectionToStringBuilder.html
https://projectlombok.org/features/ToString
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Sobrescribiendo hashCode()

Elías Canales — Tue, 19 Aug 2025 12:00:00 +0000

El método hashCode, es heredado de Object, normalmente de forma indirecta, y su utilidad principal es devolver un entero que representa al objeto.

Siempre que sobrescribes el método equals deberas sobrescribir el método hashCode para cumplir con el contrato.

Concretamente por la segunda regla: “If two objects are equal according to the equals method, then calling the hashcode method on each of the two objects must produce the same integer result”.

Como Java en principio devuelve un número de la referencia del objeto (como hashCode), si sobrescribes equals y tienes dos objetos iguales, su hashcode sera distinto, y por tanto, no estarás cumpliendo el contrato.

El hashCode debe

Durante una misma ejecución de programa, para objeto de un determinado equals siempre debe devolver el mismo hashCode. Pero para otra ejecución este valor no es necesario que sea el mismo.

Dos instancias distintas, pero que el equals es igual, deben devolver el mismo hashCode

Si dos objetos son distintos, el hashCode() no tiene porque ser distinto pero si para objetos distintos, el hashCode es distinto eso mejorara el número de colisiones, y por tanto, el rendimiento de las tablas hash.

Como lo implementamos

Tenemos que usar los atributos relevantes, que son los mismos que usamos en el equals para que dos objetos iguales tengan el mismo hashCode:

Si el dato relevante es primitivo, aplicaremos TipoPrimitivo.hashCode()
Si el dato relevante es complejo, y en el equals lo hemos hecho llamando recursivamente al equals del objeto, en este caso haremos lo mismo
Si necesitas hacer una validación más compleja, entonces crea una representación del objeto con un tipo primitivo y llama al hashCode como en el punto 2.
Si es nulo devuelve 0.
Si es un array y tiene un elemento significativo usa ese como hashCode, si no tiene ninguno usa una constante que no sea 0, y si todos son relevantes usa Arrays.hashCode().
Para combinar los distintos atributos, utiliza: hashCode = 31 * hashCode +
Finalmente devuelve el hashCode

Creo que lo más peculiar es el 31, básicamente ese número se utiliza para reducir el número de colisiones. Dado que dos objetos distintos podrían tener el mismo hashCode, el objetivo es reducir las colisiones.

Además, los compiladores son capaces de optimizar mucho esa multiplicación.

Lombok

Podemos generar el equals y hashCode usando la anotación [@EqualsAndHashCode](https://projectlombok.org/features/EqualsAndHashCode) de lombok.

Referencias
https://www.geeksforgeeks.org/why-does-javas-hashcode-in-string-use-31-as-a-multiplier/
https://projectlombok.org/
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.

Método equals() en Java

Elías Canales — Mon, 18 Aug 2025 12:00:00 +0000

Claves para definir la igualdad lógica entre objetos

Es un problema que pues encontrar fácilmente cuando programas en Java, probablemente con la clase String, y es que si quieres comparar Objetos necesitas equals() porque si usas ‘==’ lo que estás comparando es la referencia.

//Valor NO tiene implementado el método equals()
final Valor a = new Valor(1);
assertTrue(a == a && a.equals(a));

final Valor b = new Valor(1);
assertFalse(a == b);
assertFalse(a.equals(b));

//Valor tiene implementado el método equals()
final Valor a = new Valor(1);
assertTrue(a == a && a.equals(a));

final Valor b = new Valor(1);
assertFalse(a == b);
assertTrue(a.equals(b));

Cuando no tenemos implementado el método equals() la comparación ‘==’ tiene el mismo resultado. Es decir, estamos comparando la referencia. Pero si implementamos el método equals() ya es diferente. Ya tendremos la comparación de valor y referencia, separadas.

Antes de adentrarnos en cómo debe ser un método equals, podemos empezar hablando de cuando deberíamos de sobrescribir este método.

Cuando la clase sea una clase valor, es decir, cuando está representando algo que por sus atributos podemos decir, si es o no igual a otro objeto.
Cuando la instancia por sí misma no es única. Por ejemplo, una clase de un servicio en principio es única, si queremos saber si es la misma podemos usar ‘==’ porque no tiene propiedades que la hagan única frente a otra.
Cuando la superclase no tiene un método equals(). Para evitar romper la propiedad transitiva (más adelante hablaremos de esto).

Una vez tenemos claro que queremos un método equals(), lo siguiente es empezar a sobrescribirlo haciendo uso de la anotación @Override, esto es importante porque nos garantiza que realmente estamos sobrescribiendo.

Ya que si no estamos sobrescribiendo nada, tendremos una alerta por parte del IDE, o en tiempo de compilación.
Por ejemplo, si en vez de hacer equals(Object o) hacemos equals(Valor v).

Claramente no estamos sobrescribiendo el método equals() y podríamos tener resultados no deseados, por ello, mejor utilizar la anotación @Override en estos casos.

Si vamos a la documentación sobre este método vamos a ver las propiedades que debería de tener un método equals().

Reflexiva: Debe ser igual asimismo, obviamente el mismo objeto con los mismo valores debe decirnos que es igual (a.equals(a)).
Simétrica: No importa el orden que comparemos, es decir, debe ser lo mismo decir que ‘a’ es igual a ‘b’, que ‘b’ es igual a ‘a’ (a.equals(b) && b.equals(a) == true).
Transitiva: Si tenemos 3 instancias ‘a’,’b’ y ‘c’, si sabemos que a == b y
b == c, entonces a == c (a.equals(b) && b.equals(c) && a.equals(c)).
Consistente: Si llamamos varias veces a a.equals(b) y no hemos cambiado ninguno de los dos objetos, el resultado siempre debería ser el mismo.
Comparado contra un null: Devolver falso cuando se compara con un nulo (a.equals(null) == false).

Como podemos ver todas las propiedades tienen lógica, no son nada raro. Pero aunque parezca que es difícil romper alguna de esas propiedades, lo cierto es que hay algunas situaciones que pueden llevarnos a romperlo.

Romper simetría

@Override
public boolean equals(Object o) {
    if(o instanceof Valor)
        return num.equals(((Valor) o).num);
    else if(o instanceof Integer)
        return num.equals(o);
    else
        return false;
}

Una forma de romper la simetría es tratar dos tipos dentro de un equals(), de hecho es uno de los motivos para no hacer un equals(), porque si la clase que estas creando hereda de otra, y la superclase ya tiene una definición del método equals, en ese caso no lo sobrescribas.

Fíjate en el ejemplo, está claro que si comparamos dos objetos Valor va a funcionar. Si comparamos un Valor con un Integer también, pero y al reves que pasaría.

final Valor a = new Valor(1);
final Integer b = 1;

assertTrue(a.equals(b));
assertFalse(b.equals(a));

Como vemos, ‘a’ sí es igual a ‘b’, pero ‘b’ no es igual a ‘a’. Es algo obvio, pero tenemos que tener cuidado de no querer cubrir dos tipos en un equals(), vamos a ver que algo muy similar que pasa para el problema transitivo.

Romper transitividad

Tenemos la clase Valor en la cual implementamos el equals() solo para la clase Valor. Luego hemos creado una clase que hereda de Valor, que hemos llamado ValorAvanzado.

Si no tenemos en cuenta Valor en ValorAvanzado, estaríamos rompiendo simetría, porque tenemos que tener en cuenta que un ValorAvanzado también es un Valor.

//Valor
@Override
public boolean equals(Object o) {
    if(o instanceof Valor)
        return num.equals(((Valor) o).num);
    else
        return false;
}

//ValorAvanzado
@Override
public boolean equals(Object o) {
    if(o instanceof ValorAvanzado)
        return super.equals(o) && 
          decimals.equals(((ValorAvanzado) o).decimals);
    else if(o instanceof Valor)
        return super.equals(o);
    else
        return false;
}

final Valor a = new ValorAvanzado(1, 2);
final Valor b = new Valor(1);
final Valor c = new ValorAvanzado(1, 3);

assertTrue(a.equals(b));
assertTrue(b.equals(c));
assertFalse(a.equals(c));

Aunque ‘a’ es igual a ‘b’, y ‘b’ es igual a ‘c’, resulta que ‘a’ no es igual a ‘c’ en este caso. Por tanto, hemos roto la simetría. Como decía antes es muy similar al anterior, y es que cuando queremos abarcar dos tipos en un equals() nos vamos a encontrar problemas.

Este caso, concretamente, dado que la superclase ya tiene definido el método equals() no debemos sobrescribirlo. En caso de hacerlo tenemos que saber las consecuencias, y rompiendo alguna de las propiedades que la propia documentación establece, puede llevarnos a situaciones no deseadas.

La mejor solución en este caso, es hacer uso de la composición en vez de la herencia. Con la cual, podríamos tener un método equals() funcional para ambas clases.

Romper consistencia

La consistencia se puede romper por las operaciones que hagamos en el propio método equals(). Por ejemplo, si tenemos que hacer una llamada a un servicio externo, eso podría dar resultados no deterministas, y por tanto, romper la consistencia. Debemos solo hacer uso de elementos que están en memoria y nos permitirán tener resultados deterministas.

Lombok

En Lombok hay una anotación para definir automáticamente el equals y el hashCode (@EqualsAndHashCode), ya que cuando se sobrescribe el equals debes sobrescribir el hashCode. Pero debes tener en cuenta que la anotación de Lombok no va a arreglar todos los problemas que hemos comentado, sobre todo los relativos a herencia.

Referencias
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/Object.html
https://projectlombok.org
Joshua Bloch, Effective Java (3ª edición), Addison-Wesley, 2018.