Предприятие реального времени №1 |
| На главную Новости Карта сайта |
Задача заключается в построении библиотеки классов, содержащих общую для всех приложений функциональность - выделение квантов данных(Wrapper), построение структур связанных квантов данных (Composite Wrapper), управление событиями, связи между квантами данных посредством системы событий (signal/slot management) и построении каркаса(framework) приложения, содержащего систему построения визуализаторов(Views) по данным квантам данных.
Несколько слов о требованиях к классам модели и классам пользовательского интерфейса, способствующих более четкому расслоению архитектуры и, следовательно, улучшению гибкости при внесении изменений в один из "слоев".
Зачастую бизнес-классы (будем классифицировать их как "модель") не имеют функций, требуемых от модели уровнем визуализации (далее - "вид") согласно паттерну MVC, например уведомления элементов GUI об изменениях.
Бизнес-классы не обязаны управлять преобразованиями потока соответствующей информации: например класс, рассчитывающий скорость твердого тела не обязан нести информацию о различных единицах длины и скорости, т.е. м/с, миль/час и т.п.
С учетом того, что по мнению автора большинство читателей знакомы с Sun JFC(Swing) API, уместно привести
еще одно ограничение: классы пользовательского интерфейса (GUI, текстовый интерфейс) не обязаны знать
о наличии других таких классов.
Дело в том, что во многих библиотеках пользовательских интерфейсов, в том числе JFC,
для построения элементов управления явно или скрыто применяется модель MVC в которой роль модели
играет совсем не бизнес-класс и не абстрактная модель приложения, о которой идет речь в данной статье,
а специализированная модель пользовательского интерфейса. С нашей точки зрения сейчас все представители
этой MVC - структуры являются "видом" и спрятаны внутри него.
Такой подход каскадного разбиения ответственности
классов вполне допустим и оправдан повышением эффективности труда создателей графической библиотеки.
Теперь переформулируем последнее ограничение на примере JFC:
(под)класс модели таблицы TableModel не обязан знать
о существовании (под)класса модели дерева TreeModel.