Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. tiré de Lignes directrices de conception de framework : Conventions, Idiomes et Modèles pour les bibliothèques .NET réutilisables, 2ème édition. Cette édition a été publiée en 2008, et le livre a été entièrement révisé dans la troisième édition. Certaines informations de cette page peuvent être obsolètes.
Les surcharges d’opérateur permettent aux types d’infrastructure d’apparaître comme s’ils étaient des primitives de langage intégrées.
Bien qu’elles soient autorisées et utiles dans certaines situations, les surcharges d’opérateur doivent être utilisées avec prudence. Il existe de nombreux cas dans lesquels la surcharge des opérateurs a été abusée, par exemple lorsque les concepteurs de framework ont commencé à utiliser des opérateurs pour les opérations qui doivent être des méthodes simples. Les directives suivantes devraient vous aider à décider quand et comment utiliser la surcharge d'opérateur.
❌ ÉVITEZ de définir des surcharges d'opérateur, sauf dans les types qui doivent ressembler à des types primitifs (intégrés).
✔️ ENVISAGEZ de définir des surcharges d’opérateur dans un type qui doit ressembler à un type primitif.
Par exemple, System.String a operator== et operator!= défini.
✔️ Définissez des surcharges d’opérateur dans des structs qui représentent des nombres (tels que System.Decimal).
❌ NE FAITES PAS preuve de légèreté lors de la définition de surcharges d’opérateur.
La surcharge d’opérateur est utile dans les cas où il est immédiatement évident quel sera le résultat de l’opération. Par exemple, il est judicieux de pouvoir soustraire un DateTime d’un autre DateTime et d’obtenir un TimeSpan. Toutefois, il n’est pas approprié d’utiliser l’opérateur d’union logique pour unioniser deux requêtes de base de données, ou d’utiliser l’opérateur shift pour écrire dans un flux.
❌ NE PAS fournir de surcharges d’opérateur, sauf si au moins l’un des opérandes est du type définissant la surcharge.
✔️ SURCHARGEZ les opérateurs de manière symétrique.
Par exemple, si vous surchargez le operator==, vous devez également surcharger le operator!=. De même, si vous surchargez le operator<, vous devez également surcharger le operator>, et ainsi de suite.
✔️ ENVISAGEZ de fournir des méthodes avec des noms conviviaux qui correspondent à chaque opérateur surchargé.
De nombreuses langues ne prennent pas en charge la surcharge des opérateurs. Pour cette raison, il est recommandé que les types qui surchargent les opérateurs incluent une méthode secondaire avec un nom spécifique au domaine approprié qui fournit une fonctionnalité équivalente.
Le tableau suivant contient une liste d’opérateurs et les noms de méthodes conviviales correspondants.
| Symbole d’opérateur C# | Nom des métadonnées | Nom convivial |
|---|---|---|
N/A |
op_Implicit |
To<TypeName>/From<TypeName> |
N/A |
op_Explicit |
To<TypeName>/From<TypeName> |
+ (binary) |
op_Addition |
Add |
- (binary) |
op_Subtraction |
Subtract |
* (binary) |
op_Multiply |
Multiply |
/ |
op_Division |
Divide |
% |
op_Modulus |
Mod or Remainder |
^ |
op_ExclusiveOr |
Xor |
& (binary) |
op_BitwiseAnd |
BitwiseAnd |
| |
op_BitwiseOr |
BitwiseOr |
&& |
op_LogicalAnd |
And |
|| |
op_LogicalOr |
Or |
= |
op_Assign |
Assign |
<< |
op_LeftShift |
LeftShift |
>> |
op_RightShift |
RightShift |
N/A |
op_SignedRightShift |
SignedRightShift |
N/A |
op_UnsignedRightShift |
UnsignedRightShift |
== |
op_Equality |
Equals |
!= |
op_Inequality |
Equals |
> |
op_GreaterThan |
CompareTo |
< |
op_LessThan |
CompareTo |
>= |
op_GreaterThanOrEqual |
CompareTo |
<= |
op_LessThanOrEqual |
CompareTo |
*= |
op_MultiplicationAssignment |
Multiply |
-= |
op_SubtractionAssignment |
Subtract |
^= |
op_ExclusiveOrAssignment |
Xor |
<<= |
op_LeftShiftAssignment |
LeftShift |
%= |
op_ModulusAssignment |
Mod |
+= |
op_AdditionAssignment |
Add |
&= |
op_BitwiseAndAssignment |
BitwiseAnd |
|= |
op_BitwiseOrAssignment |
BitwiseOr |
, |
op_Comma |
Comma |
/= |
op_DivisionAssignment |
Divide |
-- |
op_Decrement |
Decrement |
++ |
op_Increment |
Increment |
- (unary) |
op_UnaryNegation |
Negate |
+ (unary) |
op_UnaryPlus |
Plus |
~ |
op_OnesComplement |
OnesComplement |
Surcharge d’opérateur ==
La surcharge de operator == est assez compliquée. La sémantique de l’opérateur doit être compatible avec plusieurs autres membres, tels que Object.Equals.
Opérateurs de conversion
Les opérateurs de conversion sont des opérateurs unaires qui autorisent la conversion d’un type vers un autre. Les opérateurs doivent être définis comme membres statiques soit sur l’opérande, soit sur le type de retour. Il existe deux types d’opérateurs de conversion : implicite et explicite.
❌ Ne fournissez pas d’opérateur de conversion si cette conversion n’est pas clairement attendue par les utilisateurs finaux.
❌ NE DÉFINISSEZ PAS les opérateurs de conversion en dehors du domaine d’un type.
Par exemple, Int32, Doubleet Decimal sont tous les types numériques, alors que DateTime ce n’est pas le cas. Par conséquent, il ne doit pas y avoir d’opérateur de conversion pour convertir un Double(long) en DateTime. Un constructeur est préféré dans ce cas.
❌ Ne fournissez pas d’opérateur de conversion implicite si la conversion est potentiellement perdue.
Par exemple, il ne doit pas y avoir de conversion implicite à partir de Double car Int32Double a une plage plus large que Int32. Un opérateur de conversion explicite peut être fourni même si la conversion est potentiellement perdue.
❌ NE LEVEZ PAS d’exceptions à partir de casts implicites.
Il est très difficile pour les utilisateurs finaux de comprendre ce qui se passe, car ils ne savent peut-être pas qu’une conversion est en cours.
✔️ LEVEZ System.InvalidCastException si un appel à un opérateur de conversion entraîne une perte de données et que le contrat de l’opérateur n’autorise pas les pertes de données.
Portions © 2005, 2009 Microsoft Corporation. Tous les droits réservés.
Réimprimé par l’autorisation de Pearson Education, Inc. tiré de Framework Design Guidelines : Conventions, Idioms et Patterns pour les bibliothèques .NET réutilisables, 2e édition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la Série de développement Microsoft Windows.