Главная страница
Навигация по странице:

  • Два вида прокси можно выделить

  • Плюсы прокси-объектов

  • 4. Что такое Inversion of Control и как Spring реализует этот принцип

  • Преимущества этой архитектуры

  • Объекты могут быть получены одним из двух способов

  • 2. Dependency Injection (внедрение зависимости)

  • 4.1. Service locator

  • В некотором случае локатор служб фактически является анти-шаблоном, потому что

  • Преимущества

  • Инструкция по созданию бизнесобъектов. Strategy это поведенческий паттерн, выносит набор алгоритмов в собственные классы и делает их взаимозаменимыми


    Скачать 0.73 Mb.
    НазваниеИнструкция по созданию бизнесобъектов. Strategy это поведенческий паттерн, выносит набор алгоритмов в собственные классы и делает их взаимозаменимыми
    Дата13.11.2022
    Размер0.73 Mb.
    Формат файлаdocx
    Имя файла2.docx
    ТипИнструкция
    #785689
    страница3 из 26
    1   2   3   4   5   6   7   8   9   ...   26

    3.1. Что такое проси объекты?


    Proxy — это специальный объект, который имеет такие же публичные методы как и бин, но у которого есть дополнительная функциональность.

    Два вида прокси можно выделить:

    JDK-proxy — динамическое прокси. API встроены в JDK. Для него необходим интерфейс

    CGLib proxy — не встроен в JDK. Используется, когда интерфейс объекта недоступен

    Плюсы прокси-объектов:

    1.Позволяют добавлять доп. логику — управление транзакциями, безопасность, логирование;

    2. Отделяет некоторый код (логирование и т.п.) от основной логики.

    4. Что такое Inversion of Control и как Spring реализует этот принцип?


    IoC (Inversion of Control) — инверсия управления. Это принцип в разработке программного обеспечения, при котором управление объектами или частями программы передается контейнеру или фреймворку, т.е не программист управляет процессом выполнения кода/программы, а фреймворк это делает вместо него. Программист делегирует управление Spring это и есть инверсия управления.

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

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

    Преимущества этой архитектуры:

    1. Отделение выполнения задачи от ее реализации;

    2. Легкое переключение между различными реализациями;

    3. Большая модульность программы;

    4. Более легкое тестирование программы путем изоляции компонента или проверки его зависимостей и обеспечения взаимодействия компонентов через контракты.

    Центральной частью Spring является подход Inversion of Control, который позволяет конфигурировать и управлять объектами Java с помощью рефлексии.

    Вместо ручного внедрения зависимостей, фреймворк забирает ответственность за это посредством контейнера.

    Контейнер отвечает за управление жизненным циклом объекта: создание объектов, вызов методов инициализации и конфигурирование объектов путем связывания их между собой.

    Обычно, конфигурирование контейнера, осуществляется путем внедрения аннотаций (начиная с 5 версии J2SE), но также, есть возможность, по старинке, загрузить XML-файлы, содержащие определение bean’ов и предоставляющие информацию, необходимую для создания bean’ов.

    Объекты могут быть получены одним из двух способов:

    1. Dependency Lookup (поиск зависимости)шаблон проектирования, в котором вызывающий объект запрашивает у объекта-контейнера экземпляр объекта с определенным именем или определенного типа.

    2. Dependency Injection (внедрение зависимости) — шаблон проектирования, в котором контейнер передает экземпляры объектов по их имени другим объектам с помощью конструктора, свойства или фабричного метода.

    Инверсия управления может быть достигнута с помощью различных механизмов, таких как: шаблон проектирования “Strategy”, шаблон “Service locator”, шаблон “Factory method” и внедрение зависимостей (DI).

    4.1. Service locator?


    Service locator – это шаблон проектирования, используемый в разработке программного обеспечения для инкапсуляции процессов, связанных с получением какого-либо сервиса с сильным уровнем абстракции.

    Этот шаблон использует центральный реестр, известный как «локатор сервисов», который по запросу возвращает информацию (как правило это объекты), необходимую для выполнения определенной задачи.

    В некотором случае локатор служб фактически является анти-шаблоном, потому что:

    1. Отношения между компонентами приложения, помещенные в реестр, скрывают зависимости частей программы (делают их неочевидными) и увеличивают сложность системы. Это затрудняет поиск ошибок в приложении и может сделать систему в целом менее надежной;

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

    3. Реестр может быть серьезной уязвимостью безопасности, поскольку он позволяет посторонним (в том числе злоумышленникам) вводить код в приложение;

    4. Реестр скрывает зависимости класса, вызывая ошибки во время выполнения, а не ошибки времени компиляции, когда при отсутствии необходимых зависимостей компилятор информирует об ошибке;

    5. Реестр делает код более сложным для поддержания (против использования инъекции зависимостей), потому что становится неясным, когда вносится ошибочная запись в реестр или пропускается необходимая запись;

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

    Однако это легко преодолеть, введя классы приложений с помощью одного интерфейса локатора служб.

    Преимущества:

    1. Service locator может действовать как простой компоновщик времени выполнения.

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

    2. Приложения могут оптимизировать себя во время выполнения путем выборочного добавления и удаления элементов из локатора служб;

    Например, приложение может обнаружить, что у него есть лучшая библиотека для чтения доступных изображений JPG, чем стандартная, и соответствующим образом изменить реестр;

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

    1   2   3   4   5   6   7   8   9   ...   26


    написать администратору сайта