enums compare with - Comparando miembros enum de Java: == o es igual a ()?





7 Answers

¿Se puede usar == en enum ?

Sí: las enumeraciones tienen controles de instancia ajustados que le permiten usar == para comparar instancias. Aquí está la garantía proporcionada por la especificación del idioma (énfasis por mí):

JLS 8.9 Enums

Un tipo de enumeración no tiene más instancias que las definidas por sus constantes de enumeración.

Es un error de tiempo de compilación intentar crear una instancia explícita de un tipo de enumeración. El final clone método de final clone en Enum garantiza que las constantes de enum nunca se puedan clonar, y el tratamiento especial por parte del mecanismo de serialización garantiza que las instancias duplicadas nunca se creen como resultado de la deserialización. La creación de instancias reflexivas de tipos de enumeración está prohibida. En conjunto, estas cuatro cosas garantizan que no existan instancias de un tipo de enum más allá de las definidas por las constantes de enum .

Debido a que solo hay una instancia de cada constante de enum , es permisible utilizar el operador == en lugar del método equals al comparar dos referencias de objetos si se sabe que al menos una de ellas se refiere a una constante de enum . (El método equals en Enum es un método final que simplemente invoca a super.equals en su argumento y devuelve el resultado, por lo tanto, realiza una comparación de identidad).

Esta garantía es lo suficientemente fuerte como Josh Bloch recomienda, que si insistes en usar el patrón de singleton, la mejor manera de implementarlo es usar una enum un solo elemento (ver: Efectiva Java 2ª edición, elemento 3: aplicar la propiedad de singleton con un constructor privado o un tipo de enumeración ; también Thread safety en Singleton )

¿Cuáles son las diferencias entre == y equals ?

Como recordatorio, se debe decir que, en general, == NO es una alternativa viable a los equals . Sin embargo, cuando lo es (como con enum ), hay dos diferencias importantes que se deben tener en cuenta:

== nunca lanza NullPointerException

enum Color { BLACK, WHITE };

Color nothing = null;
if (nothing == Color.BLACK);      // runs fine
if (nothing.equals(Color.BLACK)); // throws NullPointerException

== está sujeto a verificación de compatibilidad de tipo en tiempo de compilación

enum Color { BLACK, WHITE };
enum Chiral { LEFT, RIGHT };

if (Color.BLACK.equals(Chiral.LEFT)); // compiles fine
if (Color.BLACK == Chiral.LEFT);      // DOESN'T COMPILE!!! Incompatible types!

¿Debe usarse == cuando sea aplicable?

Bloch menciona específicamente que las clases inmutables que tienen un control adecuado sobre sus instancias pueden garantizar a sus clientes que == es utilizable. enum se menciona específicamente para ejemplificar.

Ítem ​​1: considerar métodos de fábrica estáticos en lugar de constructores

[...] permite que una clase inmutable garantice que no existen dos instancias iguales: a.equals(b) si y solo si a==b . Si una clase hace esta garantía, sus clientes pueden usar el operador == lugar del método equals(Object) , lo que puede resultar en un mejor rendimiento. Los tipos de enumeración proporcionan esta garantía.

Para resumir, los argumentos para usar == en enum son:

  • Funciona.
  • Es mas rapido.
  • Es más seguro en tiempo de ejecución.
  • Es más seguro en tiempo de compilación.
string ejemplo recorrer

Sé que las enumeraciones de Java se compilan en clases con constructores privados y un grupo de miembros estáticos públicos. Al comparar dos miembros de una enumeración determinada, siempre he usado .equals() , por ejemplo,

public useEnums(SomeEnum a)
{
    if(a.equals(SomeEnum.SOME_ENUM_VALUE))
    {
        ...
    }
    ...
}

Sin embargo, acabo de encontrar un código que usa el operador igual == lugar de .equals ():

public useEnums2(SomeEnum a)
{
    if(a == SomeEnum.SOME_ENUM_VALUE)
    {
        ...
    }
    ...
}

¿Qué operador es el que debería estar usando?




Como han dicho otros, tanto == como .equals() funcionan en la mayoría de los casos. La certeza del tiempo de compilación de que no está comparando tipos de Objetos diferentes que otros han señalado es válida y beneficiosa, sin embargo, FindBugs también encontraría el tipo particular de error al comparar objetos de dos tipos diferentes de tiempo de compilación (y probablemente de Inspecciones de tiempo de compilación de Eclipse / IntelliJ), por lo que el compilador de Java que lo encuentra no agrega tanta seguridad adicional.

Sin embargo:

  1. El hecho de que == nunca arroje NPE en mi mente es una desventaja de == . Casi nunca debería ser necesario que los tipos de enum sean null , ya que cualquier estado adicional que desee expresar a través de null solo se puede agregar a la enum como una instancia adicional. Si es inesperadamente null , prefiero tener una NPE que == evaluar silenciosamente a falso. Por lo tanto, no estoy de acuerdo con que es más seguro en la opinión de tiempo de ejecución ; es mejor adquirir el hábito de no dejar nunca que los valores de enum sean @Nullable .
  2. El argumento de que == es más rápido también es falso. En la mayoría de los casos, llamará a .equals() en una variable cuyo tipo de tiempo de compilación sea la clase enum, y en esos casos el compilador puede saber que esto es igual a == (porque el método equals() una enum puede no ser anulado) y puede optimizar la función de llamada de distancia. No estoy seguro de si el compilador actualmente hace esto, pero si no lo hace, y resulta ser un problema de rendimiento en Java en general, entonces prefiero arreglar el compilador que hacer que 100.000 programadores de Java cambien su estilo de programación para adaptarse Características de rendimiento de una versión particular del compilador.
  3. enums son objetos. Para todos los demás tipos de objetos, la comparación estándar es .equals() , no == . Creo que es peligroso hacer una excepción para las enums porque podría terminar comparando Objetos accidentalmente con == lugar de equals() , especialmente si refactoriza una enum en una clase que no es enumeración. En el caso de una refactorización de este tipo, el punto de trabajo desde arriba es incorrecto. Para convencerse de que el uso de == es correcto, debe comprobar si el valor en cuestión es una enum o una primitiva; Si se enum clase que no sea enum , sería incorrecto pero fácil de omitir porque el código aún se compilaría. El único caso en el que un uso de .equals() sería incorrecto es si los valores en cuestión fueran primitivos; en ese caso, el código no se compilaría, por lo que es mucho más difícil pasarlo por alto. Por lo tanto, .equals() es mucho más fácil de identificar como correcto, y es más seguro contra futuras refactorizaciones.

Realmente creo que el lenguaje Java debería haber definido == en Objetos para llamar a .equals () en el valor de la mano izquierda, e introducir un operador separado para la identidad del objeto, pero no es así como se definió Java.

En resumen, sigo pensando que los argumentos están a favor de usar .equals() para los tipos de enum .




Prefiero usar == lugar de equals :

Otra razón, además de las otras ya comentadas aquí, es que puedes introducir un error sin darte cuenta. Supongamos que tiene esta lista que es exactamente igual pero en paquetes separados (no es común, pero podría suceder):

Primera enumeración :

package first.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

Segunda enumeración:

package second.pckg

public enum Category {
    JAZZ,
    ROCK,
    POP,
    POP_ROCK
}

Luego, suponga que utiliza los iguales como los siguientes en item.category que es first.pckg.Category pero importa el segundo enum ( second.pckg.Category ) en lugar del primero sin darse cuenta:

import second.pckg.Category;
...

Category.JAZZ.equals(item.getCategory())

Por lo tanto, siempre obtendrás false porque es una enumeración diferente, aunque esperas que sea cierto porque item.getCategory() es JAZZ . Y podría ser un poco difícil de ver.

Entonces, si en cambio usa el operador == , tendrá un error de compilación:

operator == no se puede aplicar a "second.pckg.Category", "first.pckg.Category"

import second.pckg.Category; 
...

Category.JAZZ == item.getCategory() 



Usar otra cosa que no sea == para comparar constantes de enumeración es una tontería. Es como comparar objetos de class con equals , ¡no lo hagas!

Sin embargo, hubo un error desagradable (BugId 6277781 ) en Sun JDK 6u10 y anteriores que podría ser interesante por razones históricas. Este error impidió el uso adecuado de == en enumeraciones deserializadas, aunque esto podría decirse que es un caso de esquina.




La razón por la que las enumeraciones funcionan fácilmente con == es porque cada instancia definida también es un singleton. Así que la comparación de identidad usando == siempre funcionará.

Pero usar == porque funciona con enumeraciones significa que todo su código está estrechamente relacionado con el uso de esa enumeración.

Por ejemplo: Enums puede implementar una interfaz. Supongamos que actualmente está utilizando una enumeración que implementa Interface1. Si más adelante, alguien lo cambia o introduce una nueva clase Impl1 como una implementación de la misma interfaz. Luego, si comienza a usar instancias de Impl1, tendrá mucho código para cambiar y probar debido al uso anterior de ==.

Por lo tanto, es mejor seguir lo que se considera una buena práctica, a menos que haya alguna ganancia justificable.




tl; dr

Otra opción es el método de utilidad Objects.equals .

Objects.equals( thisEnum , thatEnum )

Objects.equals

operador igual == en lugar de .equals ()

¿Qué operador es el que debería estar usando?

Una tercera opción es el método estático de Objects.equals que se encuentra en la clase de utilidad Objects agregada a Java 7 y posterior.

Ejemplo

Aquí hay un ejemplo usando la enumeración del Month .

boolean areEqual = Objects.equals( Month.FEBRUARY , Month.JUNE ) ;  // Returns `false`.

Beneficios

Encuentro un par de beneficios para este método:

  • Seguridad nula
  • Compacto, legible

Cómo funciona

¿Cuál es la lógica utilizada por Objects.equals ?

Compruébelo usted mismo, desde el código fuente de Java 10 de OpenJDK :

return (a == b) || (a != null && a.equals(b));



Enumeración en el medio es un conjunto de enteros constantes. "==" es tan válido y apropiado como si compararas dos enteros.






Related


Tags

java   enums