Java соединяет интерфейсом со структурой каталогов?
Должны интерфейсы в Java находиться в их собственном каталоге? Или должен и интерфейс и его реализация быть помещенными в тот же каталог (пакет)? Спасибо.
6 ответов
Интерфейсы не нуждаются в собственном каталоге. Они должны быть размещены там, где это имеет смысл, точно так же, как и классы должны быть размещены там, где это имеет смысл. Во многих случаях имеет смысл поместить их в одно и то же место.
Это вообще не нужно для размещения интерфейса в том же каталоге (пакет). Если ваш интерфейс имеет публичный доступ, то вы можете импортировать его нигде в любом пакете.
Та же пакет. Пользователь не должен знать или оказывать, что они используют интерфейс
Вопрос в том, как я его прочитал (но тогда он странно сформулирован), не заключается в том, должен ли интерфейс быть в их собственном каталоге или нет. Вопрос в том, следует ли вам воссоздать всю структуру каталога (жирным шрифтом выделено, что в заголовке вопроса), где одна ветка будет содержать только интерфейсы, как например:
pureooabstraction/
|
|_com/
|
|_example/
|
|__SomeInterface.java
|__SomeOtherInterface.java
src/
|
|_com/
|
|_example/
|
|__SomeClass.java
|__...
Где pureooabstraction/ каталог структура будет содержать только "чистые абстрактные классы" (с точки зрения OO, а не Java "абстрактное" определение), так же известные как интерфейсы на Java.
А мелочные детали реализации (которые не существуют на уровне OOA/OOD), где "код" лежал бы в директории src/.
Конечно, имеет смысл, если ваш процесс разработки переходит от ООА к ООД к ООП.
Один видел у рисунка, - это поставить интерфейсы в базовый каталог, затем поместите реализации в подкаталог оттуда.
Например, интерфейсы могут пойти сюда:
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.
Это может работать в некоторых ситуациях, а не в других, а просто что-то, о чем думать.
Так как уже есть хорошие моменты, я хочу добавить только одно:
В некоторых проектах мы даже зашли так далеко, что разместили все интерфейсы в одном подпроекте (maven module) и реализации в другом. Таким образом можно было ПОЛНОСТЬЮ отделить интерфейсы от реализаций и закончить проект интерфейсов очень рано в проекте и передать его другим командам, работающим с этими интерфейсами. В каждом из проектов мы использовали одни и те же пакеты.
В общем, я бы сказал, что нужно отделять интерфейсы и их реализации, способ не имеет значения, если вы с ним согласны.