空のインターフェースはコード臭？[クローズド］

質問

同じ種類のオブジェクト（クエリの結果）を返す関数がありますが、共通のプロパティやメソッドがありません。共通の型を持つために、私は空のインターフェイスを戻り値の型として使用し、両方にそれを実装することをお勧めします。

もちろん、それは正しいとは言えません。私は、いつかこれらのクラスが共通の何かを持つようになり、その共通のロジックを私の空のインターフェイスに移すという希望にしがみつくことで、自分自身を慰めることしかできません。しかし、私は満足せず、2つの異なるメソッドを持ち、条件付きで次を呼び出すべきかどうか考えています。それはより良いアプローチでしょうか？

また、.NET Frameworkはタグ付けのために空のインターフェースを使用すると聞いたことがあります。

私の質問は、空のインターフェイスは設計上の問題の強い兆候なのか、それとも広く使われているのか、ということです。

EDIT : 興味のある方のために説明すると、関数型言語における判別済み共用体が、私が達成しようとしていたことの完璧な解決策であることが後でわかりました。C#はまだその概念にフレンドリーではないようです。

EDIT : を書きました。 長文 を書き、この問題と解決策を詳しく説明しました。

どのように解決するのですか？

そのユースケースのためのデザインパターン (多くの人が "marker interface" を挙げています) が存在するようですが、そのようなプラクティスの使用はコードの臭いの兆候であると思います (少なくともほとんどの場合)。

V4Vendetta が投稿したように、これをターゲットとした静的解析ルールがあります。 http://msdn.microsoft.com/en-us/library/ms182128(v=VS.100).aspx

もしあなたの設計が、型が実装することを期待される空のインターフェースを含んでいるなら、おそらくマーカーとして、または型のグループを識別する方法としてインターフェースを使用しているのでしょう。 この識別が実行時に行われる場合、これを達成するための正しい方法はカスタム属性を使用することです。 属性の有無、または属性のプロパティを使用して、対象の型を識別します。 もし識別がコンパイル時に行われなければならないのであれば、空のインターフェースを使ってもよいでしょう。

これはMSDNの勧告を引用したものです。

インターフェースを削除するか、それにメンバーを追加してください。空のインターフェースが型の集合をラベル付けするために使用されている場合、インターフェースをカスタム属性に置き換えてください。

これは、すでに投稿されているwikipediaのリンクのCritiqueの項目も反映しています。

マーカーインターフェースの大きな問題は、インターフェースは実装クラスの契約を定義し、その契約はすべてのサブクラスに継承されることです。これはつまり、マーカーを未実装にすることはできない、ということです。この例では、シリアライズしたくないサブクラスを作成した場合 (おそらく過渡的な状態に依存しているため)、明示的に NotSerializableException (ObjectOutputStream ドキュメントによる) をスローすることに頼るしかないでしょう。