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

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, Objective-C, Python, Ruby.

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.

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

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

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

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

• позднее связывание
• виртуальные методы
• ненаследуемые классы и непереопределяемые методы

Объектно-ориентированный подход. OOAD, анализ, проектирование.

• OOA: требования → модель.
• ООD: модель → архитектура.

• Meyer, B. Object-Oriented Software Construction. Prentice Hall, 1997.
• Booch, G., Maksimchuk, R. A., Engel, M. W., Young, B. J., Conallen, J. and Houston, K. A. Object-Oriented Analysis and Design with Applications (3rd Edition). Addison-Wesley Professional, Hardcover, 2007.

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

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

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

Гибкий метод (agile, ускоренный) и следование плану (планомерный).

Анализ и проектирование (микропроцесс).

(требования) → Анализ → (начальное решение) → Проектирование → спецификация, допускающая эффективную реализацию.

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

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

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

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

Сравнение ОО подхода и разработки сверху-вниз (Мейер).

• Декомпозиция
• Комбинируемость
• Понятность
• Непрерывность

Непрерывность архитектуры. Повторное использование.

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

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

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

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

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

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

• явное указание класса при создании объекта,
• зависимость от аппаратной или программной платформы,
• зависимость от представлений и реализаций объектов,
• зависимость от конкретных алгоритмов,
• сильная зависимость между объектами (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): шаблоны параллельного программирования.