Маурисио Аниче | Простое объектно-ориентированное проектирование: чистый и гибкий код [2 книги] (2024) [PDF] [RU, EN]

Оглавление

Посвящение
Предисловие
Благодарности
О книге
Кому стоит прочитать эту книгу
Структура издания
О коде
Другие онлайн-ресурсы
Об авторе
Иллюстрация на обложке
От издательства

Глава 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. Обеспечение согласованности объектов
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. Управление зависимостями
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. Упражнения
Резюме

Маурисио Аниче Простое объектно-ориентированное проектирование: чистый и гибкий код
В оригинале: Aniche Mauricio. Simple Object Oriented Design: Create Clean, Maintainable Applications

Write object-oriented code that’s manageable, maintainable, and future-proof.
Keeping your object-oriented designs simple demands a creative approach—and that’s exactly what you’ll find in Simple Object-Oriented Design. This book is full of patterns and principles for reducing complexity, each one proven in author Mauricio Aniche’s 20-year career in software development. You’ll learn how to tackle code’s natural growth in complexity, and adopt a “good enough” approach that means it’s easy to refactor when requirements change.
You’ll discover insightful principles for
Making code readable and documented
Improving consistency and encapsulation
Managing dependencies
Designing abstractions
Handling infrastructure
Effective modularization
Learn what constitutes both good and bad object-oriented software design, discover how to make better trade-offs in design decisions, and when to embrace complexity over simpler data structures. With this book as your vital reference, you’ll be ready to write code that will last the test of time, without slowing feature delivery to a crawl.
This book delves into object-oriented design from two specific angles: how to prevent the complexity of a system from skyrocketing and how to achieve “good-enough” designs. First, most of a developer’s work revolves around maintaining and evolving existing systems. Unfortunately, without due care, every time you make changes to a software system, it becomes more complex, even if it is well designed from the outset. Therefore, this book greatly emphasizes how to combat the natural growth in complexity. Second, more often than not, you initially have limited knowledge about what you’re building. Despite your best efforts, your first design may fall short. However, that’s acceptable if you arrive at a good-enough design. The purpose of this book is not to lead you to always achieve the absolute best possible design, but to enable you to create good designs that empower you to build software effectively.
about the technology
Even a simple object-oriented application can quickly become complex as it evolves. Each new class, method, or feature means more state and abstractions to manage, which in turn increases complexity, maintenance, and time spent detangling legacy code. It takes effort and skill to keep your codebase simple. This book shows you how.
about the book
Simple Object-Oriented Design: Create clean, maintainable applications presents practical design principles you can use to keep an object-oriented codebase simple as it grows and changes. Written as a collection of practical techniques you can apply in any OO language, it offers tips for concise code, managing dependencies and modules, and designing flexible abstractions. Illuminating figures, real-world examples, and insightful exercises make each principle stick.
preface
It’s all about managing complexity
Making code small
Keeping objects consistent
Managing dependencies
Designing good abstractions
Handling external dependencies and infrastructure
Achieving modularization
Being pragmatic