да зачем тебе эти интерфейсы? пили треш в одиночку. Без плетки тебе к сожалению не разобрать и не понять зачем нужно тратить время на написание интерфейсов.

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

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

По сути любой лишний код вредная затея с точки зрения производительности.

Я по другому делаю, пишу без интерфейсов, а когда появляется еще одна реализация класса, тогда уж делаю интерфейс.
Самый простой пример.
Был класс Cache, он писал данные в файлы, понадобился класс MemCache с таким же api.
Из Cache сделал интерфейс, написал FileCache (бывший Cache), написал MemCache.
Приложение как использовала Cache, так и использует, только уже с той реализацией, какую я туда подсуну.

class News {
 public funtion __construct (Cache $Cache) {}
}

new News($MemCache)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

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

Вот если разработка ведется по принципу TDD, то смысл интерфейса вообще пропадает.

Вред они наносят не разработчикам, а потребителю проекта. Если есть резерв по ресурсу, допустим это какая-нибудь визитка для узкой аудитории, то конечно наплевать. А если сервера молотят на пределе от нагрузки, приходится задумываться о таких нюансах.

И еще, наоборот должна звучать фраза. Пользу интерфейсы приносят только

Тем, кого нужно держать за ручку, ибо он сам не в состояни посмотреть документацию.

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

Если так рассуждать, то можно и наоборот:

В чем разница? И то и другое нужно писать до. И еще, а я вот возьму и не буду имплементировать свой клас с интерфейсом. Не всегда объект передается аргументм с проверкой. И что?

Тут все равно все зависит от самодисциплины и квалификации. Интерфейсы, это защита от уже совсем дурака.

Все верно. Потому я и не приемлю лишнего кода, стараюсь делать все оптимально в первую очередь с точки зрения потребления. А думать за дурака, это увольте.

Вот если бы они могли быть отключаемыми, тогда да - польза несомненна, вреда минимум. А так фигня.

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.