Продолжение назначения интерфейсов

Question

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

Но если все, что у вас есть в интерфейсе, это:

 public interface animal{
  void eat(object food);
}

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

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

Любая помощь, чтобы разобраться в этом, ценится, потому что я знаю, что это действительно важно.

Answer 1

Это на самом деле не столько ответ, сколько пример, который я считаю полезным при рассмотрении интерфейсов, но подумайте об интерфейсе Comparable<T>, для которого требуется метод

public int compareTo(T anotherObject)

Пользователь может реализовать этооднако он или она хочет.Например, если Person implements Comparable<Person>, сравнение может быть основано на фамилии, а затем на имени, без учета заглавных букв.Или это может быть основано на возрасте и т. Д. Однако пользователь хочет.Реализация этого интерфейса очень полезна, так как он позволяет пользователю использовать такие вещи, как Collections.sort(), которые требуют, чтобы сортируемые элементы были сопоставимы (как еще можно сделать сравнение?)

Answer 2

Вы думаете об этом задом наперед.Вместо того, чтобы сначала думать о реализации, вы сначала думаете о поведении (как описано в сигнатуре метода).Затем вы реализуете поведение соответствующим образом в базовых классах, давая гораздо более гибкую, расширяемую систему.Вы довольно быстро отклонили «дизайн по контракту», но это ключевая стратегия проектирования и основа для веб-сервисов, SOA и т. Д.

Answer 3

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

Каждая реализация интерфейса может отличаться.Дело в том, что вы можете использовать интерфейс, не зная реализации.Рассмотрим пример:

public interface ILogger
{
    void WriteMessage(string message);
}

Ваше приложение может использовать интерфейс ILogger для регистрации ошибок / отладочной информации и т. Д. Но не имеет значения, как реализован регистратор - это может быть FileSystemLogger или DatabaseLogger или любая другая реализация.Таким образом, вы сможете заменить реализации в любое время, не изменяя все места в коде, где упоминалось ведение журнала.