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

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

Позволь мне объяснить.

Ранее в C #, если объект реализовывал IEnumerableинтерфейс, он был бы автоматически повторяем foreachциклом. Это имеет смысл для меня, так как он поддерживается интерфейсом, и если бы у меня была собственная Iteratorфункция внутри класса, через которую итерируется, я мог бы сделать это, не беспокоясь о том, что это волшебным образом будет означать что-то другое.

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

Другой пример - сделать любой объект ожидаемым, если у него будет метод с точным именем ,GetAwaiter который имеет несколько специфических свойств.

Почему бы не создать интерфейс, подобный тому, как они это сделали, IEnumerableили INotifyPropertyChangedстатически поддержать эту «магию»?

Подробнее о том, что я имею в виду здесь:

http://blog.nem.ec/2014/01/01/magic-methods-c-sharp/

Каковы плюсы и минусы магических методов, и есть ли где-нибудь в Интернете, где я могу найти что-нибудь о том, почему эти решения были приняты?

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

Когда foreachон впервые появился в C # 1.0 (такое поведение, безусловно, не является чем-то новым), он должен был использовать магические методы, потому что не было обобщений. Варианты в основном были:

1. Используйте неуниверсальный IEnumerableи IEnumeratorработать сobject s, что означает типы значений бокса. Поскольку итерация чего-то вроде списка ints должна быть очень быстрой и, конечно, не должна создавать много значений в виде мусора в штучной упаковке, это не лучший выбор.

2. Ждите дженериков. Это, вероятно, будет означать задержку .Net 1.0 (или, по крайней мере,foreach ) на более чем 3 года.

3. Используйте магические методы.

Таким образом, они выбрали вариант № 3, и он остался с нами по причинам обратной совместимости, хотя начиная с .Net 2.0, требуя IEnumerable<T> тоже работало бы.

Инициализаторы коллекций могут выглядеть по-разному в зависимости от типа коллекции. Сравните List<T>:

public void Add(T item)

и Dictionary<TKey, TValue> :

public void Add(TKey key, TValue value)

У вас не может быть единого интерфейса, который бы поддерживал только первую форму для List<T> и только вторую для Dictionary<TKey, TValue>.

Методы LINQ обычно реализуются как методы расширения (так что может быть только одна реализация, например, LINQ to Object для всех типов, которые реализуют IEnumerable<T> ), что означает, что невозможно использовать интерфейс.

Для await, GetResult()метод может возвращать один voidили несколько типов T. Опять же, вы не можете иметь один интерфейс, который может обрабатывать оба. Хотя awaitэто частично основано на интерфейсе: ожидающий должен реализовать, INotifyCompletionа также может реализовать ICriticalNotifyCompletion.