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

Предполагая, что вы спрашиваете, почему вы не можете этого сделать:

public interface IFoo {
    void Bar();
}

public class Foo: IFoo {
    public static void Bar() {}
}

Для меня это не имеет смысла семантически. Методы, указанные в интерфейсе, должны быть там, чтобы указать контракт для взаимодействия с объектом. Статические методы не позволяют вам взаимодействовать с объектом - если вы окажетесь в положении, когда ваша реализация может быть статической, вам может потребоваться спросить себя, действительно ли этот метод принадлежит интерфейсу.

public class Animal: IListItem {
    /* Can be tough to come up with a different, yet meaningful name!
     * A different casing convention, like Java has, would help here.
     */
    public const string AnimalScreenName = "Animal";
    public string ScreenName(){ return AnimalScreenName; }
}

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

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

По политическим причинам я цитирую Эрика Липперта (который разбирается в компиляторах и имеет степень бакалавра математики, информатики и прикладной математики Университета Ватерлоо (источник: LinkedIn):

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

Обратите внимание, что Липперт оставляет место для так называемого метода типа:

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

но еще предстоит убедиться в его полезности.

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

Предположим, у нас есть параметр типа в универсальном методе, и нам нужно проделать с ним некоторую операцию. Мы не хотим мгновенно создавать, потому что не знаем конструкторов.

Например:

Repository GetRepository<T>()
{
  //need to call T.IsQueryable, but can't!!!
  //need to call T.RowCount
  //need to call T.DoSomeStaticMath(int param)
}

...
var r = GetRepository<Customer>()

К сожалению, я могу придумать только уродливые альтернативы:

• Используйте отражение. Уродливая идея, превосходящая идею интерфейсов и полиморфизма.

• Создайте полностью отдельный класс фабрики

  Это может значительно увеличить сложность кода. Например, если мы пытаемся моделировать объекты предметной области, каждому объекту потребуется другой класс репозитория.

• Создайте экземпляр, а затем вызовите нужный метод интерфейса

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

Пример:

public class Customer 
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  void SomeOtherMethod() 
  { 
    //do work...
  }
}

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

public class Customer: IDoSomeStaticMath
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  //dummy instance
  public Customer() { IsDummy = true; }

  int DoSomeStaticMath(int a) { }

  void SomeOtherMethod() 
  { 
    if(!IsDummy) 
    {
      //do work...
    }
  }
}

Это, очевидно, некрасиво, а также излишне усложняет код для всех других методов. Очевидно, это тоже не изящное решение!

Я знаю, что это старый вопрос, но он интересный. Пример не лучший. Думаю, было бы намного понятнее, если бы вы показали пример использования:

string DoSomething<T>() where T:ISomeFunction
{
  if (T.someFunction())
    ...
}

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

1. Create a static generic class whose type parameter will be the type you'd be passing to DoSomething above. Each variation of this class will have one or more static members holding stuff related to that type. This information could supplied either by having each class of interest call a "register information" routine, or by using Reflection to get the information when the class variation's static constructor is run. I believe the latter approach is used by things like Comparer<T>.Default().
2. For each class T of interest, define a class or struct which implements IGetWhateverClassInfo<T> and satisfies a "new" constraint. The class won't actually contain any fields, but will have a static property which returns a static field with the type information. Pass the type of that class or struct to the generic routine in question, which will be able to create an instance and use it to get information about the other class. If you use a class for this purpose, you should probably define a static generic class as indicated above, to avoid having to construct a new descriptor-object instance each time. If you use a struct, instantiation cost should be nil, but every different struct type would require a different expansion of the DoSomething routine.

Ни один из этих подходов не выглядит привлекательным. С другой стороны, я ожидал бы, что если бы в CLR существовали механизмы для чистого обеспечения такого рода функциональности, .net позволил бы указать параметризованные «новые» ограничения (поскольку знание того, имеет ли класс конструктор с определенной сигнатурой, казалось бы быть сопоставимым по сложности со знанием того, есть ли у него статический метод с определенной сигнатурой).

Думаю, близорукость.

При первоначальной разработке интерфейсы предназначались только для использования с экземплярами класса

IMyInterface val = GetObjectImplementingIMyInterface();
val.SomeThingDefinedinInterface();

Только с введением интерфейсов в качестве ограничений для дженериков добавление статического метода к интерфейсу имело практическое применение.

(отвечает на комментарий :) Я считаю, что для его изменения сейчас потребуется изменение CLR, что приведет к несовместимости с существующими сборками.

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

Все вышеперечисленные аргументы, похоже, упускают из виду этот пункт о контрактах.

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

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

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

Как бы вы это назвали ??

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;  

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

T SumElements<T>(T initVal, T[] values)
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

Здесь нет полиморфизма, универсальный использует фактический тип объекта и вызывает оператор + =, но это не удается, поскольку он не может точно сказать, что этот оператор существует. Простое решение - указать это в ограничении; простое решение невозможно, потому что операторы являются статическими, а статические методы не могут быть в интерфейсе и (вот в чем проблема) ограничения представлены как интерфейсы.

Что нужно C #, так это реальный тип ограничения, все интерфейсы также будут ограничениями, но не все ограничения будут интерфейсами, тогда вы могли бы сделать это:

constraint CHasPlusEquals
{
    static CHasPlusEquals operator + (CHasPlusEquals a, CHasPlusEquals b);
}

T SumElements<T>(T initVal, T[] values) where T : CHasPlusEquals
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

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

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

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

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

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

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

Приведу пример, в котором мне не хватает либо статической реализации методов интерфейса, либо того, что Марк Брэкетт представил как «так называемый метод типа»:

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

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 требуется только один раз для чтения каждой таблицы, накладные расходы на создание еще одного экземпляра минимальны. Впрочем, здесь было бы неплохо в данном случае.

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

Интерфейсы - это абстрактные наборы определенных доступных функций.

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

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

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

У меня было несколько классов статического бизнес-уровня, в которых реализованы методы CRUD, такие как «Create», «Read», «Update», «Delete» для каждого типа сущности, такого как «User», «Team» и т. Д. Затем я создал базу элемент управления, имеющий абстрактное свойство для класса бизнес-уровня, реализующего методы CRUD. Это позволило мне автоматизировать операции «Создать», «Прочитать», «Обновить», «Удалить» из базового класса. Мне пришлось использовать Singleton из-за статического ограничения.

Большинство людей, кажется, забывают, что в ООП классы тоже являются объектами, и поэтому у них есть сообщения, которые по какой-то причине C # вызывает «статический метод». Тот факт, что существуют различия между объектами экземпляра и объектами класса, только указывает на недостатки языка. Хотя оптимист по поводу C # ...

Хорошо, вот пример необходимости «метода типа». Я создаю один из набора классов на основе некоторого исходного XML. Так что у меня есть

  static public bool IsHandled(XElement xml)

функция, которая вызывается по очереди для каждого класса.

Функция должна быть статической, иначе мы тратим время на создание неподходящих объектов. Как отмечает @Ian Boyde, это можно сделать в фабричном классе, но это только добавляет сложности.

Было бы неплохо добавить его в интерфейс, чтобы заставить разработчиков классов реализовать его. Это не вызовет значительных накладных расходов - это всего лишь проверка времени компиляции / компоновки и не влияет на vtable.

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

Так что это второстепенная потенциальная функция, которую в конечном итоге, вероятно, лучше не учитывать.

Тот факт, что статический класс реализован на C # путем создания Microsoft специального экземпляра класса со статическими элементами, является лишь странностью того, как достигается статическая функциональность. Это не теоретический момент.

Интерфейс ДОЛЖЕН быть дескриптором интерфейса класса - или того, как он взаимодействует, и это должно включать статические взаимодействия. Общее определение интерфейса (от Meriam-Webster): место или область, в которой разные вещи встречаются и взаимодействуют друг с другом или влияют друг на друга. Когда вы полностью опускаете статические компоненты класса или статические классы, мы игнорируем большие части того, как эти плохие парни взаимодействуют.

Вот очень наглядный пример того, где было бы весьма полезно использовать интерфейсы со статическими классами:

public interface ICrudModel<T, Tk>
{
    Boolean Create(T obj);
    T Retrieve(Tk key);
    Boolean Update(T obj);
    Boolean Delete(T obj);
}

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

C # и CLR должны поддерживать статические методы в интерфейсах, как это делает Java. Модификатор static является частью определения контракта и имеет значение, в частности, поведение и возвращаемое значение не меняются в зависимости от экземпляра, хотя они могут по-прежнему меняться от вызова к вызову.

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

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

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

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

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

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

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

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

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

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

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

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

Статические методы в интерфейсе разрешены начиная с C # 9 (см. https://www.dotnetcurry.com/csharp/simpler-code-with-csharp-9).

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