Глава 5. Проектирование при конструировании(часть 2)

На уровне проектирования подсистем важно ограничить их взаимодействие между собой(уровень связанности должен быть низким). Также здесь действует важное правило - граф подсистем не должен содержать циклов.

Некоторые часто встречающиеся на практике подсистемы:

• Подсистема бизнес-правил
• Пользовательский интерфейс
• Доступ к БД
• Подсистема изоляции зависимостей от ОС

Следующий уровень проектирования - уровень разделения подсистем на классы. Основная задача этого этапа - декомпозиция подсистемы на отдельные классы и описание их интерфейсов.
На следующем этапе определяются необходимые приватные методы для реализации публичных интерфейсов классов.
И наконец последний этап - проектирование методов. Сюда входит поиск удачных алгоритмов, написание псевдокода

Эвристические методики проектирования:

• Определение объектов реального мира - определяем объекты, их атрибуты, действия, которые могут выполняться с этими объектами, какие части должны быть доступны извне, а какие должны быть скрыты.
• Определение абстракций
• Инкапсуляция деталей реализации
• Использование наследования - дополняет абстракцию
• Сокрытие секретов - большая часть класса должна быть приватной + скрытие информации, которая подвержена изменениям(магические числа, примитивные типы, некоторые свойства класса - лучше завести сеттер, геттер, которые будут содержать логику к этому полю). Два основных типа секретов: скрывающие сложность и скрывающие источники возможных изменений. Основные проблемы при сокрытии секретов:

• Избыточное распространение информации - большое количество повторяющейся информации и действий в разных местах программы, глобальные переменные
• Круговая зависимость
• Ментальная - кажется, что от этого снижается производительность
• Определение источников изменений: наиболее подвержены изменениям бизнес-правила, зависимости от оборудования, ввод-вывод, нестандартные возможности языка, сложные аспекты проектирования и конструирования, переменные состояния системы. Схема действий:
• Определить наиболее вероятные источники изменений
• Отделить их в отдельные классы
• Изолировать изменения в этих классах(отсечь большинство зависимостей других классов от выделенного)
• Поддержка слабой связанности. Критерии оценки связанности:
• Объём - количество связей
• Видимость - связи должны быть явными
• Гибкость - возможность легко изменить связь                                                                                                                 Виды связей в порядке убывания крутости:
• Через данные-параметры - все параметры - элементарные типы данных
• Посредством объекта - один класс создаёт объект другого класса
• Посредством объекта-параметра - объект постороннего класса передаётся в качестве параметра
• Семантическая связь - один класс обладает знаниями об особенностях поведения другого класса и влияет на него через эти особенности - например изменение состояния постороннего класса путём выставления у него какого-нибудь флажка
• Использование популярных шаблонов проектирования

Что ещё можно попробовать:

• Стремление к максимальной связности
• Формирование иерархий
• Формализация контрактов классов
• Проектирование для удобства тестирования
• Концентрация на плохих сценариях, а не на одном хорошем
• Тщательный выбор времени связывания(присвоения значений переменным)
• Создание центральных точек управления(DRY?)
• Использование грубой силы - делаем неэффективно, зато работает
• Рисование диаграмм

Методики проектирования:

• Итерация - проектируем, ищем, что получилось неочень, делаем изменения и так по кругу.
• Разделяй и властвуй - разбиваем программу на области и проектируем их отдельно
• Нисходящий и восходящий подходы - при нисходящем мы начинаем с верхнего уровня абстракций и путём декомпозиции добираемся до самых деталей, при восходящем наоборот, начинаем с деталей и постепенно, находя между ними общее добираемся до верхнего уровня
• Экспериментальное прототипирование - сделали прототип и выкинули его
• Совместное проектирование

Во время проектирования пишем разную документацию, а именно: документация в коде, вики-статьи, UML диаграммы, резюме обсуждений, CRC-карточки