example - remarks c#

¿Por qué la implementación por defecto== no se llama igual?

Question

Posible duplicado:
¿Por qué ReferenceEquals y el operador == se comportan de forma diferente a los iguales?

La implementación predeterminada del operador == compara objetos por referencias. Por lo tanto, cuando reemplaza a Equals (cuyo comportamiento predeterminado es el mismo) también tiene que especificar los operadores == y != que llamen a Equals (y lo haga en cada clase de jerarquía, ya que los operadores == y != No son virtuales).

Mi pregunta es ¿por qué es así? ¿Por qué == y != Comparan los objetos por referencia en lugar de usar Equals? Supongo que debería haber una razón para algo tan fundamental.

Actualizar.

Para comentarios: asumí que == debería depender de iguales (pero no al revés), ya que puede anular los iguales en la clase base y usar esta implementación en las clases derivadas automáticamente. No funcionaría si se utilizara Igual a == en su implementación, ya que == no es virtual.

Answer 1

Creo que la razón principal es que == es un operador estático y se puede llamar en objetos null , mientras que Equals requiere una instancia .

Por ejemplo:

Foo foo1 = null;
Foo foo2 = null;
Console.WriteLine(foo1 == foo2); // cannot use Equals

Answer 2

El == ha existido y se usa como referencia desde C, y está integrado en la sintaxis del lenguaje en lugar de tener que responder en la invocación del método (incluso si los resultados son los mismos para ambos).

Simplemente, porque C # no es Objetivo C :)

Answer 3

En Java, a veces es bueno determinar rápidamente si dos identificadores son iguales simplemente comparando las referencias. == tiene su lugar. Si observa un método de equals generados por el IDE, a menudo encontrará que la primera comparación que se hace es la igualdad de referencia, después de todo, ¿por qué verificar los campos si las referencias de los objetos son iguales?

Answer 4

La "razón" se debe a que a veces uno necesita saber si A es la misma instancia que B en lugar de si son simplemente "iguales" entre sí.

Por ejemplo, dos objetos iguales pueden tener sentido para la mayor parte de su lógica de negocios, sin embargo, también puede necesitar utilizar algunas utilidades de concurrencia que realizan operaciones atómicas en las que los resultados dependen de la identidad del objeto, no de la igualdad.

Answer 5

Object.ReferenceEquals es un miembro static que compara la igualdad de referencia . Incluso los tipos de valor están recuadrados antes de pasar a ese método.

¿Qué pasa con Equals Es un método virtual , lo que significa que permite a un consumidor anular una funcionalidad.

Por lo tanto, la implementación predeterminada del comportamiento == presupone que la comparación predeterminada (referencia) está bien para usted, si necesita algo específico, en este caso, el marco le proporciona un método virtual , que puede anularse.

Answer 6

Yo lo llamaría una característica. Por referencia, dos objetos idénticos siguen siendo dos objetos separados. Si reemplaza a Equals, entonces puede determinar si dos objetos son idénticos. Incluso si dos objetos son idénticos, es posible que también desee probar si son el mismo objeto. A menudo tengo motivos para anular iguales, pero nunca tuve la necesidad de anular ==! = (Pero ese lenguaje proporciona esa opción).

Con cadena anulan == y no me gusta. Aunque la cadena es un tipo de referencia, los operadores de igualdad (== y! =) Están definidos para comparar los valores de los objetos de cadena, no las referencias (7.9.7 operadores de igualdad de cadena). Esto hace que las pruebas de igualdad de cuerdas sean más intuitivas. Ver el problema esta introducido. WPF ListBox Desplácese hasta la parte inferior