Структура каталога интерфейсов Java?

Ответ 1

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

Ответ 2

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

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

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.

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Если структура pureooabstraction/directory будет содержать только "чистые абстрактные классы" (с точки зрения OO, а не абстрактное "определение Java" ), aka интерфейсы в Java.

И мелкие детали реализации (которые не существуют на уровне OOA/OOD), где "код" лежит, находятся в каталоге src/.

Конечно, имеет смысл, если ваш процесс разработки переходит от OOA к OOD в OOP.