Skip to main content

ООП и паттерны

Справочник по ООП и паттернам проектирования

Основы ООП​

Абстракция​

Что это: Выделение главных характеристик объекта, игнорирование несущественных деталей
Зачем: Упрощение сложных систем, работа на уровне "что делает", а не "как делает"
Как: Создание классов и интерфейсов, которые определяют общее поведение

Инкапсуляция​

Что это: Объединение данных и методов в одном объекте, скрытие внутренней реализации
Зачем: Защита данных, контроль доступа, упрощение использования
Как: Использование модификаторов доступа (public, private, protected)

Наследование​

Что это: Создание нового класса на основе существующего с наследованием его свойств
Зачем: Повторное использование кода, создание иерархий классов
Как: Класс-наследник получает все поля и методы родительского класса

Полиморфизм​

Что это: Возможность объектов разных типов обрабатываться через единый интерфейс
Зачем: Гибкость кода, работа с разными типами через общие методы
Как: Переопределение методов в наследниках, использование интерфейсов

Паттерны проектирования (от простых к сложным)​

Простые паттерны для начала​

1. Одиночка (Singleton)

  • Гарантирует один экземпляр класса во всей программе
  • Глобальная точка доступа
  • Пример: Настройки приложения, подключение к базе данных

2. Фабрика (Factory)

  • Создает объекты без указания конкретного класса
  • Централизованное создание объектов
  • Пример: Создание документов разных типов

3. Строитель (Builder)

  • Пошаговое создание сложных объектов
  • Разделение конструирования и представления
  • Пример: Построение SQL-запросов, конфигураций

4. Адаптер (Adapter)

  • Преобразует интерфейс одного класса в другой
  • Совмещение несовместимых интерфейсов
  • Пример: Адаптер для работы со старым API

Структурные паттерны​

5. Декоратор (Decorator)

  • Динамически добавляет новую функциональность объектам
  • Альтернатива наследованию для расширения
  • Пример: Добавление логирования, кэширования

6. Фасад (Facade)

  • Простой интерфейс для сложной системы
  • Скрывает сложность подсистем
  • Пример: Упрощенный API для работы с базой данных

7. Компоновщик (Composite)

  • Объединение объектов в древовидные структуры
  • Единый интерфейс для отдельных объектов и их композиций
  • Пример: Файловая система, элементы интерфейса

Поведенческие паттерны​

8. Наблюдатель (Observer)

  • Один объект уведомляет других об изменениях
  • Слабосвязанная система
  • Пример: События в UI, уведомления

9. Стратегия (Strategy)

  • Определяет семейство алгоритмов
  • Возможность замены алгоритмов на лету
  • Пример: Разные алгоритмы сортировки, способы оплаты

10. Состояние (State)

  • Объект меняет поведение при изменении состояния
  • Альтернатива большим условным операторам
  • Пример: Состояния заказа (новый, оплачен, доставлен)

11. Шаблонный метод (Template Method)

  • Определяет скелет алгоритма
  • Некоторые шаги делегирует подклассам
  • Пример: Алгоритм приготовления напитков (кофе/чай)

12. Посредник (Mediator)

  • Централизованное управление взаимодействием объектов
  • Уменьшает связанность между компонентами
  • Пример: Диспетчер сообщений, контроллер чата

Принципы разработки​

KISS (Keep It Simple, Stupid)​

  • Делайте код максимально простым
  • Избегайте ненужной сложности
  • Простота = надежность + понятность

DRY (Don't Repeat Yourself)​

  • Каждая часть знания должна иметь единственное представление
  • Дублирование = источник ошибок
  • Выносите общую логику в отдельные функции/классы

SOLID​

S — Single Responsibility
Один класс = одна ответственность

O — Open/Closed
Открыт для расширения, закрыт для модификации

L — Liskov Substitution
Наследники должны заменять родителей

I — Interface Segregation
Много специализированных интерфейсов лучше одного большого

D — Dependency Inversion
Зависите от абстракций, а не от конкретных классов

PoC (Proof of Concept)​

  • Прототип для проверки идеи
  • Минимальная реализация для демонстрации возможности
  • Техническое обоснование перед полной разработкой

MVP (Minimum Viable Product)​

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

MVC (Model-View-Controller)​

  • Разделение приложения на три компонента:
    • Model — данные и бизнес-логика
    • View — отображение, пользовательский интерфейс
    • Controller — обработка ввода, связь Model и View
  • Четкое разделение ответственности

DDD (Domain-Driven Design)​

  • Разработка, ориентированная на предметную область
  • Основные понятия:
    • Доменная модель — центральная часть
    • Универсальный язык — общий язык для разработчиков и экспертов
    • Ограниченный контекст — границы моделей
    • Сущности, Объекты-значения, Агрегаты — строительные блоки
  • Фокус на бизнес-логике, а не технических деталях

Когда что использовать​

На этапе анализа:​

  • DDD — для понимания предметной области
  • PoC — для проверки технических гипотез

На этапе проектирования:​

  • SOLID — для проектирования архитектуры
  • Паттерны — для решения конкретных задач проектирования
  • MVC — для организации структуры приложения

На этапе разработки:​

  • KISS — при написании каждого метода
  • DRY — при обнаружении дублирования
  • SOLID — при создании и рефакторинге классов

На этапе выпуска:​

  • MVP — для определения первого релиза
  • Итеративное развитие на основе обратной связи

Правила хорошего тона​

  1. Начинайте с простого (KISS)
  2. Избегайте дублирования (DRY)
  3. Соблюдайте принципы SOLID
  4. Используйте паттерны обдуманно, а не везде
  5. Думайте о предметной области (DDD)
  6. Разделяйте ответственность (MVC)
  7. Итеративно развивайте продукт (MVP)

Материалы​