Почему мы реализуем интерфейсы?

Потому что вам может понадобиться, чтобы один и тот же код работал с экземплярами разных классов. Например, процедура очистки формы хочет перебрать все компоненты и удалить их. Для этого ему необходимо обращаться к компонентам через тип: либо общий базовый класс, либо интерфейс. Единичное наследование означает, что общий базовый класс не всегда возможен (предположим, что в моей форме есть как FileStream, так и Button - какой общий базовый класс у них может быть, чтобы процедура очистки могла получить к ним доступ?); отсюда и интерфейсы.

Среди прочего, прочтите о блоке с использованием .

Феб дал отличный ответ, но добавил еще немного.

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

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

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

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

Интерфейсы просто определяют объявление метода (неявно открытый и абстрактный) и могут содержать свойства (которые также неявно являются общедоступными и абстрактными). Определение интерфейса начинается с ключевого слова interface. Невозможно создать экземпляр интерфейса, подобного интерфейсу абстрактного класса.

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

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

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

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

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

код службы

public IEnumerable<int> GetNumbers(){ return new []{1,2,3,4,5}; }

код клиента:

var result = serviceProxy.GetNumbers();

Здесь код службы может изменить реализацию, чтобы вернуть любой класс, удовлетворяющий IEnumerable, без нарушения клиентского кода.

Помимо всего этого, у вас есть получил другие приложения, такие как IoC DI, Unit Testing, Object Mocking. Все это пожинает плоды полиморфного добра.