Почему C # не позволяет статическим методам реализовать интерфейс?

Question

Почему C # был разработан таким образом?

Насколько я понимаю, интерфейс только описывает поведение и служит для описания договорных обязательств для классов, реализующих интерфейс, в котором реализовано определенное поведение.

Если классы хотят реализовать это поведение в общем методе, почему бы и нет?

Вот пример того, что я имею в виду:

// These items will be displayed in a list on the screen.
public interface IListItem {
  string ScreenName();
  ...
}

public class Animal: IListItem {
    // All animals will be called "Animal".
    public static string ScreenName() {
        return "Animal";
    }
....
}

public class Person: IListItem {

    private string name;

    // All persons will be called by their individual names.
    public string ScreenName() {
        return name;
    }

    ....

 }

Answer 1

Концептуально нет никаких причин, по которым интерфейс не может определить контракт, который включает статические методы.

Для текущей реализации языка C # ограничение связано с разрешением наследования базового класса и интерфейсов. Если «класс SomeBaseClass» реализует «интерфейс ISomeInterface» и «класс SomeDerivedClass: SomeBaseClass, ISomeInterface» также реализует интерфейс, статический метод для реализации метода интерфейса может не скомпилироваться, поскольку статический метод не может иметь такую ​​же сигнатуру, как метод экземпляра (что присутствовать в базовом классе для реализации интерфейса).

Статический класс функционально идентичен синглтону и служит для той же цели, что и синглтон с более чистым синтаксисом. Поскольку синглтон может реализовывать интерфейс, реализации интерфейса с помощью статики концептуально допустимы.

Таким образом, это просто сводится к ограничению конфликта имен в C #, например, и статических методов с одним и тем же именем в наследовании. Нет причин, по которым C # не может быть «обновлен» для поддержки контрактов (интерфейсов) статических методов.

Answer 2

Когда класс реализует интерфейс, он создает экземпляр для членов интерфейса. Хотя статический тип не имеет экземпляра, нет смысла иметь статические подписи в интерфейсе.

Answer 3

Согласно объектно-ориентированной концепции Интерфейс, реализуемый классами и иметь контракт для доступа к этим реализованным функциям (или методам), используя объект.

Итак, если вы хотите получить доступ к методам Interface Contract, вам нужно создать объект. Это всегда должно быть запрещено в случае статических методов. Статические классы, методы и переменные никогда не требуют объектов и загружаются в память без создания объекта этой области (или класса), или, можно сказать, не требуют создания объектов.

Answer 4

Я думаю, что вопрос заключается в том, что C # нуждается в другом ключевом слове, именно для такой ситуации. Вам нужен метод, возвращаемое значение которого зависит только от типа, для которого он вызывается. Вы не можете назвать это «статическим», если указанный тип неизвестен. Но как только тип станет известным, он станет статичным. «Неразрешенная статика» - это идея - она ​​еще не статична, но как только мы узнаем тип приема, он будет. Это очень хорошая концепция, поэтому программисты постоянно просят об этом. Но это не совсем соответствовало тому, как дизайнеры думали о языке.

Поскольку он недоступен, я привык использовать нестатические методы, как показано ниже. Не совсем идеально, но я не вижу подходов, которые имеют больше смысла, по крайней мере, не для меня.

public interface IZeroWrapper<TNumber> {
  TNumber Zero {get;}
}

public class DoubleWrapper: IZeroWrapper<double> {
  public double Zero { get { return 0; } }
}

Answer 5

Я думаю, что краткий ответ - «потому что он бесполезен». Чтобы вызвать метод интерфейса, вам нужен экземпляр типа. Из методов экземпляра вы можете вызывать любые статические методы, которые хотите.