Проектирование реализации

Цель этапа проектирование классов – найти подходящие классы и определить требования к ним.

Цель этапа проектирование реализации – изобрести реализацию класса, удовлетворяющую требованиям к нему.

В предложенном мною подходе логика проектирования может быть выражена формулой:

Функциональная модель => Группы функций => Кандидаты в классы => Реализация

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

После создания функциональной модели, можно приступать к проектированию классов.

Классический объектно-ориентированный подход даёт проектировщику чёткое руководство, как это делать.

Прежде всего, в предметной области следует найти ключевые абстракции. Различные учебники по ООП пишут, что для графического редактора ключевой абстракцией является фигура.

Затем следует установить взаимосвязи между ключевыми абстракциями. Если взаимосвязь можно выразить отношением is-a, то такие абстракции следует связать при помощи  наследования. Если взаимосвязь подходит под отношение has-a, то такие абстракции следует связать при помощи агрегации.

Для графического редактора абстрактную фигуру можно связать отношением наследования с конкретными фигурами: прямоугольником, эллипсом, треугольником и т.п.

Получается стройная и логичная картина:

class Figure;

class Rectangle : public Figure;

class Ellipse   : public Figure;

class Triangle  : public Figure;

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

Проектирование: расширение функциональной модели

Прежде чем приступать к проектированию структур данных, следует убедиться в том, что построенная функциональная модель системы достаточно полна.

Будем считать функциональную модель полной, если рассмотрение каждого последующего прецедента не приводит к добавлению новых функций.

Основная ошибка, допускаемая неопытными разработчиками, заключается в том, что они рассматривают упрощённые прецеденты. (Или же не рассматривают их вообще.) Чтобы построить полную функциональную модель, нужно изучать сложные юз-кейсы, взятые из реальной жизни.

Вернёмся к нашему примеру – "проектирование графического редактора для создания открыток".

Первая часть.

Вторая часть.

В третьей части мы расширим функциональную модель модуля редактирования.

Проектирование: построение функциональной модели

Прежде чем проектировать структуры данных, разработчик должен построить функциональную модель проектируемой системы.

В умных книжках по OOA&D рекомендуют поступать наоборот: сначала выявлять классы и объекты и лишь затем – находить операции для этих классов и объектов. Автор данного блога рекомендует не верить умным книжкам и начинать проектирование с выявления функций.

У автора есть веские основания для такой рекомендации: любая техническая система создаётся для выполнения каких-то полезных функций. Если она их не выполняет, то такая система не нужна. Согласитесь, мало кому в быту будет полезен стул со сломанными ножками. Просто потому что на нём невозможно сидеть. В программной индустрии точно также. Если программа не делает нечто полезное, её можно удалить с компьютера, чтобы она не занимала место.

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