Чому C # не дозволяє статичним методам реалізувати інтерфейс?

Чому 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;
    }

    ....

 }

Припускаючи, що ви запитуєте, чому ви не можете цього зробити:

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 blob, і вважаю це свідченням того, що це може бути не бути гарною ідеєю.

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

З політичної причини я наводжу Еріка Ліпперта (який є компілятором, який мав бакалавр математики, інформатики та прикладної математики з Університету Ватерлоо (джерело: LinkedIn ):

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

Зауважте, що Ліпперт залишає місце для так званого методу типу:

Тобто метод, пов'язаний з типом (наприклад, статичним), який не приймає ненульовий аргумент «цей» (на відміну від екземпляра чи віртуальної), але той, де названий метод залежатиме від побудованого типу 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...
    }
  }
}

Це очевидно негарно, а також непотрібно ускладнює код для всіх інших методів. Очевидно, і не елегантне рішення!

Я знаю, що це старе питання, але цікаво. Приклад - не найкращий. Я думаю, що було б набагато зрозуміліше, якби ви показали випадок використання:

рядок DoSomething <T> (), де T: ISomeFunction
{
  якщо (T.someFunction ())
    ...
}

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

1. Створіть статичний загальний клас, параметр типу якого буде типом, який ви переходите до DoSomething вище. Кожна зміна цього класу матиме один або більше статичних членів, що містять речі, пов'язані з цим типом. Ця інформація може бути надана або за допомогою кожного класу, що цікавить, викликати процедуру "реєстрації інформації", або за допомогою Reflection, щоб отримати інформацію, коли запускається статичний конструктор зміни класу. Я вважаю, що останній підхід використовується такими речами, як Порівняння <T> .Default ().
2. Для кожного цікавого класу T визначте клас або структуру, яка реалізує IGetWeverClassInfo <T> і задовольняє "нове" обмеження. Клас насправді не містить жодних полів, але матиме статичну властивість, яка повертає статичне поле з інформацією про тип. Передайте тип цього класу або структури відповідній загальній процедурі, яка зможе створити екземпляр і використовувати його для отримання інформації про інший клас. Якщо ви використовуєте клас для цієї мети, вам, мабуть, слід визначити статичний загальний клас, як зазначено вище, щоб уникнути необхідності кожного разу створювати новий екземпляр-дескриптор-об'єкт. Якщо ви використовуєте структуру, вартість інстанції повинна бути нульовою, але кожен різний тип структури вимагає різного розширення програми DoSomething.

Жоден із цих підходів не є дійсно привабливим. З іншого боку, я б очікував, що якби існували механізми 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;
    }
}

Вже було багато розмов про те, щоб зробити ІАрифметику для всіх числових типів для реалізації, але існує стурбованість ефективністю, оскільки обмеження не є поліморфною конструкцією, внаслідок чого обмеження CArithmetic вирішило б цю проблему.

Оскільки інтерфейси є в структурі успадкування, а статичні методи не успадковують добре.

Те, що ви, здається, хочете, дозволить викликати статичний метод як через Тип, так і будь-який примірник цього типу. Це принаймні призведе до неоднозначності, що не є бажаною ознакою.

Були б нескінченні дебати про те, чи має це значення, що є найкращою практикою та чи є проблеми з ефективністю, що роблять це так чи інакше. Просто не підтримуючи його, C # рятує нас від цього турбуватися.

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

Ви можете вважати статичні методи та нестатичні методи класу як різні інтерфейси. При виклику статичні методи вирішаються до однотонного об’єкта статичного класу, а нестатичні - до екземпляра класу, з яким ви маєте справу. Отже, якщо ви використовуєте статичні та нестатичні методи в інтерфейсі, ви ефективно оголосите два інтерфейси, коли ми дійсно хочемо, щоб інтерфейси використовувались для доступу до однієї згуртованої речі.

Наведіть приклад, коли мені не вистачає статичної реалізації методів інтерфейсу, або що ввів Марк Брокетт як "так званий тип методу":

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

FYI: Ви можете отримати подібну поведінку до бажаної, створивши методи розширення інтерфейсу. Метод розширення буде загальною статичною поведінкою, що не перезаписується. Однак, на жаль, цей статичний метод не був би частиною контракту.

Інтерфейси - це абстрактні набори визначених доступних функціональних можливостей.

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

Якби методи були визначені як статичні, клас, що реалізує інтерфейс, був би не таким інкапсульованим, як міг би бути. Інкапсуляція - це хороша річ, на яку слід прагнути в об'єктно-орієнтованому дизайні (я не буду вникати в це, чому ви можете прочитати це тут: http://en.wikipedia.org/wiki/Object-oriented ). З цієї причини статичні методи не дозволені в інтерфейсах.

Статичні класи повинні бути в змозі це зробити, щоб їх можна було використовувати в загальних рисах. Я повинен був замість цього застосувати Singleton, щоб досягти бажаних результатів.

У мене було безліч класів статичного бізнес-шару, які реалізовували методи CRUD, такі як "Створити", "Прочитати", "Оновити", "Видалити" для кожного типу об'єктів, таких як "Користувач", "Команда", тощо. Потім я створив базу контроль, який мав абстрактне властивість для класу Business Layer, який реалізував методи CRUD. Це дозволило мені автоматизувати операції "Створити", "Прочитати", "Оновити", "Видалити" з базового класу. Мені довелося використовувати Singleton через статичне обмеження.

Більшість людей, здається, забувають, що в класах OOP теж є об'єкти, і тому у них є повідомлення, які чомусь 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);
}

В даний час я пишу статичні класи, які містять ці методи, без будь-якої перевірки, щоб переконатися, що я нічого не забув. Це як погані старі часи програмування перед OOP.

C # і CLR повинні підтримувати статичні методи в інтерфейсах, як це робить Java. Статичний модифікатор є частиною визначення контракту і має значення, зокрема, те, що поведінка і значення повернення не залежать від базового примірника, хоча він все ще може змінюватись від виклику до виклику.

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

Я вважаю, що коротка відповідь "тому, що вона нульова". Щоб викликати метод інтерфейсу, вам потрібен примірник типу. З методів екземпляра ви можете викликати будь-які статичні методи, які ви хочете.

Я думаю, що питання виникає в тому, що 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 # не можна було "модернізувати" для підтримки контрактів (інтерфейсів) статичних методів.

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