Java-ведение многостраничного приложения из разделяющей кодовой базы

Question

Я пишу приложение, которое будет поставляться в нескольких разных версиях (изначально около 10 вариантов базы кода будут существовать и их необходимо будет поддерживать). Конечно, 98% или около того кода будут одинаковыми среди разных систем, и имеет смысл сохранить базу кода без изменений.

Мой вопрос: какой был бы предпочтительный способ сделать это? Если у меня, например, есть класс (MyClass), который отличается в некоторых версиях (MyClassDifferent), и этот класс упоминается в нескольких местах. Я бы хотел, чтобы эта ссылка изменилась в зависимости от того, какую версию приложения я компилирую, вместо того, чтобы разделить все классы, относящиеся к MyClassDifferent. Макросы препроцессора были бы хороши, но они раздувают код и afaik, есть только доказательства реализации концепций?

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

Answer 1

Посмотрите шаблон дизайна AbstractFactory, «Инъекция зависимостей» и «Инверсия управления». Мартин Фаулер пишет об этих here.

Вкратце, вы отправляете файлы JAR со всеми необходимыми компонентами. Для каждой точки обслуживания, которая может быть настроена, вы определяете интерфейс для службы. Затем вы пишете одну или несколько реализаций этого интерфейса. Чтобы создать объект службы, вы спросите AbstractFactory для него, например:

AbstractFactory factory = new AbstractFactory(); 
... 
ServiceXYZ s = factory.newServiceXYZ(); 
s.doThis(); 
s.doThat(); 

Внутри вашего AbstractFactory вы построить соответствующий объект ServiceXYZ с помощью Java-метода отражения Class.classForName(), и SomeClassObject.newInstance(). (Выполнение этого способа означает, что вам не нужно иметь класс ServiceXYZ в файлах jar, если это не имеет смысла. Вы также можете создавать объекты в обычном режиме.)

Фактические имена классов считываются из файла свойств, уникального для каждого сайта.

Вы можете легко свернуть собственное решение или использовать фреймворк, например Spring, Guice или Pico.

Answer 2

Вы на правильном пути: Заводские модели, конфигурация и т.д.

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

Answer 3

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

Препроцессорные макросы, подобные C/C++, недоступны непосредственно для java. Хотя, возможно, можно эмулировать это через скрипты сборки. Но я не пошел бы по этой дороге. Мое предложение - придерживаться заводского подхода.

Answer 4

, к счастью, у вас есть несколько вариантов

1) ServiceLoader (в java6 встроенной) положить класс API как MyClass в банке, то скомпилировать приложение против этого API. Затем добавьте отдельную реализацию MyClass в отдельную банку с помощью /META-INF/services/com.foo.MyClass. , Затем вы можете поддерживать несколько версий своего приложения, просто сохраняя «распределение» банок. Ваш "основной" класс просто куча ServiceLoader называет

2) та же архитектура, 1), но заменяя META-INF услуг с Spring или Guice конфигурации

3) OSGI

4) Ваше решение