Основы объектно-ориентированного программирования

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

Упорядочивание и ОО-разработка

Риск преждевременного упорядочивания заслуживает более глубокого рассмотрения, поскольку даже ОО-проектировщики не имеют к нему иммунитета. Подход списка покупок - это один из наименее понятных компонентов метода. Довольно часто можно встретить ОО-проекты, попавшие в старую ловушку, что немедленно отражается на их качестве. В частности, это может быть результатом неправильного использования идеи разбора случаев - case технологии, с которой мы встретимся при изучении ОО-методологии.

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

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

[H]

найти_дом

получить_ссуду

подписать_контракт

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

[H1]

найти_дом

ensure

дом_найден

получить_ссуду

ensure

ссуда_получена

подписать_контракт

require

дом_найден and ссуда_получена

Нотация будет введена только в лекции 11, но и здесь все должно быть достаточно ясно. Предложение require задает предусловие, логическое свойство, требуемое операцией перед ее выполнением; ensure - задает постусловие, свойство, выполняемое после завершения операции. Тем самым нам удалось описать результат двух операций, и то, что последняя операция требует для своего выполнения достижения результата этих операций.

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

Подход, основанный не на порядке операций, а на логических ограничениях, более уравновешенный. Каждая операция просто устанавливает, что ей необходимо и что она гарантирует, -все это в терминах абстрактных свойств.

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

Возможность повторного использования

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

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

Рис. 5.4.  Контекст модуля при разработке сверху вниз