Объектно-ориентированный анализ и проектирование

Объектно-ориентированный анализ отвечает: какие понятия, состояния и правила есть в предметной области. Проектирование отвечает: как распределить эти обязанности между программными объектами.

Анализ

Начинаю не с классов, а со сценария:

Клиент подтверждает заказ.
Заказ проверяет допустимость перехода.
Платёж подтверждает исполнение обязательства.
Повтор команды не создаёт второй результат.

Из текста выделяются:

• сущности с идентичностью;
• значения без самостоятельной идентичности;
• действия и доменные события;
• инварианты;
• границы транзакции;
• внешние участники.

Семантику терминов фиксирует Представление системы семантической моделью.

Проектирование

Ответственность размещаю рядом с данными, инвариант которых она защищает:

final class Order {
    private OrderStatus status;
 
    void confirmPayment() {
        if (status != OrderStatus.NEW) {
            throw new IllegalStateException("Unexpected state: " + status);
        }
        status = OrderStatus.PAID;
    }
}

Это предпочтительнее объекта только с getters/setters, если переход является доменным правилом.

Отношения

• ассоциация — один объект знает другой;
• композиция — часть принадлежит целому и разделяет жизненный цикл;
• агрегация — более слабое отношение целого и части;
• наследование — отношение «является» с подстановкой;
• зависимость — временное использование.

Композиция часто безопаснее наследования: она не связывает подкласс со внутренними решениями родителя.

Какие диаграммы полезны

• диаграмма классов — структура и отношения;
• sequence diagram — порядок взаимодействий;
• state diagram — допустимые переходы;
• component diagram — крупные зависимости.

Диаграмма нужна, если отвечает на вопрос; она не заменяет код и тесты.

Связано: Основы ООП, Формализованное описание элементов системы и взаимодействия между ними.

Самопроверка

• Чем объект анализа отличается от Java-класса?
• Где лучше держать инвариант перехода состояния?
• Когда наследование нарушает подстановку?