Бесполезные интерфейсы - PullRequest
22 голосов
/ 05 июня 2009

Зачем вам когда-либо использовать интерфейс, если у вас будет только одна его реализация?

Ответы [ 25 ]

28 голосов
/ 05 июня 2009

Если бы я точно знал, что будет только одна реализация, я бы не стал создавать интерфейс. Это подпадает под ЯГНИ, ИМО.

(Конечно, я редко знаю что-либо о будущем для факта ...)

22 голосов
/ 05 июня 2009

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

10 голосов
/ 05 июня 2009

Хорошей практикой может быть установка interface в качестве спецификации для кодирования вашего class в.

Если вы определили общедоступные методы / функциональные возможности, которые будут иметь ваши interface, вы можете заблокировать их на месте. Тогда становится намного проще кодировать class, если вы помните об этом.

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

8 голосов
/ 05 июня 2009

Потому что им не хватает заголовочных файлов C ++?

4 голосов
/ 05 июня 2009

Если действительно существует одна реализация, и только когда-либо будет одна реализация, не кодируйте интерфейс. (YAGNI).

Тем не менее, в 99% случаев существует как минимум две реализации класса, одна реальная, другая используется в тестировании.

Простота разделения и проверки частей системы во время тестирования более чем стоит дополнительных усилий по созданию интерфейса для одного класса.

В качестве дополнительного примечания, и, возможно, это просто из-за того, что мне не хватает самоконтроля, кодирование с интерфейсами делает меня намного более сосредоточенным, когда я работаю над определенным классом. Я поймал себя на мысли, что «и этот интерфейс, который я вызываю, вернет / сделает это», а не «и этот класс, с которым я работаю вот так, вызывает x, преобразовывает y, общается с z, кладет кофе, пухнет pillows, интегрирует n относительно y и затем возвращает экземпляр monkey ... подождите, что я снова делал? "

4 голосов
/ 05 июня 2009

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

Однако, широкое использование будет:

  1. Заполнитель будущего расширения / улучшения

  2. Простота реализации Инверсия управления / инжекция зависимости

  3. Простые в использовании макеты для модульного тестирования.

* Edit:

Я заметил, что в ваших тегах тоже есть Spring. Если использовать Spring, то № 2 выше, вероятно, важная персона. Классы, которые ожидают интерфейсов, легче проектировать, и вы можете поменять фактические реализации интерфейса в конфигурации Spring (Dependency Injection).

3 голосов
/ 05 июня 2009

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

3 голосов
/ 05 июня 2009

Если у вас будет только одна реализация, я бы этого не делал. Приведенные здесь аргументы о том, что у вас может быть несколько реализаций, на самом деле не подходят для тщательного изучения. Если у вас есть несколько реализаций, извлечение интерфейса занимает около 5 секунд с помощью встроенных инструментов Visual Studio или Resharper.

Так что да, ЯГНИ - не усложняй свою жизнь, пока тебе не придется.

3 голосов
/ 05 июня 2009

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

2 голосов
/ 05 июня 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...