为什么通过inheritance类型访问静态成员是有用的？
我很高兴C＃不允许你访问静态成员，就像’他们是实例成员一样。 这避免了Java中的常见错误：
Thread t = new Thread(..); t.sleep(..); //Probably doesn't do what the programmer intended. 另一方面，它允许您通过’派生类型访问静态成员。 除了运算符（它可以让你免于编写演员表），我无法想到任何实际上有用的情况。 事实上，它积极鼓励错误，例如：
// 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.ReferenceEquals(dict1, dict2);
当我通过不熟悉的API搜索时，我个人不断地反复提出类似的错误（我记得从表达树开始;我在编辑器中点击BinaryExpression.并且想知道为什么地球上的IntelliSense提供MakeUnary作为选项）。
在我的（短视）意见中，此function：
- 不减少冗长; 程序员必须以某种方式指定类型名称（当访问当前类型的inheritance静态成员时，不包括运算符和大小写）。
- 鼓励上面提到的错误/误导性代码。
- 可以向程序员建议C＃中的静态方法表现出某种“多态性”，而不是。
- （次要）在重新编译时引入’沉默’，可能是无意的重新绑定可能性。
（国际海事组织，运营商是一个特殊情况，值得他们自己讨论。）
鉴于C＃通常是“成功的一块”语言，为什么这个function存在？ 我看不到它的好处（除了’可发现’，它总是可以在IDE中解决），但我看到很多问题。
我同意这是一种错误。 我不知道Stack Overflow上有人发布了以下代码：
ASCIIEncoding.ASCII
等……虽然在执行方面无害，但在阅读代码方面却有误导性。
显然现在删除这个“function”为时已晚，尽管我猜C＃团队可以为这个和其他样式问题引入一个超级详细的警告模式。
也许C＃的继任者将改善事物……
这在WinForms中很有用。
在任何控件或表单中，您可以编写MousePosition ， MouseButtons或ModifierKeys来使用从Controlinheritance的static成员。
这是否是一个好的决定仍然存在争议。