Циклические зависимости или правильный способ построения проекта

Question

У меня есть проект для веб-приложения.

1. Большинство классов этого проекта должны быть составлены в .jar файл и поместить на сервер в codebase/WEB-INF/lib реж. Эти классы используются только сервером.

2. Но у меня есть несколько классов, которые необходимо использовать на сервере и на клиенте. Эти классы должны быть помещены непосредственно в codebase/[package.class].

3. Все эти классы зависят друг от друга и наоборот.

Конец рассказа. Теперь я пытаюсь переместить мой проект из сборки IDE в Gradle. Мой проект содержит два модуля, которые зависят друг от друга. InteljID предостерегает меня и компилирует этот штраф. Но с Грейдлом он застревает. Итак, могу ли я как-то разбить эти классы на две логические группы и иметь простой способ построить структуру, описанную выше?

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

Answer 1

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

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

Рекомендуемая литература:

• Clean Code от «Дядя Боб» Мартин
• Working Effectively with Legacy Code Майкл Перья

Answer 2

Вот некоторые небольшая утилита, которая может оказаться полезной, чтобы сохранить ваш код Java в чистоте циклические зависимости: http://sourceforge.net/projects/jcycles/

Я сделал это, работая на ag когда мне не удалось отслеживать взаимосвязи между классами (чтобы избежать циклов) только на мой взгляд (все библиотеки, связанные с циклами, которые я мог найти, были либо сломанными, либо слишком тяжелыми (со сложными графическими интерфейсами или встроенными в огромные рамки) , и т.д.)).

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

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

-Jeff