Я рад, что 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<string, int>.ReferenceEquals(dict1, dict2);
Я лично продолжаю совершать подобные ошибки снова и снова, когда я ищу свой путь через незнакомые API (я помню, как начинал с деревьев выражений; я нажимал BinaryExpression. в редакторе и ему было интересно, почему IntelliSense предлагал мне MakeUnary в качестве опции).
По моему (близорукому) мнению, эта функция:
- Неуменьшить многословие;программист должен указать имя типа тем или иным образом (исключая операторы и случаи, когда кто-то обращается к унаследованным статическим членам текущего типа).
- Поощряет ошибки / вводящий в заблуждение код, такой как приведенный выше.
- Может предложить программисту, что статические методы в C # демонстрируют своего рода «полиморфизм», когда они этого не делают.
- (Незначительно) Вводит «тихие», возможно, непреднамеренные возможности повторного связывания при перекомпиляции.
(IMO, операторы - это особый случай, требующий собственного обсуждения.)
Учитывая, что C # обычно является языком «ямы успеха», почему эта функция существует?Я не вижу его преимуществ (кроме «обнаруживаемости», которую всегда можно решить в IDE), но вижу много проблем.