Лекция 4 - ООП и паттерны

СОВРЕМЕННЫЕ
ТЕХНОЛОГИИ
РАЗРАБОТКИ ПО
Лекция 4:
Сложность программных систем.
Декомпозиция задач.
Объектно-ориентированный анализ.
Паттерны (шаблоны) проектирования.
Сложность
программных систем
Причины
Признаки сложных систем
Борьба со сложностью
Причины сложности
• По Фредерику Бруксу:
• сложность предметной области
- сложный мир
- пользователи не знают/не умеют объяснить, что надо
- требования меняются
• трудность управления процессом разработки
- большая система -> много задач -> большая команда -> сложно
координировать
• необходимость обеспечить гибкость программы
- нет стандартов, сложно выбрать нужный уровень
• сложность описания поведения больших систем
- «случайно залетевший дятел приводит к краху цивилизации»
• Из SICP:
• Computer Science – не столько про науку и компьютеры,
сколько про набор методов преодоления сложности
3
Последствия для индустрии
• Непонимание этой сложности
• за «небольшим изменением» может стоять
необходимость фундаментальной
переделки всей системы
• Неумение создавать сложные системы
• Срыв сроков, бюджетов, непопадание в
требования
• Неэффективное использование кадров
- избыточные трудозатраты на
создание/поддержание «плохих» систем
4
Признаки сложной системы
1. Иерархия и взаимозависимые подсистемы (тоже
сложные)
2. Можно выделить элементарные компоненты
•
разными способами (зависит от взгляда)
абстрагировавшись от деталей
3. Внутрикомпонентная связь обычно сильнее, чем
связь между компонентами
4. Состоит из немногих типов подсистем, по-разному
скомбинированных и организованных
5. Любая сложная система – результат развития более
простой системы
•
"с нуля" сложная система не заработает - всегда есть что-то
проще
5
Подходы к организации
• Архитектура системы:
• структура классов
- общие свойства объектов
• + структура объектов
- конфигурация системы во время выполнения
• Проблема организации:
• сложность систем превышает способности
человека охватить их целиком
• выход – «разделяй и властвуй»
- декомпозиция
- работа с каждым уровнем абстракции отдельно
6
Декомпозиция
• Алгоритмическая
• шаги разбиваются на подшаги
иерархически, сверху-вниз
• Объектно-ориентированная
• критерий – принадлежность частей к
абстракциям предметной области
• Оба вида – взаимодополняющие
• следует предпочитать более подходящий к
задаче
7
Абстракция. Иерархия
• Методы проектирования программных
систем:
• структурное проектирование сверху вниз
• потоки данных
- система преобразует входные потоки в выходные
• объектно-ориентированное проектирование
- система – совокупность взаимодействующих объектов
• Иерархия
• объектная схема – механизмы взаимодействия
объектов
• структура классов – общность структур и
поведения
8
Абстракция данных
• Отделяет способ использования от деталей
внутреннего представления
• Пример (SICP): рациональные числа. Уровни
абстракции:
• Программы, использующие рациональные числа:
- рациональные числа в предметной области
• Высокоуровневые операции
- plus, minus, ..., equal
- используют более простые абстракции (конструирование,
селекторы)
• Рациональные числа как числители со знаменателями
- конструкторы, селекторы numerator, denominator
• Рациональные числа как структура данных
- std::pair<int, int> или просто int n, d
• Реализация более простых типов (pair, int)
- как это понимает компилятор или среда исполнения
9
Абстракция данных
• Можно изменять представления данных
• интерфейс остаётся неизменным
• Или даже использовать одновременно
несколько представлений
• можно выбирать более удобное в данный
момент
10
Абстракция алгоритмов
• Пример: нужно подсчитать сумму квадратов всех нечётных
чисел в дереве
• Решение «в лоб», от описания:
def sumOddSquares(tree):
if tree is null:
return 0
elif tree is instance of Leaf:
return square(tree.value())
else:
return sumOddSquares(tree.left()) +
sumOddSquares(tree.right())
• Подход 2: конвейер обработки потока данных
do
all <- tree.values(),
oddItems <- filter(all, isOdd),
squaredItems <- map(oddItems, square),
return accumulate(plus, 0, squared).
11
ООП: данные + поведение
Пример: классический ГПСЧ
• В языке C: srand(int seed) + int rand()
• ООП: внутреннее состояние объекта – «зерно» для
генерации следующего числа
• конструктор Random(int seed)
+ модификатор int Random::rand()
Внутреннее состояние изменяет картину:
• Присваивание нарушает "чистоту" (побочные
эффекты)
• ФП vs. Императивное программирование
• Два объекта с одинаковым состоянием – это не одно
и то же (разные сущности)
• нарушается ссылочная прозрачность
12
Объектноориентированный подход
Объектная модель
Отношения классов и объектов
Процесс проектирования
Основы ООП
• В качестве базовых элементов –
объекты
• а не алгоритмы
• Каждый объект – экземпляр
определенного класса
• Классы организованы иерархически
14
Объектная модель
• Основные элементы:
•
•
•
•
Абстрагирование
Инкапсуляция
Модульность
Иерархия
• Вспомогательные элементы:
• Типизация
• Параллелизм
• Сохраняемость
15
Объектная модель
Абстрагирование
•
Основные виды
•
Абстракция сущности
-
•
Абстракция поведения
-
•
обобщённое множество операций
Абстракция виртуальной машины
-
•
модель сущности предметной области
набор операций более низкого уровня
Произвольная абстракция
16
Объектная модель
Абстрагирование
• Контрактная модель
• «сервер» исполняет обязательства перед
«клиентом»
• Протокол – полный набор операций и их
порядок
• способы взаимодействия с объектом
• внешнее поведение абстракции
• Инвариант – логическое условие
• изменение инварианта нарушает контракт
17
Объектная модель
Инкапсуляция
• Определяет четкие границы между
абстракциями
• На практике, означает разделение
класса на
• интерфейс
• и внутреннюю реализацию
18
Объектная модель
Модульность
• Модульность системы
• внутренне связные
• но слабо связанные между собой модули
• Понятие модульности связано с
инкапсуляцией
• интерфейс модуля часто отделяется от его
реализации
• Пример из C++:
• модуль (компиляции) - .cc/.cpp-файл
• интерфейс – в заголовочном файле .h/.hpp
19
Объектная модель
Иерархия
• Иерархия – это упорядочение
абстракций, расположение их по
уровням.
• Структура классов: наследование
- "обобщение/специализация"
• Структура объектов – агрегация
- «целое/часть»
- проблема владения (управление временем
жизни частей)
• собственно агрегация
• композиция
20
Объектная модель
Типизация
• Типизация – способ защититься от
использования объектов одного класса
вместо другого
• или управлять таким использованием
• Сильная или слабая типизация
• сильная – жёсткий контроль за приведением типов
• слабая – отсутствие контроля
• промежуточные варианты: возможно смешивать
базовые типы (C++)
• Статическое и динамическое связывание
• во время компиляции или во время выполнения
(полиморфное поведение)
21
Объектная модель
Параллелизм
• Параллелизм позволяет различным объектам
действовать одновременно
• Параллелизм – свойство, отличающее
активные (управляющие) объекты от
пассивных
• Многозадачность:
• "истинная" –параллельное и независимое
исполнение
• "легковесная" – кооперативная многозадачность
• "вытесняющая" – прерывания
• Возникает задача синхронизации
22
Объектная модель
Сохраняемость
• Сохраняемость – способность объекта существовать
• во времени
- переживая породивший его процесс,
• и (или) в пространстве
- перемещаясь из своего первоначального адресного
пространства
• Время жизни объекта:
•
•
•
•
Промежуточные результаты вычисления выражений
Локальные переменные в вызове процедур
Глобальные переменные и динамически создаваемые
Данные, сохраняющиеся между сеансами выполнения
программы
• Данные, сохраняемые при переходе на новую версию
программы
• Данные, которые переживают саму программу
23
Объекты
• Не всё является объектами
• могут быть атрибуты (без поведения)
• Свойства объекта:
• Состояние
- свойства и их текущие значения
• Поведение
-
Конструктор
Деструктор
Модификатор
Селектор
Итератор
• Идентичность
- отличительный признак объекта
- время жизни
24
Отношения между объектами
• Связи (ассоциации)
• Actor – действующее лицо
• Сервер – обслуживает запросы
• Агент – промежуточное звено
• Агрегация
• отношения "целое-часть"
• композиция – когда время жизни композита
совпадает с временем жизни частей
25
Классы
• Класс - это некое множество объектов,
имеющих общую структуру и общее
поведение.
• Составные части:
• интерфейс
- открытая часть
- защищённая
• доступ себе, подклассам и друзьям
- закрытая
• доступ себе и друзьям
• реализация
26
Отношения между классами
• Ассоциация
• смысловая связь (ссылки на объекты другого класса)
• участники, роли, мощность отношений
• Наследование
• специализация
• при поддержке полиморфного поведения
• Aгрегация
• воплощение агрегации объектов
• включение по ссылке или физическое
• Использование
• клиент-серверные отношения
• в т.ч., "дружеские" отношения - доступ с нарушением инкапсуляции
• передача "серверов" в методы "клиента"
• Инстанцирование
• шаблонные классы и их специализации
• класс как параметр шаблона
• Метакласс
• класс как объект
27
Процесс проектирования
Макропроцесс
• Концептуализация
• Выявление сущности требований к программному
продукту
• Анализ
• Разработка модели требуемого поведения системы
• Проектирование
• Создание архитектуры для реализации
• Эволюция
• Итеративное выполнение реализации
• Сопровождение
• Управление эволюцией продукта в ходе
эксплуатации
28
Процесс проектирования
Итерация (микропроцесс)
• Выявление классов и объектов на
данном уровне абстракции
• Выяснение семантики этих классов и
объектов
• Выявление связей между этими
классами и объектами
• Спецификация интерфейса и
реализация этих классов и объектов
29
Паттерны
проектирования
Паттерны проектирования
• Идеи архитектора К. Александера
• «язык шаблонов» в архитектуре зданий
• Эрих Гамма и его “Gang of Four”
• Design Patterns – Elements of Reusable ObjectOriented Software
• Описали общие паттерны, разделив по категориям
• Помимо этих общих, выделяют также и другие,
частные паттерны
- Model-View-Controller как самый известный
- Параллельное программирование:
• пулы потоков, мониторы, замки, планировщики и т.п.
- Active Record – шаблон работы с БД
31
Порождающие паттерны
•
•
•
•
•
Abstract Factory (абстрактная
фабрика)
Builder (строитель)
Factory Method (фабричный метод)
Prototype (прототип)
Singleton (одиночка)
32
Структурные паттерны
•
•
•
•
•
•
•
Adapter (адаптер)
Bridge (мост)
Composite (компоновщик)
Decorator (декоратор)
Facade (фасад)
Fluweight (приспособленец)
Proxy (заместитель)
33
Поведенческие паттерны
•
•
•
•
•
•
•
•
•
•
•
Chain of Responsibility (цепочка обязанностей)
Command (команда)
Interpreter (интерпретатор)
Iterator (итератор)
Mediator (посредник)
Memento (хранитель)
Observer (наблюдатель)
State (состояние)
Strategy (стратегия)
Template Method (шаблонный метод)
Visitor (посетитель)
34
Примеры:
Фабричный метод
• Порождающий шаблон
• Делегирует создание объектов наследникам
• определяет интерфейс для создания объекта
- возможно, какое-то сложное конструирование
• решение о конкретном инстанцируемом типе принимают
наследники
(с) http://ru.wikipedia.org/wiki/Файл:FactoryMethodPattern.png (CC BY-SA 3.0)
35
Примеры:
Адаптер
• Структурный шаблон
• Определяет специальный интерфейс для работы с
объектом
• если исходный класс имеет неподходящий интерфейс
• и нельзя его модифицировать
(с) http://ru.wikipedia.org/wiki/Файл:AdapterPattern.svg (CC BY-SA 3.0)
36
Примеры:
Декоратор
• Структурный шаблон
• Динамическое подключение дополнительного
поведения к объекту
• расширение функциональности без наследования
• реализует тот же интерфейс, что и декорируемый объект
(с) http://ru.wikipedia.org/wiki/Файл:Decorator_Template.png (CC BY-SA 3.0)
37
Примеры:
Посетитель
• Поведенческий шаблон
• Выполнение аналогичных операций над набором
классов
• возможность определять операции, не меняя самих классов
• причём, для каждого из классов – своя операция
(с) http://ru.wikipedia.org/wiki/Файл:VisitorDiagram.svg (CC BY-SA 3.0)
38
Примеры:
Наблюдатель
• Поведенческий шаблон
• Механизм оповещения об изменении состояния
классов
• уведомляются все заинтересованные наблюдатели
39
(с) http://ru.wikipedia.org/wiki/Файл:Observer.png (CC BY-SA 3.0)
Примеры:
Стратегия
• Поведенческий шаблон
• Позволяет абстрагировать и выбирать
алгоритмы в зависимости от контекста
• обобщённый интерфейс для правила/алгоритма
40
(с) http://ru.wikipedia.org/wiki/Файл:Strategy_pattern.png (CC BY-SA 3.0)
Ссылки
• Х. Абельсон, Дж. Сассман, «Структура и
интерпретация компьютерных программ»
• Г. Буч, «Объектно-ориентированный анализ и
проектирование»
• Ф. Брукс, «Мифический человеко-месяц»
• 35 принципов ОО-дизайна:
• http://www.asis.ru/posts/23
• Шаблоны проектирования:
• http://ru.wikipedia.org/wiki/Шаблон_проектирования
41