Объектно-ориентированный анализ и программирование. План лекций

Bertrand Meyer. Object-Oriented Software Construction (2nd edition), 1997.

Booch et al. Object-Oriented Analysis and Design with Applications (3rd Edition), 2007.

Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software, 1994.

Симула, абстракция данных.

Определение Кэя (2003): «Для меня ООП означает только обмен сообщениями, сохранение, защита и скрытие состояния-процесса, и экстремально позднее связывание всего. Так можно сделать в Смолтоке и в Лиспе. Возможно, есть и другие системы, которые позволяют это, но я о них не знаю.»

Взаимодействующие вычислительные узлы, отправка сообщений, управление состоянием.

Классы, объекты. Идентификация, состояние, поведение. Инкапсуляция, полиморфизм, наследование.

Парадигмы ЯП. Императивное → структурное → ООП.

Lisp, сборка мусора (1959). 1960-е. Структурное и процедурное программирование (ALGOL).

ООП. Кри́стен Ню́горд и Оле-Йохан Даль. Simula (1967)

PARC. Alan Kay. Smalltalk (1969, 1972, 1980), влияние Лиспа. Передача сообщений, «утиная» типизация.

Динамическая типизация: Smalltalk → Self, Python, Ruby.

Objective-C (1983) — Си дополненный передачей сообщений в стиле Смолтока.

Статическая типизация: Simula → Ada, C++ (1983), Eiffel (1986), Java (1991).

ООП на основе прототипов: Self (1987) → JavaScript (1995).

ООП с множественной диспетчеризацией (CLOS).

Пример со стэком (Мейер).

• ADT. Типы. Универсализация (обобщение).
• Функции. Аппликативное против императивного. Запросы, команды, конструкторы.
• Аксиомы.
• Частичные функции, предусловия.

TYPES
  • STACK [G]
FUNCTIONS
  • put: STACK [G] × G → STACK [G]
  • remove: STACK [G] /→ STACK [G]
  • item: STACK [G] /→ G
  • empty: STACK [G] → BOOLEAN
  • new: STACK [G]
AXIOMS
  For any x: G, s: STACK [G]
  A1 • item (put (s, x)) = x
  A2 • remove (put (s, x)) = s
  A3 • empty (new)
  A4 • not empty (put (s, x))
PRECONDITIONS
  • remove (s: STACK [G]) require not empty (s)
  • item (s: STACK [G]) require not empty (s)

Пример выражения:

item (remove (put (remove (put (put (
     remove (put (put (put (new, x1), x2), x3)),
     item (remove (put (put (new, x4), x5)))), x6)), x7)))

Класс — это абстрактный тип данных, снабженный некоторой (возможно частичной) реализацией.

Отложенные (абстрактные) и эффективные классы.

• Имя — обычно существительное (возможно, полученное в результате номинализации).
• экземпляры — объекты,
• поля — состояние,
• методы — поведение,
• инварианты.

Класс определяет тип объектов. Тип: возможные значения, операции, представление в памяти. Абстрактные типы. Интерфейс и реализация. Инкапсуляция. Позднее связывание и полиморфизм: ситуативный (ad-hoc), параметрический (обобщенное программирование), полиморфизм подтипов.

Методы. Модификаторы доступа. Команды и запросы. Доступ к атрибутам, UAP.

Отношения: композиционные и иерархические (наследование). Метаклассы (класс является объектом).

Отношения классов в UML.

• наследуемые элементы языка
• наследование и подтипы
  • принцип подстановки Барбары Лисков
  • номинальная и структурная системы типов
• переопределение и повторное использование
• дифференциальное наследование
• статичность и единственность
• composition over inheritance
• Проблема круг-эллипс. Решения путем изменения модели:
  • успех/неудача или возврат нового значения;
  • ослабить требования к Эллипсу;
  • смена типа;
  • предусловие Ellipse.stretchable;
  • абстрактный класс RoundObject;
  • убрать наследование, Circle.toEllipse();
  • объединить классы;
  • обратное наследование;
  • неизменяемость;
  • MutableEllipse.
• Множественное наследование
  • проблема ромба
  • примеси и типажи (Traits: Composable Units of Behaviour)
  • наследование интерфейсов
  • методы по умолчанию в Java 8

Тип. Идентичность и состояние. Изменяемость. Объекты-значения (value objects) и объекты-ссылки (reference objects).

Логическое и физическое состояние объекта

Идентичность объекта.

Эквивалентность и хэш код.

Объектный граф (граф ссылок).

• позднее связывание
  • виртуальные методы
• ненаследуемые классы и непереопределяемые методы
• JIT и оптимизация
  • На примере HotSpot
• примитивные типы
• управление памятью
  • сборка мусора
    • подсчет ссылок
    • проблема циклических ссылок
  • слабые ссылки

Нет готовых рецептов. Жизненный цикл разработки. Макропроцесс.

Стили макропроцесса. Итеративный и поступательный. Водопадный.

Требования → Анализ и проектирование → Реализация → Тестирование → Развертывание → (следующая итерация)

Не обязательно с целю создания ПО.

Goals of performing analysis (Meyer)

1. To understand the problem or problems that the eventual software system, if any, should solve.
2. To prompt relevant questions about the problem and the system.
3. To provide a basis for answering questions about specific properties of the problem and system.
4. To decide what the system should do.
5. To decide what the system should not do.
6. To ascertain that the system will satisfy the needs of its users, and define acceptance criteria (especially when the system is developed for an outside customer under a contractual relationship).
7. To provide a basis for the development of the system.

Модель поведения. Что делает система, а не как. (Буч)

• «В центре внимания анализа находится поведение, а не форма.» (Буч)
• На этапе анализа достаточно описать все основные аспекты поведения.

Или с чем она это делает?

• «Ask not first what the system does: ask what it does it to!» (Мейер)

Использование ОО для моделирования (Мейер, с. 907).

Поиск классов

• "The grand mistake" (Мейер) — выделение классов-процедур вместо классов-абстракций данных.
• Кортежи для простой группировки значений.
• Классы, представляющие абстрактные действия (команды).

Пример с программой тебепередач (Мейер, с. 908).

Представления анализа:

• формальный текст (код),
• диаграмма,
• текст.

Идентификация элементов, определение взаимодействия, определение отношений, определение семантики.

Хорошая архитектура:

• многоуровневая система абстракций,
• четкая граница между интерфейсом и реализацией на каждом уровне абстракции,
• простота: общее поведение достигается общими абстракциями и механизмами.

Основные принципы:

• программирование на основе интерфейса, а не реализации,
• повторное использование функциональности,
  • внутреннее, инструментарий, каркас,
• композиция объектов предпочтительнее наследования,
  • делегирование, как альтернатива наследованию,
• предполагать изменения.

Факторы, ограничивающие гибкость архитектуры и приводящие к перепроектированию:

• явное указание класса при создании объекта,
• зависимость от аппаратной или программной платформы,
• зависимость от представлений и реализаций объектов,
• зависимость от конкретных алгоритмов,
• сильная зависимость между объектами (tight coupling),
• использование наследования вместо композиции,
• невозможность изменить внешние классы.

Инверсия управления и внедрение зависимости.

Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software, 1994.

GoF: Эрих Гамма (Erich Gamma), Ричард Хелм (Richard Helm), Ральф Джонсон (Ralph Johnson), Джон Влиссидс (John Vlissides)

Шаблоны проектирования — описания взаимодействующих объектов и классов, нацеленные на решение общих проблем проектирования в определенном контексте.

Польза шаблонов:

• обобщение опыта,
• унификация словаря решений проектирования.
• в GoF:
  • выявление неочевидных абстракций и объектов,
  • определение детальности разбиения на объекты,
  • определение интерфейсов.

Критика:

• шаблоны — недостающие возможности ЯП,
  • зависимость шаблонов от языка,
• повтор решений вместо реализации один раз,
• чрезмерное усложнение (overengineering).

Элементы шаблона: имя, задача, решение, последствия.

Описание шаблона:

• имя и классификация,
• назначение,
• альтернативные названия,
• мотивация,
• применимость,
• структура,
• участники,
• взаимодействие,
• последствия,
• особенности реализации,
• пример кода,
• примеры использования,
• связанные шаблоны.

Категории:

• порождающие, структурные, поведенческие;
• дополнительно (нет в GoF): шаблоны параллельного программирования.