Объявить реализованный IEnumerable интерфейса или класса как устаревшего

Question

Можно ли объявить производную или реализованную часть IEnumerable интерфейса или класса устаревшим, тогда как остальная часть класса или интерфейса по-прежнему актуальна? Как я объявляю это?

interface Foo : IEnumerable<Bar>{ 

    int SomethingNonObsolete{ 
     get; 
    } 

} 

В приведенном выше examble, хотелось бы, что использование итераторы реализованного IEnumerable приводит к компилятору устаревших предупреждениям, тогда как использование интерфейса itselfs или использование SomethingNonObsolete -свойства не приводит к такое предупреждение.

Следующий код должен привести к компилятором устаревшие предупреждения

foreach(var bar in myFooImplementingInstance){ 

Следующий код не должно привести к компилятором устаревшие предупреждения

myFooImplementingInstance.SomethingNonObsolete.ToString() 

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

В конце концов, это технически невозможно из-за LINQ.

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

[Obsolete] 
IEnumerator<Bar> GetEnumerator() 
[Obsolete] 
IEnumerator IEnumerable.GetEnumerator() 

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

[Obsolete] 
new IEnumerator<ITabularDataRow> GetEnumerator(); 

Однако, в то время как обе эти версии делают в общем то, что они должны, они оба разрыва при использовании LINQ. Таким образом, ответ кажется, что это невозможно в комплексном виде и что это в большинстве случаев полезно (см. Ответ и комментарии от MDeSchaepmeester).

Answer 1

При реализации своего интерфейса, добавив атрибут на GetEnumerator методы Obsolete, как показано ниже, приводит к вашим ожиданиям:

public class MyClass : Foo 
{ 
    public int SomethingNonObsolete 
    { 
     get 
     { 
      throw new NotImplementedException(); 
     } 
    } 

    [Obsolete] 
    public IEnumerator<Bar> GetEnumerator() 
    { 
     throw new NotImplementedException(); 
    } 

    [Obsolete] 
    IEnumerator IEnumerable.GetEnumerator() 
    { 
     throw new NotImplementedException(); 
    } 
} 

Результат:

var c = new MyClass(); 

// Flagged as obsolete 
foreach (var blah in c) 
{ 

} 

// Not flagged as obsolete 
var s = c.SomethingNonObsolete; 

Answer 2

Вы можете использовать ObsoleteAttribute, чтобы пометить участника как устаревшие. Добавьте его к каждому из ваших устаревших методов, и вы получите свои предупреждения (или ошибки, в зависимости от аргументов). Однако это означает, что вам нужно указать всех членов, что невозможно в вашем случае, кроме случаев, когда выполняется реализация Foo. Единственный другой вариант - пометить весь интерфейс как устаревший и заменить его на Foo2 - на самом деле, это может быть лучший способ обойти это в любом случае.

Также обратите внимание, что это будет касаться только прямых вызовов. Компилятор не знает, что ((IEnumerable<Bar>)yourFooInstance).GetEnumerator() должен быть устаревшим.

Answer 3

Это интересная ситуация, но то, что вы это будет довольно значительным изменением для вашего API.

Obsolete используется, в основном, если вы можете использовать вместо альтернативы, т.е. через XML-документ (например, если вы хотите пометить SomethingNotObsolete с Obsolete и сказать use SomethingNew instead.

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

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

Answer 4

Вы могли создайте новый интерфейс. Теперь в вашем новом интерфейсе вы не наследуете IEnumerable и iginal интерфейс Obsolete. Теперь whoeever использует foreach(Foo f in myFooImplementingInstance) получает ваше устаревшее сообщение. В идеале вы также добавили намек на то, что вместо этого следует использовать новый интерфейс. Основная идея заключается в том, что ваш интерфейс имеет единственную цель. Изменение его цепочки наследования или аналогичного варианта приведет к значительному непредсказуемости. Поэтому вы должны создать новый интерфейс, который обеспечит новые требования.

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