Sobrecargas del operador

Las sobrecargas de operador permiten que los tipos de marco aparezcan como si fueran primitivos de lenguaje integrados.

Aunque se permite y resulta útil en algunas situaciones, las sobrecargas de operador deben usarse con precaución. Hay muchos casos en los que se ha abusado de la sobrecarga de operadores, como cuando los diseñadores de marcos comenzaron a usar operadores para las operaciones que deben ser métodos simples. Las instrucciones siguientes deben ayudarle a decidir cuándo y cómo usar la sobrecarga del operador.

❌ EVITE definir sobrecargas de operador, excepto en aquellos tipos que deberían ser similares a los tipos primitivos (integrados).

✔️ CONSIDERE la posibilidad de definir sobrecargas de operador en un tipo que debería ser similar a un tipo primitivo.

Por ejemplo, System.String tiene operator== y operator!= definidos.

✔️ DEfina sobrecargas de operador en estructuras que representan números (como System.Decimal).

❌ NO sea ingenioso a la hora de definir sobrecargas de operador.

La sobrecarga del operador es útil en los casos en los que es inmediatamente obvio cuál será el resultado de la operación. Por ejemplo, tiene sentido poder restar uno DateTime de otro DateTime y obtener un TimeSpan. Sin embargo, no es adecuado usar el operador de unión lógica para unir dos consultas de base de datos o usar el operador de desplazamiento para escribir en un flujo.

❌ NO proporcione sobrecargas de operador a menos que al menos uno de los operandos sea del tipo que define la sobrecarga.

✔️ SOBRECARGUE operadores de forma simétrica.

Por ejemplo, si sobrecarga operator==, también debe sobrecargar operator!=. Del mismo modo, si sobrecarga operator<, también debe sobrecargar operator>, etc.

✔️ CONSIDERE la posibilidad de proporcionar métodos con nombres descriptivos que se correspondan con cada operador sobrecargado.

Muchos lenguajes no admiten la sobrecarga del operador. Por esta razón, se recomienda que los tipos que sobrecarguen operadores incluyan un método secundario con un nombre específico del dominio adecuado que proporcione una funcionalidad equivalente.

La tabla siguiente contiene una lista de operadores y los nombres de métodos amigables correspondientes.

Sobrecarga del operador ==

operator == La sobrecarga es bastante complicada. La semántica del operador debe ser compatible con otros miembros, como Object.Equals.

Operadores de conversión

Los operadores de conversión son operadores unarios que permiten la conversión de un tipo a otro. Los operadores deben definirse como miembros estáticos, ya sea en el operando o en el tipo de retorno. Hay dos tipos de operadores de conversión: implícitos y explícitos.

❌ NO proporcione un operador de conversión si los usuarios finales no esperan claramente dicha conversión.

❌ NO defina operadores de conversión fuera del dominio de un tipo.

Por ejemplo, Int32, Doubley Decimal son todos los tipos numéricos, mientras que DateTime no. Por lo tanto, no debe haber ningún operador de conversión para convertir un Double(long) en un DateTime. En tal caso, se prefiere un constructor.

❌ NO proporcione un operador de conversión implícito si la conversión es potencialmente perdida.

Por ejemplo, no debe haber una conversión implícita de Double a Int32 porque Double tiene un intervalo más amplio que Int32. Se puede proporcionar un operador de conversión explícito incluso si la conversión es potencialmente perdida.

❌ NO inicie excepciones desde conversiones implícitas.

Es muy difícil que los usuarios finales comprendan lo que sucede, ya que es posible que no sepan que se está llevando a cabo una conversión.

✔️ INICIE System.InvalidCastException si una llamada a un operador de conversión da lugar a una conversión con pérdidas y el contrato del operador no permite conversiones con pérdidas.

© Partes 2005, 2009 de Microsoft Corporation. Todos los derechos reservados.

Reimpreso con permiso de Pearson Education, Inc. de Framework Design Guidelines: Convenciones, Idiomas y Patrones para Bibliotecas .NET Reusables, 2ª Edición por Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la Serie Desarrollo de Microsoft Windows.

Consulte también

• Directrices de diseño de miembros
• Directrices de diseño de marcos