
- •Цели проведения анализа
- •Подход к проектированию программ в целом
- •Рекомендации:
- •30 Принципов объектно-ориентированного дизайна
- •Пример построения диаграммы классов. Задание: Построить диаграмму классов dom демонстрационно-обучающей системы решения квадратных уравнений. Шаг 1. «Вначале было слово…»
- •Оценка модели:
- •Шаг 2. «Раз ромашка, два ромашка…»
- •Примечания:
- •Оценка модели:
- •Справка:
- •Шаг 3. «Позовите Вия!..»
- •Примечания:
- •Оценка модели:
- •Заключение
Оценка модели:
Данная модель тоже не лишена недостатков (например, класс, реализующий новый алгоритм решения квадратного уравнения будет иметь совершенно другой интерфейс, к которому придется адаптировать слой представления – нарушен принцип обратной совместимости, что затруднит развитие проекта), но следуя принципу YAGNI, сейчас мы их рассматривать не будем (хотя очень хочется).
Следующий насущный вопрос: кто (или что) будет «связывать» уравнение с решением и с построением графика, а так же «следить» за ходом этих процессов? Перефразируя «умным языком», какой класс (объект) будет отвечать за обработку системных событий?
Вывод:
Необходимо включить в модель контроллер.
Справка:
Контроллер – структурный паттерн проектирования GRASP (англ. General Responsibility Assignment Software Patterns (общие образцы распределения обязанностей)) – это объект, который отвечает за обработку системных событий и не относится к интерфейсу пользователя. Контроллер определяет методы для выполнения системных операций.
Шаг 3. «Позовите Вия!..»
Итак, в системе для модуля-демонстратора определен прецедент «решить уравнение» (см. диаграмму прецедентов), состоящий из следующих сервисов:
Ввести коэффициенты
Вычислить корни
Построить график
Очевидно, что прежде, чем ввести коэффициенты, объект «уравнение» необходимо создать (строго говоря, за создание экземпляров классов в GRASP отвечает другой паттерн – Creator, но для упрощения примера прикроем глаза на эту деталь). То же касается и экземпляров других классов. Список методов класса контроллера (назовем его, по традиции, TQuadraticController) будет примерно такой:
Таблица 3
Метод |
Описание |
TQuadraticEquation* CreateEquation() |
Создает экземпляр класса «квадратное уравнение» и возвращает ссылку на созданный объект. |
TQuadraticSolution* CreateSoluion() |
Создает экземпляр класса «решение квадратного уравнения» и возвращает ссылку на созданный объект. (Т.к. в системе есть решение только одного типа, то метод для внутреннего использования функцией Solve) |
TQuadraticGraphData* CreateGraphData () |
Создает экземпляр класса «данные для построения графика квадратного уравнения» и возвращает ссылку на созданный объект. (Т.к. в системе есть только один тип графика, то метод для внутреннего использования функцией Draw) |
void Solve(TQuadraticEquation* E, TStrings* S) |
Функция демонстрации решения уравнения. Входные параметры: Е – указатель на решаемое уравнение S – указатель на коллекцию строк, в которую будет помещен ход решения (стандартный класс для хранения массива строк Borland C++ Builder) |
void Draw(TQuadraticEquation* E, TCanvas* C) |
Функция построения графика. Входные параметры: Е – указатель на решаемое уравнение C – ссылка на объект типа «холст», где будет нарисован график (стандартный класс для отображения граф. информации Borland C++ Builder) |
… |
… |
Для экономии места и времени первая колонка с наименованием классов опущена.
Рис. 3. Диаграмма классов на третьем шаге.