「継承型」から「静的メンバー」にアクセスすると便利なのはなぜですか？

Question

C＃では静的メンバーにアクセスすることはできません 'インスタンスメンバーだったようです。これは、Javaで一般的なバグ回避：一方

Thread t = new Thread(..); 
t.sleep(..); //Probably doesn't do what the programmer intended. 

を、それあなたが派生型「を介して」静的メンバにアクセスしてみましょうありません。演算子（キャストを書くことからあなたを救う）以外に、これが実際に役に立ちそうなケースは考えられません。実際には、それは積極的のような過ち奨励：;私は、エディタでBinaryExpression.を打つ私は式ツリーをオフに始まる覚えて（不慣れなAPIを介して自分の道を探していたときに

// Nasty surprises ahead - won't throw; does something unintended: 
// Creates a HttpWebRequest instead. 
var ftpRequest = FtpWebRequest.Create(@"http://www.stackoverflow.com"); 

// Something seriously wrong here. 
var areRefEqual = Dictionary<string, int>.ReferenceEquals(dict1, dict2); 

を私は個人的に何度も同様のエラーを犯し続けますなぜ地球上でIntelliSenseが私にオプションとしてMakeUnaryを提供していたのだろうと思っていた）。私（近視眼）の意見では

、この機能：

1. 冗長性を低下させません。 （現在の型の継承された静的メンバーにアクセスする際の演算子やケースを除いて）プログラマは型名を一方向に指定する必要があります。
2. 上記のようなバグや誤解を招くようなコードを奨励します。
3. C＃の静的メソッドは、多態性がある場合は、多様性を示していることをプログラマに示唆するかもしれません。
4. （マイナー）再コンパイル時に意図しないリビジョンの可能性がある「サイレント」を導入します。

（IMO、事業者が自らの議論を保証する特殊なケースです。）

C＃は、通常、この機能が存在しない理由「ピット成功の」言語、であることを考えると？私はその利点（IDEでいつでも解決できる「発見可能性」以外）を見ることはできませんが、私は多くの問題を抱えています。

Answer 1

私はこれが間違っていると思います。 実行の面で無害ながら、コードを読み取るという点で誤解を招く恐れがあり、

ASCIIEncoding.ASCII 

等...：私は、スタックオーバーフロー上の誰かがのコードを掲載している頻度を知りません。

明らかに、この「機能」を削除するのは遅すぎますが、C＃チームはこの問題やその他のスタイルの問題に対して超冗長な警告モードを導入できると思います。

たぶんC＃の後継者は物事を改善します...

Answer 2

これは、WinFormsのに有用です。任意のコントロールまたはフォームで

、あなたはControlから継承されたstaticメンバーを使用するMousePosition、MouseButtons、またはModifierKeysを書くことができます。

それは良い決定かどうかは議論の余地があります。