Comments 8
Не хорошо. Если изменилась только реализация, то и библиотеку интерфейсов менять надо.
Лучше, что бы фактори находила в classpath файл с определённым именем и из него читала имена классов, имплементирующих интерфейс. А этот файл будет лежать только в библиотеке с имплементацией, с классами.
Ну т.е. опять таки проходим к спрингу. Спринг рулез.
Лучше, что бы фактори находила в classpath файл с определённым именем и из него читала имена классов, имплементирующих интерфейс. А этот файл будет лежать только в библиотеке с имплементацией, с классами.
Ну т.е. опять таки проходим к спрингу. Спринг рулез.
JSR 299 же!
Тоже вариант. Хотя спринг я люблю больше — он работает не только в сервере, но и в standalone application, в юнит тестах, где угодно
Так ведь и Weld (aka JSR 299 RE) тоже изначально.
Писал про самые обычные либы.
А интерфейс менять плохо. Лучше расширять его наследованием. Например если надо изменить интерфейс Component, делаем ComponentEx отнаследованный от Component, и добавляем новые методы.
И обратная совместимость сохранится.
А интерфейс менять плохо. Лучше расширять его наследованием. Например если надо изменить интерфейс Component, делаем ComponentEx отнаследованный от Component, и добавляем новые методы.
И обратная совместимость сохранится.
Так я о том и говорю — у Вас, если Вы не меняете интерфейс, а только класс-реализацию, то Вашему пользователю надо менять jar с API тоже. А если имя класса реялизации хранить в classpath resource — тогда не надо!
ServiceLoader вам в помощь. Штатный механизм динамической загрузки компонентов определенного типа. В интерфейсной библиотеке определяете интерфейс компонента, и по необходимости — интерфейс фабрики. А также репозиторий, с помощью ServiceLoader'а в статическом методе, грузящий компоненты/фабрики.
ну проще чем городить огород использовать готовые и давно придуманые решения. IoC (Inversion of control): решение от гугла Guice.
Sign up to leave a comment.
О компонентах и интерфейсах. Java