Resharper 4.1を使用して、私はこの興味深い警告に遭遇しました。「派生型を介して型の静的メンバーにアクセスする」派生型でクラスの静的メンバーを使用していますか？
がclass A {
public static void SomethingStatic() {
//[do that thing you do...]
}
}
class B : A {
}
class SampleUsage {
public static void Usage() {
B.SomethingStatic(); // <-- Resharper warning occurs here
}
}
は誰もが知っていますが発行するものです（もしあれば）Bを経由してAの静的メンバを使用する際：ここでこの問題が発生した場所のコードサンプルはありますか？
誤解を招く恐れがある箇所は、静的がファクトリメソッドである場合です。 WebRequestクラスはファクトリメソッドCreateを持ちます。このメソッドは、派生クラスを介してアクセスする場合にこのタイプのコードを書き込むことができます。ここでrequest
var request = (FtpWebRequest)HttpWebRequest.Create("ftp://ftp.example.com");
はタイプFtpWebRequestのですが、それはCreate方法が実際にWebRequest（基底クラス）で定義されていても、それがHttpWebRequest（兄弟クラス）に基づいて作成されたもののように見えるので、それは混乱です。次のコードの意味では同じですが、より明確である：
var request = (FtpWebRequest)WebRequest.Create("ftp://ftp.example.com");
は、最終的に派生型を経由して、静的にアクセスする重大な問題はありませんが、コードは、多くの場合、そうではないことで明確です。
これは警告ではなく、通常は単なる提案です。不必要に何かに依存関係を作り出しています。
BがBを継承する必要がないと判断したとします。Resharperのアドバイスに従うと、そのコード行を変更する必要はありません。
インスタンスメソッドでも同じ問題が発生します。このすべての論理によって、なぜ何かを継承しますか？ か何か不足していますか？ – NullVoxPopuli
@NullVoxPopuli - 実装の継承を完全に避けることを推奨する人がいます。いくつかのよく知られているJavaとC＃の本がこれを示唆しています（この記事も参照してください：http://www.isase.us/wisr3/7.pdf）。しかし、いずれにしても、インスタンスメソッド 'Foo'を' A'に入れ、変数 'b'によって参照される' B'のインスタンスが与えられた場合、静的関数と同じ自由度はありません「どこで」「Foo」を調べるべきかを言う。あなたが何をしていても、あなたは 'b'で始まらなければなりません。だから静的と同じではありません。 –
ええ私もこれを見てきました。 A.SomethingStatic();も同じことをします。
B.SomethingStatic()は、SomethingStaticがBのメンバーであるという発言をします。本当じゃない。 SomethingStaticは、Aのメンバーであることは間違いありません。 Bのメンバ（例えば、Bのメンバーであるかのように）に無条件にアクセスできるということは、便宜上の問題です。 Bで認定されたときにアクセス可能であるという事実は、IMO、間違いです。
+1あなたの説明はここで最高のものです。 –
サブクラスは常にスーパークラスのすべてのプロパティを継承する必要があると思います。特に私が今行っているプロジェクトでは、工場パターンに役立つスーパーです。 – NullVoxPopuli
私は同意しません。私は、現在の行動が有益な場合に有効なケースを持っています。'class Validator：ValidatorBase
これは私が以前考えたことのない問題です。おかげでグレッグ！ – Swim
良い例で、きれいで分かりやすい説明。 – serg10
大きな説明は、本当に役に立ちました。グーグルでの最初の結果^^ – marcgg