StyleCopルールSA1600では、すべてのタイプメンバーに独自のドキュメントヘッダーが必要です。私はそれがかなり合理的だと思うし、私はこのルールが好きです。しかし、我々は次のような階層があるとします。ここではStyleCop SA1600ルールとインターフェイスの実現
/// <summary>
/// Documentation for interface ISomeModule.
/// </summary>
interface ISomeModule
{
/// <summary>
/// Documentation for DoA.
/// </summary>
void DoA();
/// <summary>
/// Documentation for DoB.
/// </summary>
void DoB();
}
/// <summary>
/// Documentation for StandardModule.
/// </summary>
class StandardModule : ISomeModule
{
private readonly SomeCoolType _value;
/// <summary>
/// Documentation for constructor.
/// </summary>
public StandardModule(SomeCoolType value)
{
_value = value;
}
// SA1600 violation here!
public void DoA()
{
// realisation of DoA().
}
// SA1600 violation here!
public void DoB()
{
// realisation of DoB().
}
/// <summary>
/// Documentation for MyOwnDoC.
/// </summary>
public void MyOwnDoC()
{
// realisation of MyOwnDoC().
}
}
を、私完全に文書化インタフェースのメンバーのDoA（）とDOB（）、私たちは、これらの方法では正確にインタフェースのドキュメントから何をすべきか知っています。 VS Intellisenceもそれを認識しており、クラスStandardModuleでもこれらのメソッドの上にマウスを置くことでメソッドの説明を見ることができます。したがって、インタフェースから派生クラスへ文書をコピーする必要はありません。しかし、StyleCopはそれを行うことを要求しています。どうして？誰か知っていますか？インターフェイスから
1.コピードキュメント：私たちは、この問題を解決しようとすると
、我々は4つの異なる道を行くことができます。 ここでの問題は、ドキュメントをコピーすると、インターフェイスの動作が変更された場合、派生したすべてのクラスのドキュメントを更新する問題が発生します。
2. SuppressMessageAttributeでメッセージを抑制します。 「Ok、私はSuppressMessageAttributeを使用できます」と言って、私が同意しないこの違反を抑止するとします。そして、ルールSA1600のために、SuppressMessageAttributeをクラスStandardModuleの先頭に追加します。しかし、StyleCopはStandardModuleクラスのドキュメンテーションヘッダーのチェックをやめます。コンストラクタや他のメソッドがあるので、私はそれを望んでいません。我々は2つの領域にクラスStandardModuleを分割のみインターフェイスISomeModuleを実装部にメッセージ抑制を使用することができる領域に
3分割クラス、 。そして、私はすべての部分を1つのファイルに配置する必要があると思います。私はこのアプローチが大好きです（＃4の方法の後）が、今は1つのクラスの複数の部分に対処する必要があります。
4.ルールSA1600を変更します。ルールSA1600の独自の実装を作成して、クラスメンバーが基本クラスまたはインタフェースで文書化されたかどうかを考慮に入れることは可能ですか？ （ここで私はStyleCopのための独自のルールを書くことができるかどうかは尋ねませんが、できることは分かりますが、StyleCopエンジンが一部のメンバーがインターフェースクラスかベースクラスかをチェックできるかどうかを意味します）。
インターフェイスの実現に関するSA1600の問題を解決する最も好ましい方法は何ですか？
+1よく書かれた質の高い質問です。 –