Структура каталогов интерфейсов Java? - PullRequest
19 голосов
/ 29 января 2010

Должны ли интерфейсы в Java находиться в своем собственном каталоге? Или и интерфейс, и его реализация должны находиться в одном каталоге (пакете)? Спасибо.

Ответы [ 7 ]

14 голосов
/ 29 января 2010

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

Например, интерфейсы могут быть здесь:

com.myproject.data.dao.CustomerDao (some people do ICustomerDao for interfaces, but some don't like that.)
com.myproject.data.dao.ProductDao

И реализации могут быть здесь:

com.myproject.data.dao.hibernate.HibernateCustomerDao
com.myproject.data.dao.hibernate.HibernateProductDao
com.myproject.data.dao.someotherorm.SomeOtherOrmCustomerDao
etc.

Это может работать в некоторых ситуациях, а может и не в других, но просто о чем подумать.

11 голосов
/ 29 января 2010

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

6 голосов
/ 30 января 2010

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

В некоторых проектах мы даже зашли так далеко, что поместили все интерфейсы в один подпроект (модуль maven) и реализации в другой. Таким образом было возможно ПОЛНОСТЬЮ отделить интерфейсы от реализаций, завершить проект интерфейса очень рано в проекте и передать его другим командам, работающим с этими интерфейсами. В каждом из проектов мы использовали одинаковые пакеты.

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

0 голосов
/ 16 марта 2015

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

Я думаю, что худшая практика - настаивать на том, что у вас должен быть другой каталог для интерфейсов. Я видел такие каталоги, как / services и / impl и другие, которые только портят структуру каталогов. На моем нынешнем рабочем месте у нас работает много подрядчиков, и некоторые из наших проектов имеют несколько типов интерфейсных каталогов. Единственный раз, когда я думаю, что имеет смысл использовать отдельный каталог, если вы планируете копировать интерфейсы в другие проекты, например, для EJB, но даже в этом случае они могут иметь один и тот же пакет, если вы используете общий проект для интерфейсов.

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

0 голосов
/ 30 января 2010

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

pureooabstraction/
 |
 |_com/
   |
   |_example/
     |
     |__SomeInterface.java
     |__SomeOtherInterface.java

src/
 |
 |_com/
   |
   |_example/
     |
     |__SomeClass.java
     |__...

Где каталог pureooabstraction / структура будет содержать только «чистые абстрактные классы» (с точки зрения ОО, а не «абстрактное» определение Java), то есть интерфейсы в Java .

А мелкие детали реализации (которых нет на уровне OOA / OOD), в которых лежит «код», будут помещены в каталог src / .

Это, безусловно, имеет смысл, если ваш процесс разработки переходит от ООА к ООД и ООП.

0 голосов
/ 29 января 2010

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

0 голосов
/ 29 января 2010

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

...