#java #refactoring
Вопрос:
У нас есть несколько проектов, в которых используются одинаковые и/или похожие имена пакетов. Многие или эти проекты будут создавать файлы jar, которые используются другими проектами. Мы обнаружили ряд исключений foo.util foo.db и foo., в которых используются одни и те же имена классов, что приводит к конфликтам пространства имен.
Кто — нибудь знает инструмент, который будет искать набор баз кода java и автоматически находить конфликты пространства имен и неоднозначный импорт?
Ответ №1:
Проще зафиксировать свои имена в каждом отдельном проекте.
Действительно.
Вам не нужно знать все конфликты. Имена ваших пакетов должны быть уникальными в первую очередь. Если они не уникальны, вам нужно переосмыслить, как вы присваиваете имена своим пакетам. Если они «плоские» ( foo.this и foo.that ), вам нужно сделать их более высокими и более конкретными.
Вот почему примеры всегда org.apache.project.component.lower.level.names есть .
Вы должны иметь com.projectX.foo.this и com.projectZ.foo.that предотвращать возможность дублирования.
«Но вся эта перекомпиляция», — говорите вы. Тебе все равно придется это сделать. Не тратьте много времени на то, чтобы выяснить точную, полную степень. Используйте то, что вы знаете, начните исправлять вещи сейчас и прорабатывайте свою базу кода, исправляя одну вещь за раз.
Комментарии:
1. Теоретически я согласен с вашей рекомендацией, но есть ~35 проектов, и первоначальная цель-просто заставить приложение(ы) работать на другой платформе. После того, как эта цель будет достигнута, будут финансироваться более масштабные и менее глупые методы кодирования. Пока у нас не будет работающего приложения, денег будет мало.
2. Делайте по одной упаковке за раз. Нетрудно переименовать один пакет, а затем исправить все приложения, которые от него зависят. Затем переходите к следующему пакету. Пока вы это делаете, проведите инвентаризацию своих посылок и выясните, кто несет ответственность. По одному за раз.
Ответ №2:
Если вы можете загрузить проекты в Eclipse, в представлении проблем вы увидите конфликты и неоднозначный импорт. Существует также мастер организации импорта, который поможет с любыми ненужными импортами.
Ответ №3:
Я согласен с С. Лоттом — вам нужно в первую очередь выяснить, как это произошло, и сделать это очень болезненным для людей, которые сделали это неправильно (т. Е. Заставить их вернуться и все исправить). Современные IDE (Eclipse является одним из них) делают этот вид рефакторинга довольно простым.
Единственное, с чем я не согласен, — это с тем, чтобы исправлять вещи по ходу дела. Вместо этого я настоятельно рекомендую вам погасить свой технический долг по этому вопросу сейчас с помощью тщательного анализа названия пакета. Пара часов (и это действительно все, что должно потребоваться) здесь избавит вас от кошмарной отладки в будущем.
К вашему сведению — совершенно законно иметь классы в одном пакете в разных исходных папках (например):
src/com/мой/тест проекта/com/мой/проект
Попытка провести различие между приведенной выше допустимой структурой папок и ситуацией, в которой вы оказались, будет очень сложной в любом автоматизированном режиме.