Организация процесса проектирования ПО

1.

Лекция: Шаблоны проектирования (части 4-5)
1

2.

К следующей лекции:
Нужен аккаунт на github, и установленный git.
Для нотификаций будем использовать телеграм.
Для запуска локально нужен nodejs, лучше его поставить через NVM:
●Linux: https://github.com/nvm-sh/nvm;
●Windows: https://github.com/coreybutler/nvm-windows)
Студенты могут подключиться по ссылке со своих компьютеров (с наушниками).
В конце можно задать вопросы на любую тему, не только по материалам.
Вопросы можно подготовить заранее.
2

3.

Содержание
4.1 Иерархия кэшей;
4.2 Идиома fast pimpl;
4.3 Паттерны Наблюдатель, Издатель-подписчик и
Производитель-Потребитель;
4.4 Паттерны Состояние и Стратегия;
5.1 Паттерны Прототип и Объектный пул;
5.2 Паттерн Property;
5.3 Паттерн Команда;
3

4.

4.1 Иерархия кэшей.
Вопросы к видео (до)
1. Можно ли оптимизировать программу под кэши? - Кто должен этим заниматься?
2. Что с попаданием в кэши у связных списков?
3. Что является хэш-функцией объекта при размещении в кэше?
4. Может ли программа на Java/Python/… эффективно работать с кэшами?
5. Есть ли смысл использовать ассоциативные контейнеры для повышения
эффективности? - Как они работают с кэшами?
4

5.

4.2 Идиома fast pimpl. Проблема, решаемая Pimpl
5

6.

4.2 Идиома fast pimpl. Проблема, решаемая Pimpl
6

7.

4.2 Идиома fast pimpl. Решение pimpl.
Неудачная попытка
7

8.

4.2 Идиома fast pimpl. Решение, предлагаемое pimpl
8

9.

4.2 Идиома fast pimpl. Плюсы и минусы pimpl
В header file остаются только те части кода, которые не требуют
знания о полном типе.
Минусы:
• Динамическая аллокация;
• Не кеш дружелюбно.
Плюсы:
●Не торчат наружу детали реализации
9

10.

4.2 Идиома fast pimpl. Идея
10

11.

4.2 Идиома fast pimpl. Первая реализация
11

12.

4.2 Идиома fast pimpl. Первая реализация
Плюсы:
●Не торчат наружу детали реализации.
●Кеш дружелюбно.
Минусы:
●Нужно писать стороннюю программу.
●Следить за временем жизни.
●reinterpret_cast.
●Приходится сильно менять cpp файл.
12

13.

4.2 Идиома fast pimpl. Вторая реализация
default вместо data_{std::make_unique<third_party::Json>()}
13

14.

4.2 Идиома fast pimpl. Вторая реализация
https://habr.com/en/post/111602/ простая, но не такая красивая
реализация Fast Pimpl
https://wiki.qt.io/D-Pointer - d-указатели,
так в Qt называется Pimpl, другие, но
тоже интересные реализации со
своими плюсами и минусами;
https://github.com/sqjk/pimpl_ptr работающий исходник, готовая
реализация шаблонного pimpl на
С++11.
https://www.youtube.com/watch?v=mkPTr
eWiglk&feature=emb_logo имплементация от Яндекс.
14

15.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
(с википедии — проблема изучения паттернов)
Наблюдатель - … позволяет объекту класса получать оповещения об изменении
состояния других объектов (наблюдать за ними).
… при изменении состояния одного объекта все зависящие от него оповещаются
об этом событии.
Пример кода
Еще более невнятный.
15

16.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
(GoF)
Наблюдатель - … при изменении состояния одного объекта все зависящие от него
оповещаются и автоматически обновляются.
16

17.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
Издатель-подписчик — расширение шаблона Наблюдатель с описанием канала
передачи сообщения. Часто каналом выступает посредник, который инкапсулирует
логику подписки и доставки — подписка на определенные темы, фильтрацию
сообщений и т.д.
17

18.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
6. Как реализовать передачу сообщений? (желательно - пример кода);
7. Порассуждать о вариантах реализации этих паттернов.
18

19.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
Шаблон Производитель-Потребитель — расширение паттерна Издатель-подписчик
для параллельного программирования. Канал передачи сообщений — менеджер
(может, например, выравнивать нагрузку на потребителей).
19

20.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
20

21.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
21

22.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
22

23.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
8. Какие проблемы есть в этом коде? Как
их можно исправить?
9. Где вы применяли такие шаблоны
проектирования?
23

24.

4.3 Паттерны Наблюдатель, Издатель-подписчик
и Производитель-Потребитель
Класс Bowl распределяет Еду между
Животными.
Стратегию распределения можно
делегировать отдельному классу:
1) кормить самое голодное животное;
2) распределять еду между животными
(чтобы сытость была > 0);
3) добавить воду и другие типы еды;
Тут мог бы быть логгер, тогда:
4) события (еда) могли бы поступать параллельно;
5) типы сообщений (виды еды);
6) возможны разные стратегии обработки — самое новое, самое приоритетное.
=> Стратегия обработки может быть очень сложной, а может изменяться по ходу
работы.
см. больше в «Этюды о буферизации. Вадим Винник ➠ CoreHard Autumn 2019.»
24

25.

4.4 Паттерны Состояние и Стратегия
(GoF)
State — позволяет объекту варьировать свое поведение в
зависимости от внутреннего состояния. Извне создается
впечатление что изменился класс объекта.
1) Локализует варианты поведения, делит его
реализацию на части.
2) Делает явными переходы между состояниями.
Кто определяет переходы между состояниями?
Кто и когда создает объекты-состояния?
Увеличивает количество классов.
25

26.

4.4 Паттерны Состояние и Стратегия
(GoF) Strategy (Policy) — определяет
семейство алгоритмов, инкапсулирует
каждый из них и делает их
взаимозаменяемыми. Позволяет менять
алгоритмы независимо от клиентов,
которые ими пользуются.
Context может определять интерфейс,
который позволит ConcreteStrategy
получить доступ к данным контекста.
1. Группирует семейства родственных алгоритмов;
2. Альтернатива наследованию;
3. Рефакторинг кода (избавляет от длинных цепочек if...else, switch...case;
4. Повышает гибкость — связано с DIP (пример из прошлого семестра —
TextReceiver и DecriptionStrategy).
Как определить интерфейс Контекста, чтобы всем хватило?
26

27.

4.4 Паттерны Состояние и Стратегия
Стратегии могут параметризовать
контекст как параметры шаблона.
Можно не создавать
Стратегии/Состояния каждый раз, а
хранить их в Пуле.
10. Является ли Стратегия Состоянием или Состояние Стратегией? В чем разница
между ними?
27

28.

4.4 Паттерны Состояние и Стратегия. Пример
Паттерн State — применяется для
рефакторинга, если в нескольких функциях
класса встречается разлапистая проверка
состояния объекта для выполнения тех или
иных действий.
В нашем случае персонаж может
взаимодействовать с ежом, предположим,
что если персонаж движется сидя и
контактирует с ежом — у него должно
уменьшится здоровье, а если стоя —
увеличится счет (points).
Кроме ежа могла быть еда, противники,
патроны и т.д. В классе Player, при нажатии
кнопки Ctrl состояние могло бы меняться на
SeatState, а при отпускании — на StayState.
Таким образом, при выполнении
state->process_hedgehog(this)
наш игрок каким-то образом, определенным
объектом state, проконтактирует с ежиком.
28

29.

5.1 Паттерны Прототип и Объектный пул
(Википедия)
Прототип —
порождающий
паттерн. порождает
путем копирования
существующего
объекта.
11. Квест - попробовать разобраться «Что тут?» и «Зачем может применяться этот
паттерн?» Привести примеры.
29

30.

5.1 Паттерны Прототип и Объектный пул
Объектный пул - набор инициализированных и готовых к использованию объектов.
Когда системе требуется объект, он не создаётся, а берётся из пула. Когда объект
больше не нужен, он не уничтожается, а возвращается в пул.
Клонирование объекта, требующего загрузки данных с памяти/сети (кэш).
Пул потоков часто используется вместе с Производитель-Потребитель (в реализации
канала связи).
30
Пул Стратегий.

31.

5.2 Паттерн Property
Цель паттерна Property — привязать какую-то функциональность к изменению
значения какого-либо члена класса.
Пример: класс Window с полем title.
31

32.

5.2 Паттерн Property
Цель паттерна Property — привязать какую-то функциональность к изменению
значения какого-либо члена класса.
Пример: класс Window с полем title.
32

33.

5.3 Паттерн Команда
(GoF) Команда инкапсулирует запрос на объект, позволяя клиентам:
- задавать параметры обработки запросов;
- протоколировать - ICommand может содержать не только execute, но и операции
записи операций во внешней памяти. В случае сбоя — их можно повторить;
- отменять операции — если execute перед выполнением сохранит состояние для
отката действий;
- реализовать транзакции.
33

34.

5.3 Паттерн Команда. Пример
34

35.

5.3 Паттерн Команда. Пример
В функциональном стиле
12. Команда — это делегирование?
13. Property — это делегирование?
14. Property — это Посредник?
35