Рискую повториться, но позволю описать свое видение.
Можно выделить несколько случаев, когда удобно использовать интерфейсы:
- Абстракция, предполагающая несколько одновременно используемых реализаций. Например IEnumerable или как пример с паттерном "Стратегия" в первом комментарии.
- Несколько взаимозаменяемых реализаций одной абстракции. Например логгер, можно логировать в файл, в табличку на форме, в БД.
- Замена для тестирования. Хотя при желании это можно сделать и с виртуальными методами, но как правило, с интерфейсами удобнее, с учетом множественной реализации нескольких интерфейсов, но наследование только от одного базового класса, да и базовая реализация как правило тянет за собой клубок зависимостей.
- Для следования принципу инверсии зависимостей. Очень рекомендую ознакомиться с принципами SOLID, два из которых как про интерфейсы - принцип инверсии зависимостей и принцип разделения интерфейсов. Если кратко про инверсию - потребители должны зависеть от абстракции, а не от реализации, в том числе на уровне сборок. Чтобы сократить и упорядочить зависимости между сборками, как правило выделяют сборку с интерфейсами и контрактами, которую используют сборки с реализацией, сборки потребители и сборки с тестами.
По поводу когда следует вводить интерфейс - обычно я ввожу интерфейс, если вижу в этом смысл по описанным выше причинам, если смысла нет, то и вводить не тороплюсь, ведь его всегда можно выделить, главное чтобы была понятная для вас причина.
