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

К вашему сведению: Вы могли получить подобное поведение к тому, что Вы хотите путем создания дополнительных методов для интерфейса. Дополнительный метод был бы общим, не переопределяемым статическим поведением. Однако, к сожалению, этот статический метод не был бы частью контракта.

Я думаю, что короткий ответ, "потому что это имеет нулевую полноценность". Для вызова метода интерфейса Вам нужен экземпляр типа. От методов экземпляра можно назвать любые статические методы, Вы хотите.

Можно думать о статических методах и нестатических методах класса, как являющегося различными интерфейсами. Когда названо, статические методы разрешают к одиночному элементу статический объект класса, и нестатические методы решают к экземпляру класса, с которым Вы имеете дело. Так, при использовании статических и нестатических методов в интерфейсе Вы эффективно объявили бы два интерфейса, когда действительно мы хотим, чтобы интерфейсы использовались для доступа к одной связной вещи.

Интерфейсы являются абстрактными наборами определенной доступной функциональности.

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

, Если бы методы были определены столь же статичные, класс, реализовывая интерфейс столь не инкапсулировался бы, как это могло быть. Инкапсуляция является хорошей вещью бороться за в объектно-ориентированном проектировании (я не войду, почему, можно считать что здесь: http://en.wikipedia.org/wiki/Object-oriented ). Поэтому статические методы не разрешены в интерфейсах.

То, что Вы, кажется, хотите, позволило бы, чтобы статический метод был назван через обоих Типом или любым экземпляром того типа. Это самое малое привело бы к неоднозначности, которая не является желательной чертой.

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

Его также вероятный, что compilier, который соответствовал этому требованию, потеряет некоторые оптимизации, которые могут идти с более строгим разделением между методами экземпляра и статическими методами.

Поскольку интерфейсы находятся в структуре наследования, и статические методы не наследовались хорошо.

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

, Как Вы назвали бы его??

public interface MyInterface { void MyMethod(); }
public class MyClass: MyInterface
{
    public static void MyMethod() { //Do Something; }
}

 // inside of some other class ...  
 // How would you call the method on the interface ???
    MyClass.MyMethod();  // this calls the method normally 
                         // not through the interface...

    // This next fails you can't cast a classname to a different type... 
    // Only instances can be Cast to a different type...
    MyInterface myItf = MyClass as MyInterface;  

Моя (упрощенная) техническая причина - то, что статические методы не находятся в vtable, и сайт вызова выбран во время компиляции. Это - та же причина, у Вас не может быть переопределения или виртуальных статических участников. Для получения дополнительной информации Вам были бы нужны градиент CS или зубрила компилятора - из которых я не ни один.

По политической причине, я буду кавычка Eric Lippert (кто зубрила компилятора и держит бакалавра математических наук, Информатику и Прикладную математику из Университета Уотерлу (источник: LinkedIn):

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

Примечание, что Lippert действительно оставляет комнату для так называемого метода типа:

таким образом, метод, связанный с типом (как помехи), который не берет не допускающий NULL-значения “this” аргумент (в отличие от экземпляра или виртуальный), но тот, где названный метод зависел бы от созданного типа T (в отличие от помех, которые должны быть определимыми во время компиляции).

, но должен все же быть убежден в его полноценности.

Интерфейсы определяют поведение объекта.

Статические методы не определяют поведение объекта, но поведение, которое влияет на объект в некотором роде.

Для предоставления примера, где я пропускаю или статическую реализацию методов интерфейса или что Mark Brackett представил как "так называемый метод типа":

При чтении из устройства хранения данных базы данных, у нас есть универсальный класс DataTable, который обрабатывает чтение из таблицы любой структуры. Определенная информация всей таблицы помещается в один класс на таблицу, которая также содержит данные для одной строки от DB и которая должна реализовать интерфейс IDataRow. Включенный в IDataRow описание структуры таблицы для чтения из базы данных. DataTable должен попросить datastructure от IDataRow прежде, чем читать из DB. В настоящее время это похоже:

interface IDataRow {
  string GetDataSTructre();  // How to read data from the DB
  void Read(IDBDataRow);     // How to populate this datarow from DB data
}

public class DataTable<T> : List<T> where T : IDataRow {

  public string GetDataStructure()
    // Desired: Static or Type method:
    // return (T.GetDataStructure());
    // Required: Instantiate a new class:
    return (new T().GetDataStructure());
  }

}

GetDataStructure только требуется однажды, чтобы каждая таблица читала, издержки для инстанцирования еще одного экземпляра минимальны. Однако это было бы хорошо в этом случае здесь.