Sobrecarga del operador en .NET

Question

¿En qué situaciones consideraría sobrecargar a un operador en .NET?

Answer 1

• yo consideraría fuerte sobrecarga == y! = Cualquier lugar que anular Equals
• yo consideraría (mucho menos fuertemente) la sobrecarga de operadores de comparación en cualquier implemento IComparable<T>
• yo consideraría la sobrecarga de operadores aritméticos para fundamentalmente numérica tipos
• yo consideraría proporcionar conversiones explícitas para este tipo de "contenedor" (como Nullable<T>)
• me muy suelen tener en cuenta que proporciona conversiones implícitas

La regla de oro es no sobrecargar los operadores si el significado no es del todo evidente. Por ejemplo, creo que sería bastante extraño tener un operador + en Stream - podría significar "hacer una T escribible aquí, de modo que escribir en el resultado escriba en ambos" o podría significar "leer uno después de otro" o Probablemente otras cosas.

En mi experiencia, es bastante raro sobrecargar cualquier cosa que no sea == y! =.

Answer 2

me había pedido para cerrar esto, pero tal vez puede permanecer abierta (Traté de cambiar de opinión, pero al parecer no se puede revocar una solicitud de cierre: P)

voy a responder personalmente: Nunca.

Nunca pienso que sea una buena idea implementar la sobrecarga del operador. Solo hay una excepción: si estoy escribiendo algún tipo de colección (no ocurre muy a menudo) y quiero implementar los indexadores [].

En mi opinión personal, no creo que nunca sea apropiado invalidar ==, y otras cosas similares. Pero, de nuevo, no trabajo en campos complejos de matemáticas y finanzas, donde tales cosas pueden ser útiles. Pero no puedo hablar por experiencia en ese asunto (de hecho, puedo en el mundo de las finanzas, y no lo hicimos allí).

Answer 3

Consideraría utilizar la sobrecarga del operador para operaciones aritméticas en tipos que representan un valor lógico. Por ejemplo, ha habido ocasiones en que deseé que Point tuviera una sobrecarga para los operadores + y -.

Answer 4

considero operadores predominantes i estos casos:

• == y = cuando se trata de un simple tipo de valor, e implementar la comparación del valor!. En otros tipos, espero que == y! = Así sea la comparación de referencia y tampoco son caros.
• operadores de comparación (>,> = etc) en el mismo caso que el anterior si solo se trata de un valor numérico.
• En realidad, nunca sobrecargo operadores aritméticos, pero haría esto para el mismo tipo de valores numéricos si mejorara la usabilidad.
• operadores de colada si el tipo puede ser sin pérdida se ha convertido en otro tipo apropiado.

Answer 5

creo que el Framework design guidelines proporcionar un consejo decente:

• evitar la definición de sobrecargas de operadores, excepto en los tipos que deben sentirse como tipos primitivos (incorporados).
• CONSIDER definir las sobrecargas del operador en un tipo que debería parecer un tipo primitivo.
• DO define sobrecargas del operador en estructuras que representan números (como System.Decimal).
• NO SEA lindo al definir las sobrecargas del operador.
• NO proporcione sobrecargas de operador a menos que al menos uno de los operandos sea del tipo que define la sobrecarga.
• DO sobrecargue los operadores de forma simétrica.
• CONSIDER proporcionar métodos con nombres descriptivos que correspondan a cada operador sobrecargado.