помимо их реализации добавляют еще и интерфейс. Понятно что детали реализации сервисов не должны светиться в бизнес логике, но разве мы не можем делать все методы/поля, которые специфичны для этой реализации делать приватными? Какой смысл в интерфейсе, если публичные методы реализации совпадают с интерфейсом один в один. Мало того, интерфейс не позволяет работать с полями, что бывает крайне неудобно.
Подскажите, может я что-то упускаю?
Интерфейс позволяет подменить реализацию. Если интерфейс 1в1 копирует реализацию, это ошибка проектирования (или интерфейс используется просто для того чтобы была возможность тестировать в изоляции от БД, Очереди и т.п.). Как правило такое случается, когда берут конкретную реализацию, а потом из нее извлекают интерфейс. Обычно же интерфейс обычно проектируется до того как выбрана ДБ/Очередь/Другой сервис.
Для тестирования и рефакторинга. Интерфейс = late binding (at runtime), что значит что мы в runtime можем поменять конкретную реализацию на которую диспатчатся вызовы методов. С early binding’ом (at compile-time) такое будет невозможно. Например мы пользуемся gomock с помощью которого используем mock за интерфейсами в тестах
> Мало того, интерфейс не позволяет работать с полями, что бывает крайне неудобно. поэтому я и дебатировал тут на днях о том, что нельзя смотреть на интерфейсы как на “абстрактные сущности”. Пример: Stream плохое название для интерфейса, ибо оно отображает сущность (поток данных). Такой интерфейс должен называться Streamer ибо сразу становится понятно, что это нечто, что читает поток данных и не является самим потоком. Интерфейс это диспетчер вызова методов. Это актор, который позволяет выполнять действия на каком либо объекте (при этом пользователю интерфейса не должно быть известно к какой конкретной реализации он обращается, ему должно быть пофиг.)
Обсуждают сегодня