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

11.3.3.1 Шаг 1: определение классов

Определите понятия/классы и установите основные связи между ними. Главное в хорошем проекте - прямо отразить какое-либо понятие "реальности", т.е. уловить понятие из области приложения классов, представить взаимосвязь между классами строго определенным способом, например, с помощью наследования, и повторить эти действия на разных уровнях абстракции. Но как мы можем уловить эти понятия? Как на практике решить, какие нам нужны классы?

Лучше поискать ответ в самой области приложения, чем рыться в программистском хранилище абстракций и понятий. Обратитесь к тому, кто стал экспертом по работе в некогда сделанной системе, а также к тому, кто стал критиком системы, пришедшей ей на смену. Запомните выражения того и другого.

Часто говорят, что существительные играют роль классов и объектов, используемых в программе, это действительно так. Но это только начало. Далее, глаголы могут представлять операции над объектами или обычные (глобальные) функции, вырабатывающие новые значения, исходя из своих параметров, или даже классы. В качестве примера можно рассматривать функциональные объекты, описанные в 10.4.2. Такие глаголы, как "повторить" или "совершить" (commit) могут быть представлены итеративным объектом или объектом, представляющим операцию выполнения программы в базах данных.

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

Лучшее средство для поиска этих понятий / классов - грифельная доска, а лучший метод первого уточнения - это беседа со специалистами в области приложения или просто с друзьями. Обсуждение необходимо, чтобы создать начальный жизнеспособный словарь терминов и понятийную структуру. Мало кто может сделать это в одиночку. Обратитесь к [1], чтобы узнать о методах подобных уточнений.

Не все классы соответствуют понятиям из области приложения. Некоторые могут представлять ресурсы системы или абстракции периода реализации (см. 12.2.1).

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

В 11.3.3.2 и 11.3.3.5 предлагается некоторая точка зрения на классы и иерархию классов, если необходимо улучшить их структуру.

11.3.3.2 Шаг 2: определение набора операций

Уточните определения классов, указав набор операций для каждого. В действительности нельзя разделить процессы определения классов и выяснения того, какие операции для них нужны. Однако, на практике они различаются, поскольку при определении классов внимание концентрируется на основных понятиях, не останавливаясь на программистских вопросах их реализации, тогда как при определении операций прежде всего сосредотачивается на том, чтобы задать полный и удобный набор операций. Часто бывает слишком трудно совместить оба подхода, в особенности, учитывая, что связанные классы надо проектировать одновременно.

Возможно несколько подходов к процессу определения набора операций.

Предлагаем следующую стратегию:

1. Рассмотрите, каким образом объект класса будет создаваться, копироваться (если нужно) и уничтожаться.
2. Определите минимальный набор операций, который необходим для понятия, представленного классом.
3. Рассмотрите операции, которые могут быть добавлены для удобства записи, и включите только несколько действительно важных.
4. Рассмотрите, какие операции можно считать тривиальными, т.е. такими, для которых класс выступает в роли интерфейса для реализации производного класса.
5. Рассмотрите, какой общности именования и функциональности можно достигнуть для всех классов компонента.

Очевидно, что это - стратегия минимализма. Гораздо проще добавлять любую функцию, приносящую ощутимую пользу, и сделать все операции виртуальными. Но, чем больше функций, тем больше вероятность, что они не будут использоваться, наложат определенные ограничения на реализацию и затруднят эволюцию системы. Так, функции, которые могут непосредственно читать и писать в переменную состояния объекта из класса, вынуждают использовать единственный способ реализации и значительно сокращают возможности перепроектирования. Такие функции снижают уровень абстракции от понятия до его конкретной реализации. К тому же добавление функций добавляет работы программисту и даже разработчику, когда он вернется к проектированию. Гораздо легче включить в интерфейс еще одну функцию, как только установлена потребность в ней, чем удалить ее оттуда, когда уже она стала привычной.

Причина, по которой мы требуем явного принятия решения о виртуальности данной функции, не оставляя его на стадию реализации, в том, что, объявив функцию виртуальной, мы существенно повлияем на использование ее класса и на взаимоотношения этого класса с другими. Объекты из класса, имеющего хотя бы одну виртуальную функцию, требуют нетривиального распределения памяти, если сравнить их с объектами из таких языков как С или Фортран. Класс с хотя бы одной виртуальной функцией по сути выступает в роли интерфейса по отношению к классам, которые "еще могут быть определены", а виртуальная функция предполагает зависимость от классов, которые "еще могу быть определены" (см. 12.2.3)

Отметим, что стратегия минимализма требует, пожалуй, больших усилий со стороны разработчика.

При определении набора операций больше внимания следует уделять тому, что надо сделать, а не тому, как это делать.

Иногда полезно классифицировать операции класса по тому, как они работают с внутренним состоянием объектов:

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

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

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

11.3.3.3 Шаг 3: указание зависимостей

Уточните определение классов, указав их зависимости от других классов. Различные виды зависимостей обсуждаются в 12.2. Основными по отношению к проектированию следует считать отношения наследования и использования. Оба предполагают понимание того, что значит для класса отвечать за определенное свойство системы. Отвечать за что-либо не означает, что класс должен содержать в себе всю информацию, или, что его функции-члены должны сами проводить все необходимые операции. Как раз наоборот, каждый класс, имеющий определенный уровень ответственности, организует работу, перепоручая ее в виде подзадач другим классам, которые имеют меньший уровень ответственности. Но надо предостеречь, что злоупотребление этим приемом приводит к неэффективным и плохо понимаемым проектам, поскольку происходит размножение классов и объектов до такой степени, что вместо реальной работы производится только серия запросов на ее выполнение. То, что можно сделать в данном месте, следует сделать.

Необходимость учесть отношения наследования и использования на этапе проектирования (а не только в процессе реализации) прямо вытекает из того, что классы представляют определенные понятия. Отсюда также следует, что именно компонент (т.е. множество связанных классов), а не отдельный класс, являются единицей проектирования.