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

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

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

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

[H]

найти_дом

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

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

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

[H1]

найти_дом

ensure

дом_найден

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

ensure

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

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

require

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

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

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

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

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