Spring Framework – первые шаги (Конспект седьмой)

Сегодня мы постараемся разобраться в преимуществах и недостатках, как Constructor Injection (CI), так и Setter Injection (SI).

Конспект седьмой : Constructor versus Setter Injection (продолжение)

Во-первых, следует отметить, что предпочтительно создавать „готовый“ объект со всеми инициализациями его полей в одном месте. Поэтому, использование конструктора является прозрачным и более понятным механизмом, т.к. всем разработчикам отлично видно, что и как было инициализированно в момент создания объекта.

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

Вышеописанный метод безусловно хорош, однако при наличии большого количества полей класса (как мне кажется более 5), наличие перегруженных конструкторов может стать ночным кошмаром. Правда, мы не должны забывать и тот факт, что с точки зрения дизайна приложения, класс, содержащий такое количество параметров, вероятнее всего является слишком „тяжелым“ и его необходимо подвергнуть рефакторингу – разделить на подклассы, etc. Но все же, в подобном случае, когда количество параметров велико, необходимо переходить к использованию Setter Injection.

С другой стороны, непосредственно сами разработчики Spring Framework, рекомендуют использовать именно Setter Injection, т.к. Constructor Injection может приводить к „ужасному“ (messy) коду, и кроме этого Setter Injection позволяет производить переконфигурирование системы во время работы.

Следует так же отметить, что компоненты связанные с session-компонентами, в любом случае должны конфигурироваться исключительно с помощью Setter Injection – почему? Мы ответим на этот вопрос в одной из следующих лекций, когда будем рассматривать диапазоны жизненого цикла компонент (scope).

При использовании Constructor Injection, может возникнуть еще одна проблема, известная как Кольцевая Зависимость (Circular dependencies). Представьте себе ситуацию, когда конструктор класса А требует в качестве параметра экземпляр класса B, а тот в свою очередь требует в констуркторе наличие класса A!? В этом случае, Spring Framework, не сможет „поднять“ экземпляры упомянутых компонент (beans), и выбросит исключительную ситуацию: BeanCurrentlyInCreationException. Выходом из подобной ситуации будет переход к Setter Injection. В этом случае при создании объектов, поля будут проинициализиорованы null и только в следующем проходе Spring выполнит Setter Injection.

Таким образом, не существует жестких требований, заставляющих разработчиков использовать тот или иной метод. Более того, современные фреймворки, как правило поддерживают как SI, так и CI. Не является исключением в этом плане и Spring Framework. Пользуйтесь здравым смыслом и приобретенным опытом 😉 .

This entry was posted in Java, Main menu and tagged . Bookmark the permalink.
  • d.max

    u00a0u0437u0430u043cu0435u0447u0430u0442u0435u043bu044cu043du044bu0439 u0446u0438u043au043b u0441u0442u0430u0442u0435u0439. u0432u0441u0451 u043fu0440u0435u0434u0435u043bu044cu043du043e u044fu0441u043du043e u0440u0430u0441u043fu0438u0441u0430u043du043e. u0441u043fu0430u0441u0438u0431u043e!

    • Anonymous

      u042f u0440u0430u0434, u0447u0442u043e u0441u0442u0430u0442u044cu0438 u043du0440u0430u0432u044fu0442u0441u044f. u041fu043eu044fu0432u0438u0442u0441u044f u0432u0440u0435u043cu044f – u0431u0443u0434u0435u0442 u043fu0440u043eu0434u043eu043bu0436u0435u043du0438u0435 😉

  • Mmm

    Очень интересный статьи. Приятно написаны.Благодарю