Как отсортировать связанные классы из разных проектов - PullRequest
1 голос
/ 06 мая 2009

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

Должен ли я пойти на

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

или

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

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

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

Ответы [ 5 ]

2 голосов
/ 06 мая 2009

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

org.company.service.UserService

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

org.company.service.spring.UserServiceImpl

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

  1. У вас чисто классы в отдельном пакете
  2. Используя это соглашение об именах классов, становится ясно, что это реализация UserService, и она по-прежнему различима даже при импорте обоих пакетов.
1 голос
/ 06 мая 2009

Sun имеет Соглашения об именах . Для пакетов:

Префикс уникального имени пакета всегда пишется строчными буквами ASCII и должен быть одним из доменных имен верхнего уровня, в настоящее время com, edu, gov, mil, net, org или одним из двух английских. коды, обозначающие страны в соответствии со стандартом ISO 3166, 1981.

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

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

org.company.project.interfacepackage.util.InterfaceClass and
org.company.project.implementationpackage.util.ImplementationClass
1 голос
/ 06 мая 2009

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

0 голосов
/ 06 мая 2009

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

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

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

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

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

0 голосов
/ 06 мая 2009

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

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

...