Объектные структуры приложений

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

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

Существует три основных класса объектных структур [113].

1. Инфраструктуры систем. Обеспечивают разработку инфраструктур для систем связи (коммуникационных систем), пользовательских интерфейсов и компиляторов [306].

2. Интеграционные структуры. Как правило, состоят из набора стандартов и связанных с ними классов объектов, обеспечивающих взаимодействие и обмен данными между компонентами. К этому типу структур относятся CORBA, СОМ и DCOM от Microsoft, а также Java Beans [264]. Данный тип объектных структур рассматривался в главе 11 при обсуждении архитектур распределенных объектов.

3. Структуры инструментальных сред разработки приложений. Связаны с отдельными прикладными областями, такими как телекоммуникации или финансы [30]. Они встраиваются в систему знаний области приложения и поддерживают разработку приложений конечного пользователя. Данные структуры связаны с семействами приложений, которые рассматриваются в разделе 14.2.

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

На момент написания книги были достаточно хорошо разработаны инфраструктуры систем, особенно те из них, которые связаны с графическими интерфейсами пользователя. Их постепенно вытесняют структуры инструментальных сред разработки приложений [77]. Попытаемся разобрать наиболее эффективные представления и организацию данных объектных структур.

Одной из самых известных и распространенных объектных структур для графических интерфейсов пользователя (GUI) является объектная структура "модель-представление-контроллер" (рис. 14.6). Эта модель появилась в 1980-х годах как метод проектирования графических интерфейсов пользователя, который поддерживает различные представления объекта и различает взаимодействия с каждым из этих представлений.

Рис. 14.6. Объектная структура "модель-представление-контроллер"

Объектные структуры часто реализуются в виде паттернов (см. раздел 14.2). Например, объектная структура "модель-представление-контроллер" включена в паттерн Обозреватель, описанный во врезке 14.1, а также в ряд других паттернов, подробно рассмотренных в работе [124].

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