不変オブジェクトのインターフェイスを宣言しないでください

不変オブジェクトのインターフェイスを宣言しないでください

[編集] 問題のオブジェクトがデータ転送オブジェクト（DTO）またはプレーンオールドデータ（POD）を表す場合

それは合理的なガイドラインですか？

これまで、不変の（データを変更できない）シールクラスのインターフェイスを作成することがよくありました。私は、不変性を気にするところにはインターフェースを使用しないように注意しました。

残念ながら、インターフェイスはコードに浸透し始めます（心配しているのは私のコードだけではありません）。インターフェースを渡された後、渡されるものが不変であると本当に想定したいコードにそれを渡したいと思うでしょう。

この問題のため、不変オブジェクトのインターフェイスを宣言しないことを検討しています。

これは単体テストに関して悪影響があるかもしれませんが、それ以外に、これは合理的なガイドラインに思えますか？

または、私が見ている「拡散インターフェース」の問題を回避するために使用すべき別のパターンがありますか？

（私はこれらの不変オブジェクトをいくつかの理由で使用しています：主にスレッドセーフのために、私は多くのマルチスレッドコードを書いていますが、それはまた、メソッドに渡されるオブジェクトの防御的なコピーの作成を避けることができるためです。コードは何かが不変であることを知っている多くの場合-インターフェイスを渡された場合はそうではありません。実際、インターフェイスを介して参照されるオブジェクトの防御コピーを作成することさえできません。クローン操作またはそれをシリアル化する方法...）

[編集]

オブジェクトを不変にしたいという私の理由により多くのコンテキストを提供するには、Eric Lippertの次のブログ投稿を参照してください。

http://blogs.msdn.com/b/ericlippert/archive/tags/immutability/

また、ここでは、マルチスレッドジョブキューで操作/受け渡しされるアイテムなど、いくつかの低レベルの概念で作業していることを指摘する必要があります。これらは本質的にDTOです。

また、Joshua Bloch は、著書Effective Javaで不変オブジェクトの使用を推奨しています。

ファローアップ

フィードバックをありがとう、すべて。先に進み、このガイドラインをDTOとその同類に使用することにしました。これまでのところ順調に機能していますが、1週間しか経っていません...それでも、見栄えは良いです。

これに関連する他の問題がいくつかあります。特に私が「ディープまたはシャロー不変性」と呼んでいるもの（ディープアンドシャロークローンから盗んだ命名法）-しかし、それはまた別の質問です。

私の意見では、あなたのルールは良いルール（または少なくとも悪いルールではありません）ですが、それはあなたが説明している状況のためだけです。私はすべての状況でこれに同意するとは言いませんので、私の内省者の観点から、あなたの規則は技術的に広すぎると言わざるを得ません。

通常、データ転送オブジェクト（DTO）として本質的に使用されない限り、不変オブジェクトは定義しません。つまり、データプロパティは含まれますが、ロジックはほとんどなく、依存関係はありません。その場合、ここにあるように見えるので、インターフェイスではなく具体的​​な型を直接使用しても安全だと思います。

意見が一致しない単体テストの純粋主義者もいるはずですが、私の意見では、DTOクラスは単体テストおよび依存関係注入の要件から安全に除外できます。DTOには依存関係がないため、ファクトリを使用してDTOを作成する必要はありません。必要に応じてすべてが直接DTOを作成する場合、とにかく別のタイプを注入する方法は実際にはないため、インターフェイスは必要ありません。そして、それらにはロジックが含まれていないため、ユニットテストを行う必要はありません。依存関係がない限り、何らかのロジックが含まれていても、必要に応じてロジックの単体テストを行うのは簡単です。

そのため、すべてのDTOクラスがインターフェイスを実装しないというルールを作成しても、潜在的に不要ではあるが、ソフトウェア設計を損なうことはないと思います。データは不変である必要があるという要件があり、インターフェイスを介してそれを強制することはできないため、その規則をコーディング標準として確立することは完全に正当であると言えます。

ただし、より大きな問題は、クリーンなDTOレイヤーを厳密に適用する必要があることです。インターフェイスなしの不変クラスがDTOレイヤーにのみ存在し、DTOレイヤーにロジックと依存関係がない限り、安全です。ただし、レイヤーの混合を開始し、ビジネスレイヤークラスを兼ねるインターフェイスのないクラスがある場合は、多くの問題が発生し始めると思います。

私は自分のコードを悪用し難くすることについて大騒ぎしていました。変化するメンバーを隠すための読み取り専用インターフェイスを作成し、一般的な署名などに多くの制約を追加しました。ほとんどの場合、想像上の同僚を信頼していなかったため、ほとんどの場合設計を決定しました。「おそらくいつか彼らは新しいエントリーレベルの人を雇うだろうし、クラスXYZがDTO ABCを更新できないことを彼は知らないだろう。他の場合、私は間違った問題に焦点を合わせていました-明らかな解決策を無視して-木を通して森を見ません。

DTOのインターフェイスを作成することはもうありません。私は、コードに触れる人々（主に自分自身）が何が許可され、何が理にかなっているかを知っているという仮定の下で働いています。私が同じ愚かな間違いを犯し続けている場合、私は通常、インターフェイスを強化しようとはしません。今、私はほとんどの時間を使って、なぜ同じ間違いを犯し続けるのかを理解しようとしています。それは通常、私が何かを分析しすぎているか、重要な概念を逃しているからです。妄想をあきらめたので、私のコードはずっと使いやすくなりました。また、システムで作業するためにインサイダーの知識が必要な「フレームワーク」が少なくなります。

私の結論は、最も単純なものを見つけることです。安全なインターフェイスを作成するために追加された複雑さは、開発時間を無駄にし、それ以外の場合は単純なコードを複雑にします。10,000人の開発者がライブラリを使用している場合、このようなことを心配してください。私を信じて、それは多くの不必要な緊張からあなたを救います。

大丈夫なガイドラインのようですが、奇妙な理由があります。インターフェース（または抽象基本クラス）が一連の不変オブジェクトへの均一なアクセスを提供する場所がいくつかありました。戦略はここに落ちる傾向があります。状態オブジェクトはここに落ちる傾向があります。インターフェースを不変に見えるように整形し、それをAPIにそのように文書化するのは理にかなっているとは思いません。

そうは言っても、人々は、Plain Old Data（以降、POD）オブジェクト、さらには単純な（多くの場合不変の）構造さえもオーバーインターフェースする傾向があります。コードに何らかの基本的な構造に対する適切な代替手段がない場合、インターフェイスは必要ありません。いいえ、ユニットテストはデザインを変更するのに十分な理由ではありません（データベースアクセスをモックすることは、インターフェイスを提供する理由ではなく、将来の変更に対する柔軟性です）-テストが世界の終わりではない基本的な基本構造をそのまま使用します。

何かが不変であることがわかっている場合、多くの場合、コードは非常に単純になります。これは、インターフェイスを渡された場合はそうではありません。

アクセサの実装者が心配する必要があるとは思いません。interface X不変であることが意図されている場合、不変の方法でインターフェースを実装することを保証するのは、インターフェース実装者の責任ではありませんか？

ただし、私の考えでは、不変のインターフェイスなどはありません。インターフェイスで指定されたコードコントラクトは、オブジェクトの公開されたメソッドにのみ適用され、オブジェクトの内部については何も適用されません。

インターフェースではなくデコレータとして実装された不変性を見るのが一般的ですが、そのソリューションの実現可能性はオブジェクトの構造と実装の複雑さに依存します。

インターフェースを渡された後、渡されるものが不変であると本当に想定したいコードにそれを渡したいと思うでしょう。

C＃では、「不変」型のオブジェクトを予期するメソッドは、C＃インターフェイスが不変性のコントラクトを指定できないため、インターフェイス型のパラメーターを持つべきではありません。したがって、あなたが提案しているガイドラインは、そもそもそれを行うことができないため、C＃では無意味です（そして、言語の将来のバージョンではそれを可能にする可能性は低いです）。

あなたの質問は、不変性に関するEric Lippertの記事の微妙な誤解から生じています。エリックはインターフェイスIStack<T>を定義せずIQueue<T>、不変のスタックとキューのコントラクトを指定しませんでした。彼らはしません。彼は便宜上それらを定義しました。これらのインターフェースにより、彼は空のスタックとキューに異なるタイプを定義することができました。単一の型を使用して、空のスタックを表すためにインターフェイスまたは別の型を必要としない不変スタックの異なる設計と実装を提案できますが、結果のコードはきれいに見えず、少し効率が悪くなります。

それでは、エリックのデザインにこだわりましょう。不変スタックを必要とするメソッドには、一般的な意味でスタックの抽象データ型を表すStack<T>一般的なインターフェースIStack<T>ではなく、型のパラメーターが必要です。Ericの不変スタックを使用するときにこれをどのように行うかは明らかではなく、彼は記事でこれについて議論しませんでしたが、可能です。問題は、空のスタックのタイプにあります。空のスタックを取得しないようにすることで、この問題を解決できます。これは、スタックの最初の値としてダミー値をプッシュし、決してポップしないことで保証できます。このように、あなたは安全の結果にキャストすることができますPushし、PopにをStack<T>。

持つStack<T>道具はIStack<T>便利です。スタック、任意のスタックを必要とするメソッドを定義できます。必ずしも不変スタックではありません。これらのメソッドは、typeのパラメーターを持つことができますIStack<T>。これにより、不変スタックを渡すことができます。理想的にIStack<T>は、標準ライブラリ自体の一部になります。.NETにはありませんIStack<T>が、不変スタックが実装できる他の標準インターフェイスがあり、型がより便利になります。

先ほど言及した不変スタックの代替設計と実装では、というインターフェイスを使用しますIImmutableStack<T>。もちろん、インターフェイス名に「Immutable」を挿入しても、それを実装するすべての型が不変になるわけではありません。ただし、このインターフェイスでは、不変性のコントラクトは単なる口頭です。優れた開発者はそれを尊重する必要があります。

小規模な内部ライブラリを開発している場合は、チームの全員に同意してこの契約を尊重しIImmutableStack<T>、パラメーターのタイプとして使用できます。それ以外の場合は、インターフェイスタイプを使用しないでください。

質問C＃にタグを付けたので、C＃仕様にはDTOやPODなどは存在しないことを付け加えます。したがって、それらを破棄するか、正確に定義すると、問題が改善されます。