重写Equals方法时是否需要重写==和!=运算符? (。网)
或者建议这样做? 为什么?
Or it's advisable to do that?
Why?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
或者建议这样做? 为什么?
Or it's advisable to do that?
Why?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(9)
请参阅重写 Equals() 和运算符==的指南。
引用:
基本上:
如果您希望 == 和 != 的行为像
Equals(..)
和!Equals(..)
您需要实现运算符。 您通常只对不可变类型执行此操作。See the guidelines for overriding Equals() and operator==.
Quote:
Basically:
If you want == and != to behave like
Equals(..)
and!Equals(..)
you need to implement the operators. You typically do this only with immutable types.请参阅实现等于和等于运算符 (==) 的指南
对于值类型(结构),“每次重写 Equals 方法时都实现 ==”
对于引用类型(类),“大多数引用类型,即使是那些实现 Equals 方法的引用类型,也不应该重写 ==”。 不可变类和具有类似值语义的类是例外。
See Guidelines for Implementing Equals and the Equality Operator (==)
For Value Types (structs) "Implement == any time you override the Equals method"
For Reference Types (classes), "Most reference types, even those that implement the Equals method, should not override ==." The exception is for immutable classes and those with value-like semantics.
除了此处已有的所有答案之外,不要忘记确保
GetHashCode()
保持一致。In addition to all the answers already here, don't forget to ensure
GetHashCode()
is consistent as well.如果您要重写 equals 方法并且仍然希望能够检查相等(或不等),那么您可能还应该重写 == 和 != 方法。
If you are overriding the equals method and still want to be able to check for equality (or inequality) then you should probably override the == and != methods as well.
这是可取的,因为如果出现以下情况,这将是意想不到的:
...行为与以下情况不同:
It would be advisable, as it would be unexpected if:
...behaved differently to:
没有必要,如果你不这样做,没有人会杀你。
但是,请注意,写 (A == B) 通常比写 A.Equals(B) 更自然。 如果您提供这两种方法,那么代码的使用者会更容易。
It is not necessary, nobody will kill you if you do not do that.
However, do notice that it is often more natural to write (A == B) than A.Equals(B). If you provide both methods, it will be easier for consumers of your code.
在 A.Equals(B) 中 A 不能为 null
A == B 中任意一个都可以为 null
in A.Equals(B) A cannot be null
in A == B either can be null
在我看来,重写 == 使其调用 Equals 对于引用类型来说通常是一个坏主意。 如果您重写 == 使其调用 Equals,那么我认为代码的用户没有办法测试两个对象引用是否引用完全相同的对象(而不是具有相同属性的对象)。
如果人们想要测试类的实例的值相等性,那么他们当然应该只调用 Equals,而保存 == 来专门测试引用相等性。
Overriding == to make it call Equals strikes me as a generally bad idea for reference types. If you override == to make it call Equals, then I don't think there's a way for a user of your code to test whether two object references refer to the exact same object (versus an object with equal properties).
If people want to test instances of your classes for value equality then surely they should just call Equals, saving == for testing reference equality specifically.
这不是必要的,但却是明智之举。
如果您正在创建一个框架,并且除您之外的其他开发人员要使用该对象,您应该覆盖 == 和 !=。 这样,当开发人员可以使用它时,他们至少有正确的逻辑来比较两个对象,而不仅仅是在内存中相同。
我会确保你的 == & != 请调用您的 equals 方法。
It is not necessary, but a smart thing to do.
If you are creating a framework and another developer other than you are going to use the object you should override the == and !=. That way when a developer may use it they at least have the right logic to compare the 2 objects rather than just are the same in memory.
I would ensure that your == & != do call your equals method.