Программирование на основе интерфейса, я делаю это правильно?

Question

ОК, поэтому я решил начать использовать интерфейсы в моей кодовой базе, и это хорошо работает для определенных задач.Например, у меня есть класс построителя URL, который реализует IUrlBuilder, и теперь реализация не имеет значения.Замечательно, но возьмем, к примеру, этот интерфейс.

namespace SproutMessagingFramework.Webtext.Interfaces
{
using System.Net;

public interface ICookieJar
{
    CookieCollection Collection { get; set; }
    CookieContainer Container { get; set; }

    void AddResponse(HttpWebResponse Response);
    void AddResponse(HttpWebResponse Response, string Path, string Domain);
}
}

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

Это правильно, или я просто вздуваю кодовую базу?

Answer 1

Интерфейсы могут быть разработаны с соответствием 1: 1 определенному классу.Это позволяет (помимо прочего) интегрироваться с фиктивными средами, где вы заменяете поддельный файл cookie на настоящий, проверяя поведение монстра cookie в тестовой среде.

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

Еще одно распространенное использование - предоставитьунифицированная контейнерная модель, такая как ICollection и IEnumerable.

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

Answer 2

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

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