Михаил

Верстать вымышленные сайты для портфолио / работать даром или за еду.

Часто ли вы используете интерфейсы?

Посмотрим, что у нас в стандартной библиотеке:

• IEnumerable
  
• IDisposable
  
• IEquatable
  
• IComparable
  
• IDbConnection
  

Со всеми этими интерфейсами дотнет разработчик сталкивается каждый день. Либо пользуется ими, либо реализует их. Например, тот же yield return работает благодаря IEnumerable. Весь LINQ основан на IEnumerable и IQueryable.

Часто ли у вас было что ваши репозитории окруженные интерфейсами используют MSSQL, и есть еще такие же репозитории но уже использующие к примеру MongoDB, и где нито вы подменяете одно другим?

Да, часто. Например, архитектура ADO.NET позволяет написать приложение так, что оно вообще не будет зависеть от используемого драйвера БД, и конкретный ado.net драйвер можно указать в конфиг-файле приложения. Т.е. конкретную БД может выбрать ПОЛЬЗОВАТЕЛЬ, а не разработчик. Более того, если под какую-то БД драйвера еще нет, а позже он появится, то его можно будет задействовать без перекомпиляции приложения. Только потому, что используются интерфейсы.

Самый простой пример, который приходит на ум: представьте, что вы хотите получать оповещения об ошибках на сайте по email/смс/чему-нибудь ещё.

С интерфейсами ваше решение будет выглядеть как-то так:

// Собственно, сам интерфейс оповещений
public interface INotification
{
    void Notify(string text);
}

public class EmailNotification : INotification
{
    public void Notify(string text)
    {
		// код по отправке почты
    }
}

public class SmsNotification : INotification
{
    public void Notify(string text)
    {
		// код по отправке смс
    }
}

// ... Еще какие-нибудь классы оповещений


// В каком-нибудь классе, где может появиться ошибка
public class MaybeErrorClass
{
    private INotification _notification;

    public MaybeErrorClass(INotification notification)
    {
		// Класс не должен знать, по какому каналу оповещать об ошибках.
		// Он работает с абстракцией
        this._notification = notification;
    }

	// Очень простой пример метода, в котором ожидаем генерацию ошибки
	public void DoSomething()
	{
		try {
			// какой-то блок, в котором можем получить ошибку
		}
		catch (Exception e)
		{
			this._notification.Notify("А у нас тут ошибка!");
		}
	}
}

Теперь можно создавать экземпляры этого класса, передавая ему желаемый тип оповещения:

var maybeErrorEmail = new MaybeErrorClass(new EmailNotification());
var maybeErrorSms = new MaybeErrorClass(new SmsNotification());

Теперь вопрос на засыпку: как бы вы решили подобную задачу без интерфейсов?

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