Пишете ли вы интерфейсы (в java называются интерфейсы, для других языков свои аналоги) для всех (или большинства) классов приложения?
Или это делается только для тех, которые должны быть полиморфными?
Например, если в приложении мне нужен класс SomeClassFactory с методом SomeClass create(typeName), есть ли преимущества от того, что я напишу соответствующий интерфейс и потом класс-реализацию этого интерфейса? Если есть преимущества то окупают ли они неудобства (трата времени, пусть очень маленькая, увеличение дерева проекта в IDE за счет появления к каждому классу интерфейса, что затрудняет поиск необходимого класс)?

Здравствуйте, kurel, Вы писали:

K>Пишете ли вы интерфейсы (в java называются интерфейсы, для других языков свои аналоги) для всех (или большинства) классов приложения?

It depends. Всё определяется используемым языком/фреймворком/архитектурой софта/реальной решаемой проблемой. Если рассматривать случай сферического коня в вакууме, то интерфейсы стоит использовать в двух случаях:
1. У вас есть слабосвязанные части приложения с жёстко определённым контрактом. Собственно, интерфейсы — и есть этот контракт.
2. Вы хотите переиспользовать логику для разнотипных объектов с частично похожим API — эдакий типизированный duck-typing. Тут интерфейсы описывают отношение "объект ведёт себя как", в отличие от наследования ("объект является чем-то"). Классика — Collection<E>/Comparable<T> в яве.

Все прочие варианты — это уже не лечится паттернофилия

Здравствуйте, kurel, Вы писали:

K>Пишете ли вы интерфейсы (в java называются интерфейсы, для других языков свои аналоги) для всех (или большинства) классов приложения?
K>Или это делается только для тех, которые должны быть полиморфными?

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

Естественно, всё перечисленное выше не касается библиотек, которые планируется распространять.

Здравствуйте, kurel, Вы писали:

K>Пишете ли вы интерфейсы (в java называются интерфейсы, для других языков свои аналоги) для всех (или большинства) классов приложения?
K>Или это делается только для тех, которые должны быть полиморфными?

В языках с duck-typing это вообще делать не нужно. Мне в python'е определять интерфейсы не приходилось.

Здравствуйте, kurel, Вы писали:

K>Пишете ли вы интерфейсы (в java называются интерфейсы, для других языков свои аналоги) для всех (или большинства) классов приложения?
K>Или это делается только для тех, которые должны быть полиморфными?
K>Например, если в приложении мне нужен класс SomeClassFactory с методом SomeClass create(typeName), есть ли преимущества от того, что я напишу соответствующий интерфейс и потом класс-реализацию этого интерфейса? Если есть преимущества то окупают ли они неудобства (трата времени, пусть очень маленькая, увеличение дерева проекта в IDE за счет появления к каждому классу интерфейса, что затрудняет поиск необходимого класс)?

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

А просты вещи, сляпанные на коленке — это да, это не для интерфейсов.

Здравствуйте, kurel, Вы писали:

K>Пишете ли вы интерфейсы (в java называются интерфейсы, для других языков свои аналоги) для всех (или большинства) классов приложения?
K>Или это делается только для тех, которые должны быть полиморфными?
K>Например, если в приложении мне нужен класс SomeClassFactory с методом SomeClass create(typeName), есть ли преимущества от того, что я напишу соответствующий интерфейс и потом класс-реализацию этого интерфейса? Если есть преимущества то окупают ли они неудобства (трата времени, пусть очень маленькая, увеличение дерева проекта в IDE за счет появления к каждому классу интерфейса, что затрудняет поиск необходимого класс)?

А ты можешь адекватно описать зачем все это делавется?

Здравствуйте, gandjustas, Вы писали:
G>А ты можешь адекватно описать зачем все это делавется?
Пишу на java. Порядок методов в классе не "вначале все public-методы, а потом private", а примерно "после каждого метода следуют методы которые он использует". Это затрудняет понимание что делает класс, т.к. public-методы теряются среди private-методов, которых обычно больше.

Здравствуйте, kurel, Вы писали:


K>Пишу на java. Порядок методов в классе не "вначале все public-методы, а потом private", а примерно "после каждого метода следуют методы которые он использует". Это затрудняет понимание что делает класс, т.к. public-методы теряются среди private-методов, которых обычно больше.

Если проблема в IDE, зачем решать её с помощью кода? Почему бы не использовать что-то аля VS CodeMap?

Здравствуйте, kurel, Вы писали:

K>Здравствуйте, gandjustas, Вы писали:
G>>А ты можешь адекватно описать зачем все это делавется?
K>Пишу на java. Порядок методов в классе не "вначале все public-методы, а потом private", а примерно "после каждого метода следуют методы которые он использует". Это затрудняет понимание что делает класс, т.к. public-методы теряются среди private-методов, которых обычно больше.

А чем в этом случае поможет интерфейс? Ведь снаружи класса видно только public методы, а изнутри видно все, независимо от интерфейсов.

Перенося все public методы в начало и используя folding в IDE можно быстро найти какие публичные методы есть.

А вообще похоже что у вас классы делают слишком много.

Здравствуйте, kurel, Вы писали:

K>Пишете ли вы интерфейсы (в java называются интерфейсы, для других языков свои аналоги) для всех (или большинства) классов приложения?

Никогда. За подробностями отправлю в Practical API Design: Confessions of a Java Framework Architect.

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

Интерфейсы нужны для функциональности, которые требуются классу/пакету/модулю/библиотеке. Это "внешние" зависимости, которые при этом удовлетворяются на этапе выполнения кода. Интерфейс возникает не тогда, когда "есть функциональность", а когда "для работы мне нужна следующая функциональность". Т.е. сначала формулируется интерфейс (и контракт) и только потом пишется реализация.

Более того, я на практике при возможности в большинстве случаев отказываюсь от интерфейсов. Вместо интерфейсов получения данных (одни get-методы, которые по контракту не меняют значение во времени) можно использовать либо сами данные, либо сделать класс, в котором они будут храниться. Если есть не только данные, вместо интерфейса передаются методы (функции), составляющие этот интерфейс. Т.е. 2-3-4 функции в параметрах конструктора/метода. Интерфейсы тоже остались, но только в некоторых специальных случаях.

K>Или это делается только для тех, которые должны быть полиморфными?

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

Очевидно, что интерфейс при этом не всегда отбражается 1 в 1 на какие-либо классы реализации.

K>Например, если в приложении мне нужен класс SomeClassFactory с методом SomeClass create(typeName), есть ли преимущества от того, что я напишу соответствующий интерфейс и потом класс-реализацию этого интерфейса?

Есть. Вы поймете, что это плохой интерфейс. Вряд ли ваш пользователь класса захочет создавать совершенно произвольные реализации "типов" (иначе как вы реализуете создание произвольных типов в классе?). Скорее всего, список нужных типов (интерфейсов же!) там вполне фиксирован и можно передать фабрику с методами, соответствующими нужным типам. Или вообще передать сами созданные значения (хотя я представляю случаи, когда нужна именно фабрика). В общем, фабрика очень похожа на плохую реализацию Dependency Injection (когда не все нужные зависимости передаются снаружи), хотя могут быть случаи, когда она окажется правильным решением.

K>Если есть преимущества то окупают ли они неудобства (трата времени, пусть очень маленькая, увеличение дерева проекта в IDE за счет появления к каждому классу интерфейса, что затрудняет поиск необходимого класс)?

Они явно документируют тип зависимости как "широкая полиморфная зависимость от окружения". При этом еще и контракт зависимости фиксируют.

Поиск класса лично для меня не проблема. Я не ищу классы в дереве проектов, особенно учитывая возможность нескольких реализации интерфейса (которые и в разных пакетах/модулях могут быть!). Для навигации от интерфейса к реализациям в IDE есть средства. Там, где создаются реализации, конкретный класс в коде уже видно. "Текущий контекст задачи" я вообще помню по именам и использую прямой переход по имени типа. В общем, в дереве проекта я нахожусь только когда читаю исходники друг за другом (ознакомление с кодом или ревью). Да и там при чтении работают все остальные средства навигации.