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

Question

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

Answer 1

Я думаю, что вы не должны;)

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

ЯГНИ - Тебе это не нужно из Википедии

По мнению тех, кто защищает подход 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.

Answer 5

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

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

Answer 9

Большая часть этого взята из беседы Рейнсбергера на InfoQ: http://www.infoq.com/presentations/integration-tests-scam

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

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

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

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

Answer 10

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

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

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

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