Какой самый лучший (самый полезный) интерфейс из написанных вами?

I guess the guys that wrote IEnumerable … had a good feeling after creating [it].

Я не совсем уверен. Что касается интерфейсов, IEnumerable оказался провальным. Это очевидно из того факта, что IEnumerable<T>, его общий аналог, на самом деле предлагает полностью интерфейс разные. (Ну, «другой» - не очень хорошее слово; в основном, оно добавляет одноразовости и приуменьшает значение совершенно бесполезного метода Reset; однако этот метод, конечно, все еще присутствует.)

Кроме того, похожие языки, которые имеют похожие конструкции (на ум приходит Java), имеют гораздо лучшую, более расширяемую конструкцию для удовлетворения тех же потребностей (и даже больше). Например, итераторы Java могут быть расширены до двунаправленных или для изменения доступа (тогда как IEnumerable всегда доступен только для чтения).

Обновлено: Поскольку в комментариях так много противоречий, позвольте мне уточнить. Я не говорю, что IEnumerable (или IEnumerator) являются интерфейсами плохой. Они адекватные. Однако их можно было улучшить. По крайней мере, метод Reset кажется беспорядочным.

Terjet сказал, что он «использует [s] это все время» - и это в точности моя точка зрения! IEnumerable - это основной интерфейс всей платформы .NET. Это повсеместно. Без него не было бы .NET. Поэтому не слишком ли много просить об интерфейсе идеально?

«Адекватный» - это просто еще одно слово для обозначения неудач.

Я доволен дизайном интерфейса, лежащего в основе Нажмите LINQ. Это очень простой интерфейс, но с ним вы можете делать самые разные интересные вещи. Вот определение (по памяти, но, по крайней мере, будет довольно близко):

public interface IDataProducer<T>
{
    event Action<T> DataProduced;
    event Action EndOfData;
}

По сути, он позволяет наблюдателям «прослушивать» поток данных, а не «извлекать» из него, как работает IEnumerable.

Три интересных места:

• Имя отстой. Я хочу переименовать его, и у меня есть хорошие отзывы, но имени в пока нет.
• Обработчики событий не следуют стандартным соглашениям .NET о наличии аргументов отправителя / события. В данном случае это действительно не имеет особого смысла.
• Многоадресный характер событий делает это идеальным для вычисления нескольких агрегатов и т. д. Все это предоставляется бесплатно.

Собственно интерфейс? Или просто API? Я доволен тем, как сработал материал универсальный оператор (доступен здесь) - я регулярно вижу, как люди спрашивают об использовании операторов с дженериками, поэтому я рад, что это удобный ответ для многих людей. Это может быть немного проще в C# 4.0, но я очень сомневаюсь, что он будет таким же быстрым - DLR-дерево / динамический материал имеет накладные расходы.

Я также очень рад, что это было полезно в Push LINQ, о котором уже упоминал Джон ;-p

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

Основной интерфейс спроектирован так, чтобы быть функциональным по своей природе:

public interface ICheckable<T>
{
    CheckResult Apply(T target);
}

CheckResult - это struct, представляющий значение трех состояний: Passed, Failed и Ignored. Все преобразования и перегрузки операторов используются для обработки его как значения Boolean.

Это позволяет валидаторам выражать «У меня нет мнения» вместо того, чтобы возвращать вводящее в заблуждение значение true (подумайте, что RangeValidator, указывающий, что пустое поле является допустимым, поэтому он хорошо работает с RequiredFieldValidator).

Композиция происходит естественно и выполняется с помощью статических классов а-ля Linq. Каждая точка в проверке является неявным And следующей операции:

public static ICheckable<T> Add<T>(this ICheckable<T> check, ICheckable<T> otherCheck)
{
    return new Check<T>(t => check.Apply(t) && otherCheck.Apply(t));
}

public static ICheckable<T> Either<T>(this ICheckable<T> check, ICheckable<T> firstCheck, ICheckable<T> secondCheck)
{
    return check.Add(t => firstCheck.Apply(t) || secondCheck.Apply(t));
}

public static ICheckable<T> Not<T>(this ICheckable<T> check, ICheckable<T> negatedCheck)
{
    return check.Add(t => !negatedCheck.Apply(t));
}

Методы расширения работают нормально:

public static ICheckable<int> Percentage(this ICheckable<int> check)
{
    return check.Add(n => n >= 0 && n <= 100);
}

public static ICheckable<T> GreaterThanOrEqualTo<T>(this ICheckable<T> check, T value) where T : IComparable<T>
{
    return check.Add(t => t.CompareTo(value) >= 0);
}

public static ICheckable<T> LessThanOrEqualTo<T>(this ICheckable<T> check, T value) where T : IComparable<T>
{
    return check.Add(t => t.CompareTo(value) <= 0);
}

public static ICheckable<T> Range<T>(this ICheckable<T> check, T minimum, T maximum) where T : IComparable<T>
{
    return check.GreaterThanOrEqualTo(minimum).LessThanOrEqualTo(maximum);
}

// RangeExcludeMinimum
// RangeExcludeMaximum
// RangeExclusive

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

public static ICheckable<T> Add<T>(this ICheckable<T> check, Func<ICheckable<T>, ICheckable<T>> makeCheck)
{
    return check.Add(makeCheck(new IgnoredCheck<T>()));
}

Таким образом, вы можете использовать такой синтаксис:

ICheckable<int> check;

check.Add(i => i.Percentage().GreaterThan(50).Even());

Это интерфейс ActionScript 3, который был ядром нашего нового поведения Flash Player в as3.

public interface IDisposable {
  public function dispose():void;
}

Как и следовало ожидать, метод dispose должен закрыть все ресурсы и отбросить все ссылки на все, что возможно.

Программисты на C++ могут посмеяться над этим «инновационным» интерфейсом (что вполне справедливо), но as3 представил множество проблем, связанных с управлением памятью во Flash. Все эти проблемы являются «старой шляпой» для многих компилируемых языков, но программисты ActionScript только сейчас впервые сталкиваются с этими проблемами.

Да, это все еще язык со сборкой мусора. Но, что бы там ни было, «держаться за руки» гораздо меньше, чем в ActionScript 2, о чем свидетельствует необходимость в этом интерфейсе.

Для работы с MVP-шаблоном у меня есть несколько базовых интерфейсов фреймворка:

public interface IValidatable {
  bool IsValid { get; set; }
  void ShowValidationFailureMessage(string message);
}

public interface ISubmitable {
  event EventHandler Submit;
  void ShowSubmitFailureMessage(string message);
  void ShowSubmitSuccessMessage(string message);
}

public interface ICancelable {
  event EventHandler Cancel;
}

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

public interface ILogin : IValidatable, ISubmitable, ICancelable {
  string Username { get; set; }
  string Password { get; set; }
}

Затем вы можете создать докладчика и убрать его.