Как сортировать связанные классы из разных проектов

Question

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

Должен ли я идти на

org.company.interfaceproject.util.InterfaceClass и
org.company.implementationproject.util.ImplementationClass

или

org.comp any.project.util.InterfaceClass и
org.company.project.util.ImplementationClass

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

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

Answer 1

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

org.company.service.UserService 

Тогда мы будем использовать следующие для реализации класса, который был проводной нанимателем или были, пружинные зависимости:

org.company.service.spring.UserServiceImpl 

Это тогда имеет лучшее обеих точек зрения:

1. у вас есть классы чисто в отдельном пакете
2. Используя это имя класса конвенции, то ясно, что сво осущ ectation UserService, и все еще различимы даже при импорте обоих пакетов.

Answer 2

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

Answer 3

Если вы можете положить интерфейсные клады в отдельный плагин/пакет. Когда вы используете интерфейсы, вы в большинстве случаев будете иметь более одной реализации этого интерфейса.

Я бы предпочел вариант 1

Answer 4

ВС имеет Naming conventions. Для пакетов:

Приставка уникального имени пакета всегда пишется во все-строчных ASCII букв и должна быть один из доменов верхнего уровня, в настоящее время ком, Edu, г, млн, чистый, орг, или один из двухбуквенных кодов на английском языке, обозначающих страны, указанные в стандарте ISO 3166, 1981.

Последующие компоненты названия пакета варьируются в соответствии с собственными внутренними соглашениями об именах организации. Такие соглашения могут указывать, что некоторые компоненты имени каталога являются делениями, департаментами, проектами, машинами или именами входа.

Так что я предпочел бы второй вариант, когда вы указываете название проекта. Или я бы объединил оба типа:

org.company.project.interfacepackage.util.InterfaceClass and 
org.company.project.implementationpackage.util.ImplementationClass 

Answer 5

В основном согласен с Клинтоном.

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

 
com.foo.client.* 
com.foo.server.* 
com.foo.common.* 

Главным образом это держит ваши наборы файлов ant. Обратите внимание, что это применимо даже в том случае, если расположение исходных файлов совершенно иное, из-за того, как вещи создаются или что-то еще. Единственное, что я хотел бы сказать, это быть осторожным, чтобы не получить один и тот же пакет в нескольких каталогах-источниках! Это может быть уродливо и легко сделать случайно.

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