Я должен все еще кодировать к интерфейсу, даже если я ТОЛЬКО КОГДА-ЛИБО собираюсь иметь ОДНУ реализацию?

Это вопрос детализации . Вы не можете загромождать свой код ненужными интерфейсами, но они полезны на границах между уровнями.

Когда-нибудь вы можете попробовать протестировать класс, который зависит от этого интерфейса. Тогда приятно, что вы можете поиздеваться над этим.

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

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

YAGNI - Вам это не понадобится из Wikipedia

По мнению сторонников подхода YAGNI, соблазн написать код, который сейчас не нужен, но может быть в будущем, имеет следующие недостатки:

* The time spent is taken from adding, testing or improving necessary functionality.
* The new features must be debugged, documented, and supported.
* Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
* Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
* It leads to code bloat; the software becomes larger and more complicated.
* Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
* Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

Два несколько противоречивых ответа на ваш вопрос:

1. Вам не нужно извлекать интерфейс из каждого отдельного конкретного класса, который вы создаете, и
2. Большинство Java-программистов не создают столько интерфейсов, сколько им следовало бы.

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

1. Вы даже подозреваете, что другой конкретный класс может нуждаться в таком же интерфейсе (например, если вы подозреваете, что вашим объектам доступа к данным может потребоваться представление XML в дорога - то, что я ' есть опыт)?
2. Не подозреваете ли вы, что вашему коду может потребоваться размещение на другой стороне уровня веб-служб?
3. Создает ли ваш код уровень обслуживания для какого-то внешнего клиента?

Если вы можете честно ответить «нет» на все эти вопросы, тогда интерфейс может оказаться излишним. Может быть. Но опять же, в программировании главное - это непредвиденные последствия.

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

Поэтому, если вы позже решите, что вам нужно создать формальный интерфейс, у вас должен быть готов дизайн.

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

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

«Только когда-либо будет одна реализация» == известные последние слова

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

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

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

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

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

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

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

только реализация, которая заставляет меня создавать интерфейсы, если они мне нужны при предоставлении зависимостей для тестового примера.

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

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

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

только реализация, которая заставляет меня создавать интерфейсы, если они мне нужны при предоставлении зависимостей для тестового примера.

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

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

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

для удаления дублирования или улучшения читаемости кода.

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

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

чтобы удалить дублирование или улучшить читаемость кода.

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

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

Вопрос должен быть таким: «как вы можете быть уверены, что будет только одна конкретная реализация?»

Как вы можете быть полностью уверены?

К тому времени, когда вы обдумаете это, вы уже создали бы интерфейс и продолжали бы свой путь без предположений, которые могут оказаться неверными.

С сегодняшними инструментами кодирования (такими как Resharper) это действительно не так. На создание и поддержку интерфейсов вместе с классами уходит много времени, тогда как обнаружение того, что теперь вам нужна дополнительная реализация и замена всех конкретных ссылок, может занять много времени и совсем не увлекательно - поверьте мне.

Многое из этого взято из выступления Райнсбергера на InfoQ: http://www.infoq.com/presentations/integration-tests-scam

Есть 3 причины иметь класс:

1. Он содержит какое-то значение
2. Он помогает сохранить некоторую сущность
3. Он выполняет некоторые службы

Большинство служб должны иметь интерфейсы. Он создает границу, скрывает реализацию, и у вас уже есть второй клиент; все тесты, которые взаимодействуют с этой службой.

В принципе, если вы когда-нибудь захотите смоделировать это в модульном тесте, у него должен быть интерфейс.