Equalsメソッドと等値演算子(==)の実装、つまり等価比較について自分の理解が怪しかったので改めてまとめてみました。
きっかけは @xin9le さんのこちらのツイートです。
えー、EqualsとかGetHashCodeなんて滅多にオーバーライドしないけどなーwslideshare.net/bleistift/bett…
— じんぐるさん (@xin9le) 11月 25, 2012
私は謂わいる ValueObject の実装で、よく値比較のクラスを作るために Equals(とGetHashCode) をもりもり実装していたので、「なんか自分間違ってるのかも!?」と心配になりました。
- ドメイン駆動設計・アプリケーション構築編・値オブジェクト - Strategic Choice
- Value Object(バリューオブジェクト) - Strategic Choice
- Value Objects パターン あれこれ | システム設計日記
はじめに
まずはじめにEqualsメソッドや等値演算子(==)の実装について、仕組みや注意点、実装ポリシーをおさらいです。以下の記事が大変参考になります。
Equalsメソッドと等値演算子の実装には、いくつかのケースが考えられるので、それぞれ見ていきたいと思います。
値型の等価比較について
値型のEqualsメソッドをオーバーライドしない場合、既定の実装(ValueTypeの実装)により、定義された各フィールドの等価性を調べるように実装されています。
ただし、この比較はリフレクションを用いて行われるので、パフォーマンスが求められる場合は自分でEqualsメソッドをオーバーライドして実装する必要があります。
(参考:値型については equals と等値演算子をオーバーライドします)
また、値型でEqualsメソッドを実装する場合は、等値演算子を実装する必要があります。この場合、Equalsメソッドと等値演算子は同じ結果を返すようにします。
このように値型の等価比較はあまり複雑なことはありません。通常、値型を作成する場合は、Equalsメソッドと等値演算子を合わせて実装するのが良いようです。
話がややこしくなってくるのは、参照型の場合です。
参照型の等価比較について
参照型のEqualsメソッドは、既定の実装では参照の等価性を評価します。
また、等値演算子も同様に参照の等価性を評価します。(参照型なので当然ですね)
しかし、参照型でも値の比較によって等価性を評価する場合があります。
例えば、文字列型(string)は参照型ですが、Equalsメソッドも等値演算子も値の比較で等価性を評価するように実装されています。
これは参照型であっても、文字列型(string)は値のような特性を持つためにこのようになっています。(たぶん)
文字列型(string)が参照比較だった場合、直感的な挙動でなくなると思うので、なんとなくやりづらそうです。
値型と参照型の選択
「じゃあややこしいから値っぽい型は全部値型でいいじゃん!」と思うわけですが、そういうわけにもいかない事情があります。
値型は代入時にコピーされるので、サイズが大きいと高コストになってしまいます。(逆にサイズが十分小さいなら値型のほうが高速です)
また、ボックス化やボックス化解除が頻繁に発生する場合も高コストになります。
そうなると、値のような特性を持つ型でも、サイズが大きい、ボックス化がよく起きる、というようなケースでは参照型のほうが適切になります。(stringはサイズが大きいですね)
まとめ
というわけで、値のような特性を持つ型については、参照型でもEqualsや等値演算子を実装するケースはあります。
ただ「じゃあそれってどのくらいあるの?」となると、私の想像できる範囲だと最初に挙げた ValueObject くらいしか思いつきません。
なので、そういったオブジェクトを作る必要がなければ、実装することはあまりなさそうです。
あと、Equalsの実装にはGetHashCodeを合わせて実装する必要がありますし、その際にも気をつける必要のある実装ポリシーがいろいろあって、なかなか大変です。
なんとなく自分の理解がそれほど外れた所になさそうな気がして一安心ですが、あまり深く考えずにバシバシ参照型で ValueObject を作っていたので、値型で作ったほうが適切でないか見直しが必要そうです。
あと、Equalsを実装する場合は、タイプセーフに比較できる IEquatable<T> インターフェイスを積極的に使ったほうがよさそうです。
0 件のコメント:
コメントを投稿