Это плохая практика «смешивать класс и интерфейсы в одном пакете»? - PullRequest
8 голосов
/ 05 января 2011

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

Поэтому мне интересно, есть ли причины для разделения интерфейсови реализации в Java.

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

С уважениемМайк[; -)

Ответы [ 4 ]

10 голосов
/ 05 января 2011

Я согласен с org.life.java - у меня будут пакеты service и лежащие в основе service.impl, но всегда в таком порядке.

Я не согласен с формулировкой "плохая практика".Это слишком сильно.

API коллекций java.util противоречит этому совету.Я не хотел бы быть тем, кто скажет Джошуа Блоху, что он сделал «плохую работу».

8 голосов
/ 05 января 2011

Причины сохранения интерфейсов и реализации в отдельных пакетах:

чистая кодовая база - выглядит «лучше», более аккуратно, если у нас есть один пакет с интерфейсами и другой с реализациями (обычно это пространство имен something.impl). И структура кода показывает / отражает то, что вы кодируете против интерфейсов.

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

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

7 голосов
/ 05 января 2011

Для OSGi почти необходимо использовать отдельные пакеты AFAIK, чтобы вы могли экспортировать / импортировать API без экспорта / импорта реализации.

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

3 голосов
/ 05 января 2011

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

например

com.mycompany.domain.service  
com.mycompany.domain.service.impl

Преимущества

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