Чому в 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працюйте з objects, що означає типи значень боксу. Оскільки повторення чогось подібного до списку 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 для Object для всіх типів, які реалізують IEnumerable<T>), а це означає, що використовувати інтерфейс неможливо.

Для await, The GetResult()метод може повертати або voidабо який - то тип T. Знову ж таки, у вас не може бути єдиного інтерфейсу, який може працювати з обома. Хоча awaitчастково на основі інтерфейсу: офіціант повинен реалізувати, INotifyCompletionа також може реалізувати ICriticalNotifyCompletion.