Я как-то видел реализации, где в настроечные данные прописывался, кроме прочего, идентификатор класса-обработчика. По-моему, вытаскивать в настройки "внутренности" реализации того или иного функционала - это очень пагубный подход. Во-первых, откуда тот, кто выполняет настройку, должен знать название/идентификатор класса-обработчика? Во-вторых, откуда он знает, что со временем что-то не поменяется, и не будет использоваться другой класс-обработчик? Кто в таком случае обновит настроечные данные? В общем, это хорошо для пакетных заданий, потому что там инфраструктура заранее не знает, какой именно наследник RunBaseBatch будет использоваться, и наследников этих может быть сколь угодно много, а для других случаев это опять-таки, по-моему, - очень пагубный подход.
Есть стандартный подход для таких ситуаций: заводится енум с перечислением различных разновидностей чего-нибудь, и делается статический метод, который по значению енума создает и возвращает экземпляр нужного класса-обработчика. Плюсы такого подхода:
- отвязывание настроек от реализации;
- повышение гибкости реализации (сегодня несколько значений енума могут обрабатываться одним классом, завтра - несколькими, по классу на значение);
- возможность использования строгой типизации с контролем на этапе компиляции (метод-конструктор возвращает не абы что, а предположительно наследника определенного базового класса либо класс, реализующий заранее известный интерфейс).