Это неправильно, чтобы каждый конкретный класс наследовал от интерфейса?

Question

Это ответ на некоторые комментарии , сделанные Зедом Шоу в своем блоге давным-давно.

Затем эксперты уйдут, чтобы внедрить свою Пылающую Вавилонскую башню.без каких-либо комментариев, ужасно сложные тесты с включенной имитацией, убедившись, что КАЖДЫЙ ОДИН КЛАСС имеет ИНТЕРФЕЙС, и заканчивая каждый класс «Impl», потому что, ну, в общем, это лучшая практика.Хитрость в равной степени, и я заметил, что эти фреймворки используют постфикс Impl , но экономно.В моем коде я использую интерфейсы везде, потому что мне сказали, что это облегчает насмешку и т. Д. У меня есть наивное понимание проблемы?(Возможно, фиктивные фреймворки могут работать с абстрактными классами или классами, я не знаю. Я никогда не пробовал) Для своих конкретных реализаций я выбрал соглашение Spring, заключающееся в добавлении префикса имени реализации к слову Default.

e.g. BottleOpener (interface) is implemented by DefaultBottleOpener (class)

Какова лучшая практика в этом вопросе?

UPDATE1 Я считаю полезным возвращать интерфейс из метода, потому что я всегда могу вернуть анонимный класс,

Answer 1

Делать что-либо до одержимости - неправильно.Это всего лишь инструменты, мы мастера.

Answer 2

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

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

Answer 3

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