Разработка программных модулей. Урок 40

1.

Разработка
программных модулей

2.

Шаблоны проектирования
Существует довольно много MV*-паттернов: Model-View-Controller, ModelView-Presenter, Presentation Model, Passive View, Supervising Controller, ModelView-ViewModel и многие другие:
2

3.

Шаблоны проектирования
Построение UI привычным способом нарушает принцип единственной
ответственности (single responsibility principle).
3

4.

Шаблоны проектирования
Построение UI привычным способом нарушает принцип единственной
ответственности (single responsibility principle).
Этот принцип звучит так - у класса должна быть только одна причина для
изменения.
Следование принципу заключается обычно в декомпозиции сложных
классов, которые делают сразу много вещей, на простые, ответственность
которых очень специализирована. Но также и объединении в отдельный
класс однотипной функциональности, которая может оказаться
распределённой по многим классам, может рассматриваться как следование
этому принципу.
4

5.

Шаблоны проектирования
Проектирование классов с направленностью на обеспечение единственной
обязанности упрощает дальнейшие модификации и сопровождение, так как
проще разобраться в одном блоке функциональности, нежели распутывать
сложные взаимосвязи между различными функциональными блоками.
Также при модификации логики в одном месте приложения снижаются риски
возникновения проблем в других «неожиданных» его местах.
Следование SRP весьма полезная практика с точки зрения повторного
использования кода. Сложные объекты с комплексными зависимостями
обычно очень сложно использовать повторно, особенно если нужна только
часть реализованного в них функционала. А небольшие классы с чётко
очерченным функционалом, напротив, проще использовать повторно, так
как они не избыточные и редко тянут за собой существенный объём
5
зависимостей.

6.

Шаблоны проектирования
MVC (Model-View-Controller) — фундаментальный шаблон проектирования,
целью которого является отделение логики интерфейса пользователя от
логики программирования. MVC имеет множество вариантов реализации.
Существуют модификации шаблона, самые известные из них MVP и MVVM.
• Model (модель) — содержит модель данных и бизнес-логику. Иными
словами, модель делает все для чего создавалась программа.
• View (представление) — интерфейс взаимодействия с пользователем.
Представление отображает часть данных модели пользователю. В
некоторых случаях, представление может иметь свою бизнес-логику.
• Controller (контроллер) — связывает модель и представление между
собой. Контроллер обрабатывает события пользователя, управляет
состоянием модели.
6

7.

Шаблоны проектирования
7

8.

Шаблоны проектирования
Точкой входа в программу является контроллер. Контроллер имеет ссылки на
модель и на представление. Контроллер подписывается на события
представления, а представление подписывается на события модели.
Когда пользователь совершает какие-нибудь действия, управление
переходит к контроллеру и контроллер воздействует на модель.
При процедуры изменения модели контроллер получает соответствующее
событие и воздействует на представление для обновления данных.
В реализации MVC независимой частью является модель, она ничего не
знает о представлении и контроллере.
Если программа содержит несколько представлений, то для каждого
представления требуется создать свой контроллер. При этом, допускается
использовать одну и туже модель в разных контроллерах и представлениях.
8

9.

Шаблоны проектирования
Model-View-Presenter. Компоненты Model и View в шаблоне MVP
аналогичны соответствующим компонентам модели MVC. Основной целью
данного шаблона является отделения модели от представления. В шаблоне
MVP информация об изменении модели поступает на презентер (Presenter),
который воздействует на представление для обновления состояния.
Отсутствие связи между моделью и представлением позволяет сделать
абстракцию представления. Реализовать данный паттерн можно путем
выделения интерфейса представления. Интерфейс будет содержать набор
методов и свойств, необходимых презентеру, сам презентер будет
подписываться на события представления и вызывать методы для его
обновления. Абстрагирование представления полезно в задачах, где
требуется отобразить один и тот же набор данных в разных представлениях.
9
Например, выводить отчет в разных форматах: ALV, PDF, EXCEL.

10.

Шаблоны проектирования
10

11.

Шаблоны проектирования
Основное отличие MVP и MVC в том, что в MVC обновлённая модель сама
говорит виду, что нужно показать другие данные. Если же этого не
происходит и приложению нужен посредник в виде представителя, то
паттерн стоит называть MVP. Всё это можно сравнить с работой издательства:
Автор готовит текст (модель).
Текст получает издатель (представитель).
Если с текстом всё в порядке, издатель передаёт его в отдел вёрстки (вид).
Верстальщики готовят книгу, которую начинают продавать читателям
(пользователи).
• Если пользователи как-то реагируют на книгу, например, пишут письма в
издательство, то работа может начаться заново. Допустим, кто-то может
заметить в книге неточность, тогда издатель передаст информацию
11
автору, автор её обновит и так далее.

12.

Шаблоны проектирования
Model-View-ViewModel (MVVM). Шаблон MVVM отлично показан WPF на
языке C#. Идея данного паттерна заключается в отделении слоев друг от
друга. Шаблон MVVM состоит из трех основных компонентов: модели,
представления и модели представления. Модель представляет данные
приложения и связанную с ними бизнес-логику, которая отвечает за
извлечение и хранение данных, соблюдение правил проверки и реализацию
любых соответствующих алгоритмов манипулирования данными.
Представление представляет собой пользовательский интерфейс
приложения, отображающий данные, хранящиеся в модели, и
обрабатывающий ввод пользователя. ViewModel выступает в качестве
посредника между моделью и представлением, обеспечивая привязку
данных и механизмы связи.
12

13.

Шаблоны проектирования
Главное отличие от MVC
заключается в том, что в MVVM
View более пассивно, оно не
содержит бизнес-логики и
большая часть взаимодействия с
данными и действиями
пользователя обрабатывается в
ViewModel, что делает код более
легко тестируемым и позволяет
лучше разделять
ответственности между
компонентами.
13

14.

Шаблоны проектирования
14

15.

Шаблоны проектирования
Паттернами проектирования (Design Patterns) называют решения часто
встречающихся проблем в области разработки программного обеспечения. В
данном случае предполагается, что есть некоторый набор общих
формализованных проблем, которые довольно часто встречаются, и
паттерны предоставляют ряд принципов для решения этих проблем.
Концепцию паттернов впервые описал Кристофер Александер в книге «Язык
шаблонов. Города. Здания. Строительство».
Идея показалась привлекательной авторам Эриху Гамму, Ричарду Хелму,
Ральфу Джонсону и Джону Влиссидесу, их принято называть «бандой
четырёх» (Gang of Four). В 1995 году они написали книгу «Design Patterns:
Elements of Reusable Object-Oriented Software», в которой применили
концепцию типовых паттернов в программировании. В книгу вошли 23
паттерна, решающие различные проблемы объектно-ориентированного
15
дизайна.

16.

Шаблоны проектирования
В зависимости от того, какие задачи решают паттерны, они делятся на три
вида — порождающие, структурные и поведенческие.
Порождающие предназначены для создания экземпляра объекта или группы
связанных объектов. К ним относятся:
• Abstract Factory — Абстрактная фабрика
• Builder — Строитель
• Factory Method — Фабричный метод
• Prototype — Прототип
• Singleton — Одиночка
16

17.

Шаблоны проектирования
Структурные в основном связаны с композицией объектов, с тем, как
сущности могут использовать друг друга. К ним относятся:
Adapter — Адаптер
Bridge — Мост
Composite — Компоновщик
Decorator — Декоратор
Facade — Фасад
Flyweight — Приспособленец
Proxy — Заместитель
17

18.

Шаблоны проектирования
Поведенческие связаны с распределением обязанностей между объектами.
Их отличие от структурных шаблонов заключается в том, что они описывают
не только структуру, но и способы общения между ними. К ним относятся:
• Chain of responsibility — Цепочка обязанностей
• Command — Команда
• Interpreter — Интерпретатор
• Iterator — Итератор
• Mediator — Посредник
• Memento — Хранитель
• Observer — Наблюдатель
• State — Состояние
• Strategy — Стратегия
• Template method — Шаблонный метод
18
• Visitor — Посетитель

19.

Шаблоны проектирования
Абстрактная фабрика — это порождающий паттерн проектирования, который
позволяет создавать семейства связанных объектов, не привязываясь к
конкретным классам создаваемых объектов.
Представьте, что вы пишете симулятор мебельного магазина. Ваш код
содержит:
• Семейство зависимых продуктов. Скажем, Кресло + Диван + Столик.
• Несколько вариаций этого семейства. Например, продукты Кресло, Диван
и Столик представлены в трёх разных стилях: Арт-деко, Викторианском и
Модерне.
Вам нужен такой способ создавать объекты продуктов, чтобы они сочетались
с другими продуктами того же семейства. Это важно, так как клиенты
расстраиваются, если получают несочетающуюся мебель.
19

20.

Шаблоны проектирования
Кроме того, вы не хотите вносить изменения в существующий код при
добавлении новых продуктов или семейcтв в программу. Поставщики часто
обновляют свои каталоги, и вы бы не хотели менять уже написанный код
каждый раз при получении новых моделей мебели.
Абстрактная фабрика задаёт интерфейс создания всех доступных типов
продуктов, а каждая конкретная реализация фабрики порождает продукты
одной из вариаций. Клиентский код вызывает методы фабрики для
получения продуктов, вместо самостоятельного создания с помощью
оператора new. При этом фабрика сама следит за тем, чтобы создать продукт
нужной вариации.
20

21.

Шаблоны проектирования
21

22.

Шаблоны проектирования
Далее вы создаёте абстрактную фабрику — общий интерфейс, который
содержит методы создания всех продуктов семейства (например,
создатьКресло, создатьДиван и создатьСтолик). Эти операции должны
возвращать абстрактные типы продуктов, представленные интерфейсами,
которые мы выделили ранее — Кресла, Диваны и Столики.
22

23.

Шаблоны проектирования
Для каждой вариации семейства продуктов мы должны создать свою
собственную фабрику, реализовав абстрактный интерфейс. Фабрики создают
продукты одной вариации. Например, ФабрикаМодерн будет возвращать
только КреслаМодерн,ДиваныМодерн и СтоликиМодерн.
Клиентский код должен работать как с фабриками, так и с продуктами только
через их общие интерфейсы. Это позволит подавать в ваши классы любой
тип фабрики и производить любые продукты, ничего не ломая.
23

24.

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

25.

Порождающие паттерны
Синглтон выполняет две задачи:
1. Гарантирует наличие единственного экземпляра класса. Чаще всего это
полезно для доступа к какому-то общему ресурсу, например, базе данных.
Представьте, что вы создали объект, а через некоторое время пробуете
создать ещё один. В этом случае хотелось бы получить старый объект, вместо
создания нового.
Такое поведение невозможно реализовать с помощью обычного
конструктора, так как конструктор класса всегда возвращает новый объект.
25

26.

Порождающие паттерны
2. Предоставляет глобальную точку доступа. Это не просто глобальная
переменная, через которую можно достучаться к определённому объекту.
Глобальные переменные не защищены от записи, поэтому любой код может
подменять их значения без вашего ведома.
Но есть и другой нюанс. Неплохо бы хранить в одном месте и код, который
решает проблему №1, а также иметь к нему простой и доступный интерфейс.
26

27.

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

28.

Порождающие паттерны
Плюсы синглтона:
• Гарантирует наличие единственного экземпляра класса.
• Предоставляет к нему глобальную точку доступа.
• Реализует отложенную инициализацию объекта-одиночки.
Минусы синглтона:
Нарушает принцип единственной ответственности класса.
Маскирует плохой дизайн.
Проблемы мультипоточности.
Требует постоянного создания Mock-объектов (используется при
разработке через тестирование) при юнит-тестировании.
28

29.

Домашнее задание
Ознакомьтесь с примером реализации Абстрактной фабрики в приложенном файле.

30.

Спасибо за внимание!