Как скоро мы достигнем этой вершины компонентно-ориентированной разработки? Движение к ней уже началось, и Oracle стимулирует интерес разработчиков с помощью различных методов, например конкурсов. Одна из потенциальных проблем в компонентно-ориентированной разработке — отсутствие универсального языка для кодирования компонентов. Многие компоненты потребуют взаимодействия между картриджами на клиенте, на сервере баз данных и, возможно, на сервере приложений. В настоящее время картриджи NCA можно разрабатывать только на смеси C/C++ и PL/SQL. Когда Java-революция начнется по-настоящему, мы увидим расширяемые картриджи, которые будут вставляться как в клиентские, так и в серверные компоненты.
Давайте смотреть на вещи реально: необходимость в специализированных разработках будет всегда. Поэтому, по нашему прогнозу, будущее не за не требующими программирования приложениями, а за широким лицензированием относительно дешевой и стабильной технологии, которая позволит свести к минимуму дурацкую работу в процессе проектирования и реализации прикладных систем.
Восходящая и нисходящая схемы разработки
Некоторые специалисты по объектам хотели бы заставить вас поверить в то, что ООАП строится по восходящей схеме. Они анализируют все низкоуровневые объекты (например, заказы и покупателей) в организации и начинают проектировать и разрабатывать свойства и методы на базе объектов. Затем из этого исходного набора они создают набор объектов более высокого уровня, затем еще один уровень и т.д. Смысл этой теории состоит в том, что если вы захотите построить приложение, то у вас уже будет большая часть того, что вам нужно, и задача сведется только к соединению этих компонентов между собой.
Прекрасная теория! Жаль только, что она имеет несколько существенных недостатков:
•    Она требует огромных объемов разработки "авансом", причем эти колоссальные затраты в результате не дают конкретного приложения. Большинство распорядителей средств захотят получить от своих вложений более осязаемый результат.
•    Объекты вряд ли можно четко определить. Например, структура и тенденции изменения заказа во многом зависят от того, из какой системы он анализируется — системы учета сбыта или системы обработки заказов. Трудно создать модель организации так, чтобы удовлетворить требования всех ее отделов или составных частей.
Альтернативный подход — нисходящая модель, реализуемая с применением "заглушек" для низкоуровневых классов, которые еще не созданы. Эти низкоуровневые классы разбиваются на составные части, и создаются "заглушки" для классов следующего уровня. Так делается до тех пор, пока не будут определены и разработаны атомарные классы.
2. Методы проектирования для OraclcS	27