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

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

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

Вот простой пример, который открыл мне глаза на интерфейсы.

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 в качестве параметра in. List<SimpleClass>, SimpleClass[], Collection<SimpleClass>.

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

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

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

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

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

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

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

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

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

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

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

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

Просмотрите книгу Head-First Design Patterns... вы увидите веские аргументы в пользу использования интерфейсов, которые не имеют ничего общего с TDD или полиморфизмом.

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

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

public class Employee {
  private IExpenseCalculator expenses;

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

В этом примере предполагается, что «расходы» представлены как свойство и что IExpenseCalculator имеет метод для CalcExpenses().

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

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

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

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

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