Ruby. Объектно-ориентированное проектирование

Предисловие
Введение от технической группы
Кому эта книга будет полезна
Как следует читать книгу
В чем польза этого издания
Благодарности
Об авторе
Глава 1
Объектно-ориентированное проектирование
Хвала проектированию
Проблемы, решаемые с помощью проектирования
Почему изменения так нелегко даются
Определение проектирования
Инструменты проектирования
Принципы проектирования
Шаблоны проектирования
Процесс проектирования
Когда нужно приступать к проектированию
Оценка проектирования
Краткое введение в объектно-ориентированное программирование
Процедурные языки
Объектно-ориентированные языки
Выводы
Глава 2.
Проектирование классов с единственной обязанностью
Что должно принадлежать классу
Группировка методов в классы
Организация кода с целью сохранения легкости внесения изменений
Создание классов с единственной обязанностью
Почему предметом рассмотрения стала единственная обязанность
Определение наличия у класса единственной обязанности
Когда следует принимать проектировочные решения
Создание кода, легко принимающего изменения
Полагайтесь на поведение, а не на данные
Принуждение к повсеместному внедрению единственной обязанности
И наконец, реальное колесо
Выводы
Глава 3
Управление зависимостями
Основные сведения о зависимостях
Выявление зависимостей
Связи между объектами — Coupling Between Objects (CBO)
Другие зависимости
Создание кода со слабой связью
Внедренные зависимости
Изоляция зависимостей
Устранение зависимостей от порядка следования аргументов
Управление направлением зависимостей
Разворот в обратном направлении
Выбор направления
Определение конкретности и абстрактности
Выводы
Глава 4
Создание гибких интерфейсов
Основные сведения об интерфейсах
Определение интерфейсов
Открытые интерфейсы
Закрытые интерфейсы
Обязанности, зависимости и интерфейсы
Поиск открытого интерфейса
Пример приложения: компания, занимающаяся велотуризмом
Формирование намерения
Использование диаграмм последовательности
Нужно не говорить «как», а спрашивать «что»
Поиск контекста независимости
Доверие, оказываемое другим объектам
Использование сообщений для обнаружения потребности в новых объектах
Создание приложения, основанного на сообщениях
Написание кода, визитной карточкой которого становится его лучший интерфейс
Создавайте четко выраженные интерфейсы
Уважительное отношение к чужим открытым интерфейсам
Будьте осмотрительны при наличии зависимости от закрытых интерфейсов
Минимизация контекста
Закон Деметры
Определение закона
Последствия нарушений
Как обойтись без нарушений
Прислушиваясь к закону Деметры
Выводы
Глава 5
Снижение затрат за счет неявной типизации
Основные сведения о неявной типизации
Упущение из виду возможностей применения неявной типизации
Усугубление проблемы
Обнаружение возможностей применения неявной типизации
Последствия неявной типизации
Написание кода, полагающегося на использование неявной типизации
Обнаружение скрытых возможностей применения неявной типизации
Внедрение доверия в использование неявной типизации
Документирование неявных типов
Распределение кода между «утками»
Мудрый подход к выбору «уток»
Преодоление страха применения неявной типизации
Подрыв неявной типизации с помощью статической типизации
Сравнение статической и динамической типизации
Вступление на путь динамической типизации
Выводы
Глава 6
Получение поведения через наследование
Основные сведения о классическом наследовании
Как определить, где следует воспользоваться наследованием
Начнем с конкретного класса
Встраивание нескольких типов
Поиск встраиваемых типов
Выбор наследования
Прорисовка наследственных связей
Неверное применение наследования
Поиск абстракции
Создание абстрактного родительского класса
Перемещение вверх абстрактного поведения
Отделение абстрактного от конкретного
Использование схемы шаблонного метода
Реализация каждого шаблонного метода
Управление связанностью родительских классов и подклассов
Общие сведения о связанности
Устранение связанности подклассов с использованием хук-сообщений
Выводы
Глава 7
Разделение ролевого поведения с помощью модулей
Основные сведения о ролях
Поиск ролей
Организация обязанностей
Устранение ненужных зависимостей
Выявление неявного типа, подходящего для планирования
Нужно позволить объектам говорить самим за себя
Написание конкретного кода
Извлечение абстракции
Поиск методов
Грубое упрощение
Уточненное объяснение
Почти полное объяснение
Наследование ролевого поведения
Написание наследуемого кода
Выявление антишаблонов
Принуждение к абстракции
Соблюдение контракта
Использование схемы шаблонного метода
Превентивное отделение классов
Создание неглубоких иерархий
Выводы
Глава 8
Объединение объектов путем составления композиции
Составление композиции Bicycle (велосипед) из Parts (частей)
Обновление класса Bicycle
Создание иерархии Parts
Составление композиции для объекта Parts
Создание Part
Придание объекту Parts большей схожести с массивом
Изготовление Parts-объектов
Создание модуля PartsFactory
Применение PartsFactory
Bicycle в виде композиции
Выбор между наследованием и композицией
Приемлемость наследования
Приемлемость композиции
Выбор характера отношений
Выводы
Глава 9
Проектирование экономичных тестов
Целенаправленное тестирование
Осознание намерений
Выявление предмета тестирования
Умение определять нужный момент для тестирования
Умение проводить тестирование
Тестирование входящих сообщений
Удаление неиспользуемых интерфейсов
Проверка открытого интерфейса
Изоляция тестируемого объекта
Внедрение зависимостей с использованием классов
Внедрение зависимостей в качестве ролей
Тестирование закрытых методов
Игнорирование закрытых методов при тестировании
Удаление закрытых методов из тестируемого класса
Выбор в пользу тестирования закрытого метода
Тестирование исходящих сообщений
Игнорирование сообщений-запросов
Проверка сообщений-команд
Тестирование неявных типов
Тестирование ролей
Ролевые тесты для проверки дублеров
Тестирование унаследованного кода
Определение унаследованного интерфейса
Определение обязанностей подкласса
Тестирование уникального поведения
Выводы
Заключение

Читателям с разными уровнями подготовки книга окажется по-разному полезна.
Тем, кто уже знаком с объектно-ориентированным проектированием, будет о чем поразмышлять; возможно, они по-новому посмотрят на уже привычные вещи и, вполне вероятно, с чем-то будут не согласны. Поскольку в объектно-ориентированном проектировании нет истины в последней инстанции, оспаривание принципов (и спор с автором данной книги) только улучшит общее понимание предмета.
В конце концов, именно вы должны оценивать собственные конструкции кода, проводить эксперименты и делать правильный выбор.
Хотя издание должно представлять интерес для читателей с различными уровнями подготовки, оно выпускалось с прицелом на новичков.
Если вы новичок, то эта часть введения — именно для вас.
Усвойте простую истину: объектно-ориентированное проектирование не магия.