Программирование к интерфейсу. Как решить где его необходимое?

Простой пример, который открыл мои глаза для Интерфейсов, является этим

class SimpleClass
{
  public int A { get; set; }
  public int B { get; set; }
  public int C { get; set; }
}

List<SimpleClass> Calc(IEnumerable<SimpleClass> list)
{
  foreach(SimpleClass item in list)
  {
     item.C = item.A * item.C:
  }
  return list.ToList();
}

Заметьте входной параметр IEnumerable. При помощи этого я могу передать в любом наборе, который реализует IEnumerable как в параметре. List<SimpleClass>, SimpleClass[], Collection<SimpleClass>.

Интерфейс IEnumerable гарантирует мне, что я могу использовать цикл foreach и этот способ, которым я сделал свою функцию более универсальной и будет меньше шанса, что я должен изменить этот код начиная с шанса, что IEnumerable изменяется, меньше это f.ex. Изменения списка.

Если Вы когда-нибудь вовлекаете себя заинтересованный Разработкой через тестирование, потребность в "программировании к интерфейсу" действительно становится очевидной. Если Вы хотите, чтобы класс был протестирован в изоляции его зависимостей, необходимо раздать интерфейсы вместо объектов.

Причина программировать к интерфейсу состоит в том, чтобы изолировать высокоуровневые классы от изменений в классах низшего уровня. Если Вы не ожидаете класс низшего уровня для изменения вообще, то это разумно не к программе к интерфейсу в этом случае. Эта статья (PDF) уточняет идею, вводя термин Принцип Инверсии Зависимости.

Если будет хороший шанс, то приложение станет более сложным, легче открыть леса ранее, а не позже. Однако, если приложение не сложно, и маловероятно, что это не станет сложным, ROI не может быть там. Можно всегда осуществить рефакторинг позже.

Необходимо рассматривать интерфейс как контракт. Этот контракт определяет подшипник и операции, которые должны быть выполнены теми, кто подписал этот контракт, неважно, как он сделан.

Программирование к интерфейсу в простом приложении, где Вы не планируете свопинг реализаций, может походить на излишество.

Второе Вы входите в Поблочное тестирование, которое Вы будете очень рады программировать к интерфейсам, потому что оно дает Вам способность более легко дразнить реальный объект с тестом, удваивается.

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

1. Объект может наследоваться многим интерфейсам, но только одному базовому классу;
2. Интерфейсы не позволяют реализации по умолчанию, в то время как базовый класс делает.

Теперь думайте об объектах, которые наследуются Вашей "структуре". Что будет более важно для них? Они извлекут выгоду больше всего из реализаций по умолчанию методов, или будет лучше, если у них могут быть другие базовые классы?

В большинстве случаев это довольно ясно, какой является более важным фактором. Если Вы, оказывается, находитесь на тонком промежутке строки... жесткая удача. Microsoft рекомендует базовые классы по интерфейсам.

Если Вы хотите смочь протестировать свое приложение и не иметь, чтобы использовать (и впоследствии не иметь для создания) полный объект сотрудника, Вы имеете, может создать интерфейс IEmployee и затем создать дружественные ложные объекты сотрудника теста легкого веса протестировать с. Это может быть большим усилением, если создание сотрудника является трудным или даже невозможным сделать вручную или без базы данных.

Другое серьезное основание состоит в том, что это помогает Вам определить то, от чего точно Вы зависите в Вашем классе сотрудника. Вы, возможно, думали, что только использовали несколько открытых методов, но затем узнаете позже использование 10 методов и что они более сильно связаны, чем Вы думали.

Наконец, если необходимо изменить код для использования SuperEmployee вместо Сотрудника при использовании интерфейсов все время по затем всему, что необходимо было бы сделать, должен сделать, чтобы SuperEmployee реализовал IEmployee, и Вы были бы установлены.

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

Для внутренних деталей Вашего дизайна у Вас есть опция начинания со ссылками реального класса везде и только представления интерфейсов, где это имеет смысл для дизайна.

Но другой важной вещью рассмотреть является поблочное тестирование. Вы можете полностью "ложный" интерфейс в CLR без технической трудности, но насмешка других вещей или невозможна или потребовала бы некоторого серьезного обмана. Таким образом, одна дисциплина для рассмотрения является разработкой через тестирование: запишите тесты для своего кода, как Вы продвигаетесь, и Вы обнаружите необходимость в определенных вещах, которые будут выражены интерфейсами, таким образом, можно обеспечить ложные версии их.

Возьмите обзор через книгу Головой вперед Шаблоны разработки... Вы будете видеть хорошие аргументы для использования интерфейсов, которые не имеют никакого отношения к TDD или полиморфизму.

Интерфейсы позволяют Вам изменять поведение объекта во времени выполнения... Думайте о местах, где Вы нуждались бы в обработчике для особого поведения, но не могли бы знать, какое поведение необходимо до времени выполнения. В случае вычислительных расходов для сотрудников... У менеджеров мог бы быть более высокий допуск на расходы 'развлечений', чем штатный сотрудник.

Если Ваш объект Сотрудника имеет ссылку на интерфейс IExpenseCalculator, можно присвоить ему калькулятор менеджера или калькулятор сотрудника во времени выполнения. Вызов Сотрудника. GetExpenses () даст Вам по-другому расчетный результат для менеджера, чем для штатного сотрудника. Внутренне, код был бы похож на это:

public class Employee {
  private IExpenseCalculator expenses;

  public ExpenseSheet GetExpenses() {
    return expenses.CalcExpenses();
  }
}

Этот пример предполагает, что 'расходы' выставляются как свойство, и что IExpenseCalculator имеет метод для CalcExpenses ().

Интерфейсы также тесно связываются с понятием объектных фабрик... думают слой базы данных. При конфигурировании слоя данных как фабрики можно создать объекты соединиться с SQL-сервером, Oracle или MySql динамично, во времени выполнения, на основе параметров конфигурации. Но клиенту нужен конкретный дескриптор к расположенному на слое объекту базы данных... вводят Интерфейсы.

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