Простое объектно-ориентированное проектирование. Чистый и гибкий код

Предисловие
Благодарности
О книге
Кому стоит прочитать эту книгу
Структура издания
О коде
Другие онлайн-ресурсы
Об авторе
Иллюстрация на обложке
От издательства
Глава 1. Управление сложностью
1.1. Объектно-ориентированное
проектирование
и испытание временем
1.2. Проектирование простых объектно-
ориентированных
систем
1.2.1. Простой код
1.2.2. Согласованные объекты
1.2.3. Качественное управление зависимостями
1.2.4. Хорошие абстракции
1.2.5. Правильная работа с внешними
зависимостями
и инфраструктурой
1.2.6. Продуманная модульность
1.3. Простое проектирование как
повседневная
деятельность
1.4. Краткое знакомство с архитектурой
системы
1.5. Пример проекта: PeopleGrow!
1.6. Упражнения
Резюме
Глава 2. Сокращение кода
2.1. Уменьшите единицы кода
2.1.1. Разбивайте сложные методы на закрытые
2.1.2. Переместите сложную часть кода
в другой класс
2.1.3. Когда не стоит разделять код
на небольшие единицы
2.1.4. Получите общее представление о
рефакторинге,
прежде чем приступать к нему
2.1.5. Пример: импорт данных о сотрудниках
2.2. Сделайте код читаемым и
документируйте его
2.2.1. Продолжайте искать хорошие имена
2.2.2. Документируйте решения
2.2.3. Добавьте к коду комментарии
2.2.4. Пример: решение о том, когда отправить
письмо с обновлением
2.3. Не добавляйте новые сложности в
имеющиеся
классы
2.3.1. Выделите сложную бизнес-логику
в отдельный класс
2.3.2. Разбивайте крупные бизнес-процессы
2.3.3. Пример: лист ожидания предложений
2.4. Упражнения
Резюме
3.1. Обеспечьте постоянную согласованность
3.1.1. Сделайте класс ответственным
за его собственную согласованность
3.1.2. Инкапсулируйте сложные проверки
согласованности
3.1.3. Пример: сущность Employee
3.2. Разработка эффективных механизмов
валидации
данных
3.2.1. Сделайте предварительные условия
явными
3.2.2. Создайте компоненты валидации
3.2.3. Осторожно используйте нулевые
значения
или избегайте их, если можете
3.2.4. Пример: запись сотрудника
на курс обучения
3.3. Инкапсуляция проверок состояния
3.3.1. Рассказывайте, а не спрашивайте
3.3.2. Пример: свободные места на курсе
3.4. Предусматривайте только геттеры и
сеттеры,
которые имеют значение
3.4.1. Геттеры, которые не меняют состояния и
не раскрывают клиентам слишком
много информации
3.4.2. Сеттеры только для атрибутов,
описывающих объект
3.4.3. Пример: геттеры и сеттеры
в классе Offering
3.5. Моделируйте агрегаты для обеспечения
инвариантов в кластерах объектов
3.5.1. Не нарушайте правила корня агрегата
3.5.2. Пример: агрегат Offering
3.6. Упражнения
Резюме
4.1. Разделение высоко- и низкоуровневого
кода
4.1.1. Создавайте стабильный код
4.1.2. Разрабатывайте интерфейсы
4.1.3. Когда не стоит отделять
высший уровень от низшего
4.1.4. Пример: работа с сообщениями
4.2. Избегайте привязки к деталям или
элементам,
которые вам не нужны
4.2.1. Запрашивайте или возвращайте только
те классы, владельцем которых вы являетесь
4.2.2. Пример: замена HTTP-бота чатом SDK
4.2.3. Не давайте клиентам больше,
чем им нужно
4.2.4. Пример: список предложений
4.3. Разбейте на части классы, которые
зависят
от множества других классов
4.3.1. Пример: разбор сервиса MessageSender
4.4. Внедрение зависимостей
4.4.1. Избегайте статических методов для
операций,
изменяющих состояние
4.4.2. Всегда внедряйте взаимодействующие
объекты. Все остальное опционально
4.4.3. Стратегии создания экземпляра класса
вместе с его зависимостями
4.4.4. Пример: внедрение зависимостей
в MessageSender и взаимодействующих объектах
4.5. Упражнения
Резюме
Глава 5. Разработка хороших абстракций
5.1. Проектирование абстракций и точек
расширения
5.1.1. Определение потребности в абстракции
5.1.2. Проектирование точки расширения
5.1.3. Свойства хороших абстракций
5.1.4. Учитесь на своих абстракциях
5.1.5. Узнайте об абстракциях
5.1.6. Абстракции и связанность
5.1.7. Пример: выдача значков
сотрудникам
5.2. Обобщайте важные бизнес-правила
5.2.1. Отделите конкретные данные
от обобщенного бизнес-правила
5.2.2. Пример: обобщение правил использования
значков
5.3. Отдавайте предпочтение простым
абстракциям
5.3.1. Эмпирические правила
5.3.2. Простота всегда лучше
5.3.3. Что значит достаточно?
5.3.4. Не бойтесь моделировать абстракции с
самого
первого дня
5.3.5. Пример: повторное рассмотрение примера
со значком
5.4. Упражнения
Резюме
Глава 6. Работа с внешними зависимостями и
инфраструктурой
6.1. Отделите инфраструктуру от кода
доменной области
6.1.1. Нужен ли вам интерфейс?
6.1.2. Скрывайте детали от кода,
а не от разработчиков
6.1.3. Изменение инфраструктуры
в какой-то момент: миф или реальность?
6.1.4. Пример: доступ к базе данных и бот
для отправки сообщений
6.2. Используйте инфраструктуру в полной
мере
6.2.1. Сделайте все возможное, чтобы не
испортить
проект
6.2.2. Пример: отмена записи
6.3. Устанавливайте зависимости только от
того,
что вам принадлежит
6.3.1. Не боритесь со своими фреймворками
6.3.2. Помните о косвенных утечках
6.3.3. Пример: бот для отправки сообщений
6.4. Инкапсуляция низкоуровневых ошибок
инфраструктуры в высокоуровневые ошибки
предметной области
6.4.1. Пример: обработка исключений в SDKBot
6.5. Упражнения
Резюме
Глава 7. Обеспечение модульности
7.1. Создание глубоких модулей
7.1.1. Найдите способы уменьшить
последствия изменений
7.1.2. Постоянно уточняйте границы своих
предметных областей
7.1.3. Храните связанные элементы рядом
друг с другом
7.1.4. Боритесь со случайной связанностью,
а если не можете, то документируйте
7.2. Разработка понятных интерфейсов
7.2.1. Сохраняйте простоту интерфейса модуля
7.2.2. Модули с обратной совместимостью
7.2.3. Обеспечьте чистые точки расширения
7.2.4. Пишите код так, будто вашим модулем
будет пользоваться кто-то другой с иными
потребностями
7.2.5. Модули должны иметь четкие правила
владения и взаимодействия
7.3. Отсутствие тесной связи между модулями
7.3.1. Заставьте модули и клиентов отвечать
за отсутствие тесной связи
7.3.2. Избегайте зависимостей от внутренних
классов
7.3.3. Контролируйте сеть зависимостей
7.3.4. Монолитные приложения или
микросервисы?.
7.3.5. Рассмотрите события как способ
разделения
модулей
7.3.6. Пример: система оповещения
7.4. Упражнения
Резюме
Глава 8. Прагматичность
8.1. Будьте прагматичны и улучшайте проект,
только если это действительно необходимо
8.2. Старательно выполняйте рефакторинг,
но двигайтесь небольшими шагами
8.3. Смиритесь с тем, что ваш код никогда
не будет идеальным
8.4. Рассмотрите возможность
перепроектирования
кода
8.5. Это ваш долг перед новичками
8.6. Ссылки
8.7. Упражнения
Резюме