Разделы презентаций
- Разное
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
I nversion of Control инверсия управления
Содержание
- 1. I nversion of Control инверсия управления
- 2. Инверсия зависимостиЗависимости между классами превращаются в ассоциации между
- 3. 2 принципа инверсии зависимостей:Модули верхнего уровня не
- 4. Схема программы копирования данных
- 5. Сopy может выглядеть примерно следующим образом:
- 6. МИНУСНизкоуровневые классы Keyboard и File обладают высокой гибкостью. Можно
- 7. Используя принцип инверсии зависимостей, можно сделать класс CopyManager независимым от объектов источника и назначения данных.
- 8. Слайд 8
- 9. Класс CopyManager должен полагаться только на выработанные абстракции и не делать никаких предположений по поводу индивидуальных особенностей объектов ввода/вывода:
- 10. Теперь код обладает следующими качествами:класс может быть
- 11. Формы инверсии зависимостейСуществует две формы инверсии зависимостей:
- 12. Пассивная инверсия зависимостей (Dependency Injection):внедрение через конструкторвнедрение через устанавливаемое свойствовнедрение через интерфейсвнедрение через поле
- 13. Активная инверсия зависимостей (Dependency Lookup):pull-подход: предполагается наличие в системе общедоступного
- 14. IoC контейнерIoC контейнер – это специальный объект-сборщик, который на основании
- 15. MEFОна позволяет строить модульные приложения с минимальным
- 16. Слайд 16
- 17. Скачать презентанцию
Инверсия зависимостиЗависимости между классами превращаются в ассоциации между объектами. Ассоциации между объектами могут устанавливаться и меняться во время выполнения приложения. Это позволяет сделать модули менее связанными между собой
Слайды и текст этой презентации
Слайд 2Инверсия зависимости
Зависимости между классами превращаются в ассоциации между объектами.
Ассоциации между
объектами могут устанавливаться и меняться во время выполнения приложения.
модули менее связанными между собой
Слайд 32 принципа инверсии зависимостей:
Модули верхнего уровня не должны зависеть от
модулей нижнего уровня. Оба типа модулей должны зависеть от абстракций;
Абстракция
не должна зависеть от реализации. Реализация должна зависеть от абстракции.
Слайд 6МИНУС
Низкоуровневые классы Keyboard и File обладают высокой гибкостью. Можно легко использовать их
в контексте, отличном от класса CopyManager.
Однако сам класс CopyManager не может
быть повторно использован в другом контексте. Например, для отправки данных из файла системному обработчику логов.
Слайд 7Используя принцип инверсии зависимостей, можно сделать класс CopyManager независимым от объектов источника
и назначения данных.
Слайд 9Класс CopyManager должен полагаться только на выработанные абстракции и не делать
никаких предположений по поводу индивидуальных особенностей объектов ввода/вывода:
Слайд 10Теперь код обладает следующими качествами:
класс может быть использован для копирования
данных в контексте, отличном от данного;
возможно добавлять новые устройства ввода/вывода,
не меняя при этом класс Copy.
Слайд 11Формы инверсии зависимостей
Существует две формы инверсии зависимостей:
активная и пассивная.
При
использовании пассивной формы объекты зависимости внедряются в зависимый объект. Зависимому объекту
не надо прилагать никаких усилий, все нужные сервисы он получает через свой интерфейс.Активная форма, в отличие от пассивной, предполагает, что зависящий объект будет сам получать свои зависимости при помощи вспомогательных объектов.
Слайд 12Пассивная инверсия зависимостей (Dependency Injection):
внедрение через конструктор
внедрение через устанавливаемое свойство
внедрение через интерфейс
внедрение через
поле
Слайд 13Активная инверсия зависимостей (Dependency Lookup):
pull-подход: предполагается наличие в системе общедоступного объекта, который знает
обо всех используемых сервисах. В качестве такого объекта может выступать
объект, реализующий паттерн Service Locator. Локатор реализует паттерн синглетона, благодаря чему доступ к нему можно получить из любого места приложения.push-подход: данная методика отличается от pull-подхода тем, как объект узнает об объекте-локаторе. При использовании pull-подхода класс сам получал локатор посредством класса-синглетона. Push-подход характеризуется тем, что объект-локатор (или как его иногда называют контекст) передается в класс извне (обычно через конструктор).
Слайд 14IoC контейнер
IoC контейнер – это специальный объект-сборщик, который на основании схемы зависимостей между
классами и абстракциями может создать граф объектов. Любой IoC контейнер реализует принцип инверсии
зависимостей.
Слайд 15MEF
Она позволяет строить модульные приложения с минимальным уровнем связности частей
(parts) приложения.
Эта библиотека включает в себя не только Dependency Injection контейнер, но
большой объём инфраструктуры: множество механизмов поиска элементов композиции в сборках, удалённых XAP файлах, механизм пометки элементов композиции с помощью .Net атрибутов и т.д. 
