J'ai un objet de type a) est le code ci-dessous "bon"? foo code>.
FOO a un ID code> (int)
b) Que dois-je revenir si les deux sont NULL? P> // overload operator ==
public static bool operator ==(Foo a, Foo b)
{
if (ReferenceEquals(x, y))
{
return true;
}
if (x == null && y == null)
{
return // ???
}
if (x == null || y == null)
{
return false;
}
return x.Id == y.Id; // Ids are the same
}
public static bool Equals(Foo x, Foo y)
{
return x == y;
}
4 Réponses :
Oui,
if(x!=null && y!=null) return x.id == y.id; return x == null && y == null;
@serhio: C'est une question de goût, mais je préférerais généralement la mise en œuvre de la logique dans les égaux et l'appeler de l'opérateur ==. Est-ce vraiment une raison pour la descendre?
Oui
en fait sur le dernier point, == et les égaux sont manipulés les mêmes sauf si les types de valeur Boxed ceci produit point D: non fort> c'est le même objet , le même espace mémoire - s'ils dirigent vers un champ de l'objet. p> p> null code> n'est que le pointeur interne avec valeur zéro. Il s'agit donc de comparer deux références ayant une valeur zéro. P>
objet.reeferequens (NULL, NULL) code> est toujours vrai à cause de ce fait pour ne pas avoir besoin du deuxième chèque. p>
false code> et
true code>. p>
Donc, je n'entrerai jamais dans si (x == null && y == null) code>?
Le point D est à plat non, voir Commentaires. S'ils dirigent vers un champ sur l'objet.
Si la propriété n'est que de retourner un champ - quel identifiant serait alors non. S'il renvoie une valeur non déterministe telle que guid.newguid (), ce n'est vraiment pas un identifiant.
c'est réellement un code inaccessible, comme EDIT: strong> Pour répondre spécifiquement à votre point (D): quand < Code> Références Code> Retours Il est parfaitement possible que vous puissiez avoir deux objets avec le même referequals () code> est documenté pour retourner
true code> si les deux opérandes sont nuls.
True code>, les deux références doivent être identiques; Donc, ils pointent sur le même objet. Ainsi, sauf si vous faites quelque chose d'imprévisible dans l'accesseur de propriété, les valeurs de l'ID seront lues à partir du même objet et seraient attendus em> être identiques. (Morale de l'histoire ici est que les propriétés doivent se comporter de manière répétable sans d'autres effets secondaires, comme étant peut-être attribuer un identifiant si aucun n'est déjà défini) p>
ID code>, mais différentes références. Par exemple: p>
referequals () code> donnerait false lors de la comparaison
A code> et
B code> (Comme ils sont différents instances em>), mais à moins que ce constructeur ait fait quelque chose comme allouer un
id code>, je m'attendrais à ce qu'ils partagent cet identifiant et votre vérification de l'égalité. < / p> p>
@serhio qui n'était pas là à l'époque, mais il y a un élément de style personnel ici ( travaillerait i>) - les normes de codage sur mon lieu de travail indiquant que le opérateur == code> doit toujours appeler
égale code> - aucune raison technique, mais il est facile de trouver si tout votre code est cohérent
Le retour // ???" N'est-ce pas inaccessible i> en termes de spec i> - mais vous avez raison de ne jamais y arriver (sauf une interception folle).
@Marc tu devrais faire quelque chose vraiment i> fou (ou tout simplement pas le fil de sécurité)
@Rowland Shaw: Dernier d): D
@rowland - en effet; Mon point principal était de mettre en évidence la différence entre officiellement inaccessible i> et simplement "ne va jamais là".
"Que vous pourriez avoir deux objets avec le même identifiant, mais différentes références" j'ai demandé à l'inverse: Références = ID Vrai et différents
@serhio n'est pas possible, comme pour Réfalaires Code> Pour retourner
true code> Ils doivent être b> la même référence (et ne peuvent pas être différents). Il est important de noter que la référence serait pour un seul objet qui (dans des circonstances normales - vous pouvez faire des choses folles dans l'accesseur de propriété) n'aurait jamais pu avoir la même valeur pour ses biens.
@Rowland Shaw: potentiellement et théoriquement oui, mais pratiquement non, comme l'a fait remarquer Fredrik Mörk.
Réfalaires code> gère déjà le cas lorsque les deux arguments sont nuls - msdn états "true si obja est le même instance que l'OBJB ou si les deux sont nuls; sinon, faux." Regardant sa valeur de retour. P>
En ce qui concerne la dernière question: il pourrait I> arriver. Disons une propriété renvoie
datetime.now.ticks code>, il pourrait s'agir de ce
x code> et
y code> renvoyer la même instance, mais depuis la propriété getter serait appelé deux fois cela pourrait renvoyer différents résultats.
Bonne pensée latérale, mais vous ne seriez certainement pas définir cet identifiant de votre objet, n'est-ce pas? Cela peut arriver par renvoyer une GUID.NewGuid () également.
@Aliostad: Je pensais au-delà du nom de la propriété. Et oui, tout appel qui reviendrait potentiellement une valeur différente à différents moments présentera ce comportement.