Презентация - Принцип единственной обязанности. Адаптер. Принцип разделения интерфейсов

Смотреть слайды в полном размере
Презентация Принцип единственной обязанности. Адаптер. Принцип разделения интерфейсов


Вашему вниманию предлагается презентация на тему «Принцип единственной обязанности. Адаптер. Принцип разделения интерфейсов», с которой можно предварительно ознакомиться, просмотреть текст и слайды к ней, а так же, в случае, если она вам подходит - скачать файл для редактирования или печати.

Презентация содержит 24 слайда и доступна для скачивания в формате ppt. Размер скачиваемого файла: 113.43 KB

Просмотреть и скачать

Pic.1
Осенний семестр 2017 Преподаватель: асс. каф. Чуканов В. С
Осенний семестр 2017 Преподаватель: асс. каф. Чуканов В. С
Pic.2
Содержание Принцип единственной обязанности Адаптер Соединение интерфейсов Адаптер класса и адаптер
Содержание Принцип единственной обязанности Адаптер Соединение интерфейсов Адаптер класса и адаптер объекта Применение адаптера Принцип разделения интерфейсов Заключение
Pic.3
Принцип Единственной Обязанности АТД – абстрактный тип данных Замкнутое множество данные + методы Si
Принцип Единственной Обязанности АТД – абстрактный тип данных Замкнутое множество данные + методы Single Responsibility Principle (SRP) Класс должен иметь лишь одну причину для изменения Обязанность = ось изменения Атомарный набор методы + данные = АТД Принцип SRP: каждый класс реализует 1 АТД
Pic.4
SRP: Пример Rectangle Rectangle Используется для расчета площади и визуализации Две обязанности = 2
SRP: Пример Rectangle Rectangle Используется для расчета площади и визуализации Две обязанности = 2 АТД Какие проблемы это может вызвать?
Pic.5
SRP: Решение Примера Rectangle Избыточная связь между приложениями выч. геом и визуализации Изменени
SRP: Решение Примера Rectangle Избыточная связь между приложениями выч. геом и визуализации Изменение в модуле выч. геом могло привести к необходимости пересобирать модуль визуализации Решение: разделить обязанности Rectangle по двум классам
Pic.6
SRP: Пример Modem Modem Интерфейс сетевого взаимодействия
SRP: Пример Modem Modem Интерфейс сетевого взаимодействия
Pic.7
SRP: Пример Modem Разделение обязанностей не всегда является необходимым Особенности оборудования/ОС
SRP: Пример Modem Разделение обязанностей не всегда является необходимым Особенности оборудования/ОС могут обуславливать слияние обязанностей в одном классе Определяется постановкой задачи и возможностью изменения обязанностей независимо Разделение обязанностей может быть реализовано с помощью паттернов Фасад (Facade) и Заместитель (Proxy)
Pic.8
Шаблон Проектирования: Адаптер Позволяет повторно использовать реализованную функциональность при не
Шаблон Проектирования: Адаптер Позволяет повторно использовать реализованную функциональность при несовместимых интерфейсах Технически – переадресация вызова от одного интерфейса к другому Пример Имеется реализованный в библиотеке класс для генерации случайных, равномерно распределенных чисел в интервале [0, 1] Необходимо написать класс для генерации чисел в интервале [0, 100]
Pic.9
Пример Адаптера: Код Библиотечных Классов
Пример Адаптера: Код Библиотечных Классов
Pic.10
Пример Адаптера: Код Библиотечных Классов (2)
Пример Адаптера: Код Библиотечных Классов (2)
Pic.11
Пример Адаптера: Код Целевого Класса Решение Объявляем интерфейс класса для генерации чисел в заданн
Пример Адаптера: Код Целевого Класса Решение Объявляем интерфейс класса для генерации чисел в заданном диапазоне Объявляем виртуальный метод getValue() Создаем наследника с реализацией виртуального метода getValue() Реализация может адаптировать как интерфейсный метод, так и быть привязанной к одной выбранной реализации Адаптер объекта VS адаптер класса
Pic.12
Адаптер: Решение Интерфейс класса
Адаптер: Решение Интерфейс класса
Pic.13
Адаптер Класса Реализация адаптера
Адаптер Класса Реализация адаптера
Pic.14
Адаптер Объекта Реализация адаптера
Адаптер Объекта Реализация адаптера
Pic.15
Принцип Разделения Интерфейсов «Жирные» интерфейсы Состоят из множества несцепленных функций Реализу
Принцип Разделения Интерфейсов «Жирные» интерфейсы Состоят из множества несцепленных функций Реализуют более 1 АТД Перегруженные функциями интерфейсы приводят к жесткости, хрупкости и тд Рассмотрим класс Door
Pic.16
«Загрязнение» Интерфейса Новое требование Новый тип дверей: вызывают сигнал тревоги, если слишком до
«Загрязнение» Интерфейса Новое требование Новый тип дверей: вызывают сигнал тревоги, если слишком долго открыты Класс TimedDoor Поддержка абстракции TimerClient Класс, реагирующий на истечение времени таймера
Pic.17
Взаимодействие TimedDoor & Timer
Взаимодействие TimedDoor & Timer
Pic.18
Анализ Door теперь зависит от TimerClient Изначальная абстракция Door не имела подобной зависимости
Анализ Door теперь зависит от TimerClient Изначальная абстракция Door не имела подобной зависимости Реализации Door, не требующие отсчета времени, будут обязаны реализовать метод TimeOut()
Pic.19
Жесткость и Вязкость Решения Новое требование – регистрация более одного запроса на истечение времен
Жесткость и Вязкость Решения Новое требование – регистрация более одного запроса на истечение времени Любое изменение TimerClient повлечет изменения во всех объектах Door
Pic.20
Решение: Использование Адаптера Адаптер Разделяет иерархии Door & TimerClient «Транслирует» инте
Решение: Использование Адаптера Адаптер Разделяет иерархии Door & TimerClient «Транслирует» интерфейс TimerClient в TimedDoor
Pic.21
Решение: Использование Адаптера (2)
Решение: Использование Адаптера (2)
Pic.22
Анализ Каждый вызов регистрации запроса на таймер вынуждает создать объект-адаптер DoorTimerAdapter
Анализ Каждый вызов регистрации запроса на таймер вынуждает создать объект-адаптер DoorTimerAdapter doorAdapter(door); timer->Register(timeOut, timeOutId, &doorAdapter); Какое еще существует решение?
Pic.23
Решение: Множественное Наследование
Решение: Множественное Наследование
Pic.24
Заключение Принцип единственной обязанности Каждый класс должен реализовывать лишь одну «ось изменен
Заключение Принцип единственной обязанности Каждый класс должен реализовывать лишь одну «ось изменения» Адаптер Паттерн проектирования для улучшения коэф. повторного использования кода Переадресовывает операции одного интерфейса в другой Принцип разделения интерфейсов «Жирные» интерфейсы приводят к вязкости и жесткости Интерфейсы могут быть разделены посредством адаптера или множественного наследования


Скачать презентацию

Если вам понравился сайт и размещенные на нем материалы, пожалуйста, не забывайте поделиться этой страничкой в социальных сетях и с друзьями! Спасибо!