Программирование на основе интерфейсов: пишете ли вы интерфейсы для всех классов вашего домена?

* Я делаю это, потому что мне это нужно для создания прокси моих доменных объектов.

Мы в основном пишем веб-приложения с Wicket, Spring и Hibernate, и мы используем интерфейсы для Spring Beans, например. Услуги и DAO. Для этих классов интерфейсы имеют смысл. Но мы также используем интерфейсы для каждого класса домена, и я думаю, что это просто излишество.

Написание интерфейса до того, как он понадобится (либо для тестирования, либо для архитектуры), является излишним.

Кроме того, написание интерфейса вручную - пустая трата времени. Вы можете использовать рефакторинг Resharper «Pull Members», чтобы позволить ему создать новый интерфейс из определенного класса в считанные секунды. Другие инструменты рефакторинга, которые интегрируются с IDE, также должны иметь аналогичную функциональность.

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

Довольно просто в IDEA / eclipse превращать конкретный класс в интерфейс, когда вы решите, что он вам нужен.

Затем используйте внедрение зависимостей с помощью Spring или Guice , если у вас есть много реализаций интерфейса для внедрения в места в вашем коде, которые вы используете «new»

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

Это, конечно, не означает, что нужно избегать использования интерфейсов в доменных объектах. Используйте там, где это необходимо. Например, в последнее время я работал над веб-приложением, в котором разные типы доменных объектов соответствуют страницам с постоянными ссылками, в которых пользователи могут оставлять комментарии. Итак, каждый из этих доменных объектов теперь реализует интерфейс «Commentable». Весь код, основанный на комментариях, затем программируется в интерфейсе Commentable, а не в доменных объектах.

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

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

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

Это - другая вещь иметь в виду, что я работал в к, особенно со сгенерированным доменом и объектами ДАО. Много интерфейсов просто слишком конкретно. Скажите, что много объектов области имеет идентификатор и поле состояния, Почему они не совместно используют единый интерфейс? Это вызвало меня разочарование, излишне плоская (мудрая наследованием) модель предметной области.

Мы извлекаем интерфейсы из всего просто, потому что это помогает в тестировании (насмешки) и для материала как AOP. Eclipse может сделать это автоматически: осуществите рефакторинг-> Интерфейс Извлечения.

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

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

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

Я думаю, что главной причиной для программирования против интерфейсов является тестируемость. Следовательно, для объектов области - просто придерживаются POJOs или POC#Os:) и т.д., т.е. просто мешают Вашим классам добавлять любую определенную платформу так для предотвращения их от различной сборки и зависимостей во время выполнения, и это - все. Создание интерфейсов для ДАО является хорошей идеей все же.

Даже если Вы вполне уверены, там будет только одним конкретным типом объекта модели, использование интерфейсов делает насмешку и тестирование несколько легче (но в эти дни существуют framworks, которые могут помочь Вам генерировать ложные классы автоматически, даже для конкретных классов Java - Mockito, JTestR, Spring, Groovy...)

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

На самом деле, этот вопрос является примером распространенного заблуждения о «программировании против интерфейсов».

Видите ли, это очень хороший принцип, но он действительно не означают то, что многие люди думают!

«Программа для интерфейса, а не реализация» (из книги GoF) означает именно это, а не то, что вы должны изо всех сил стараться изо всех сил, чтобы создать отдельных интерфейсов для всего. Если у вас есть объект ArrayList , объявите тип переменной / поля / параметра / возвращаемого значения как имеющий тип List . Тогда клиентский код будет иметь дело только с типом интерфейса.

В книге Джошуа Блоха «Эффективная Java» принцип выражен более четко в «Правиле 52: Обращайтесь к объектам по их интерфейсам». interface, если подходящий интерфейс не существует.

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

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