Разрешение зависимостей Java-пакетов

Question

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

У меня есть класс Address, который я хочу сделать видимым для разработчиков. На него также ссылаются классы в пакетах my.Contacts, my.Appointments и my.Location - каждый из которых я хочу компилировать, jar-d и доставлять отдельно. Конечно, я хочу, чтобы Address был единым классом - он работает прозрачно для всех компонентов платформы.

Как адрес должен быть упакован, построен и доставлен?

Спасибо!

Answer 1

Две мысли:

1. Address звучит как общий компонент, который может использоваться в различных результатах и ​​поэтому должен быть доступен в некоторых общих или основных library
2. Для ваших компонентов может иметь смысл общаться с интерфейсом Address, и реализация может быть предоставлена ​​отдельно (например, предоставить интерфейс Address и реализацию AddressImpl).Это уменьшит количество связей между основной библиотекой и библиотекой, которую разработчики разработают.

Answer 2

В этом случае Address является частью библиотеки, которая заслуживает своего собственного jar. Если вы создадите класс с именем Address в my.Contacts, my.Appointments и my.Location и захотите использовать все эти файлы jar в одном приложении, у вас будет конфликт для вашего класса Address.

Answer 3

Я предлагаю вам не "доставлять" эти банки отдельно. У Java есть очень тонкие проблемы с версиями, с которыми вы не хотите сталкиваться. Соберите все вместе и упакуйте в один или два баночки и всегда поставляйте оба баночки, или соберите их вместе и поставьте подмножество банок (но никогда не комбинируйте новые и старые банки - не пытайтесь просто отправить одну банку как обновление ).

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

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

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