     Центр
Практичных Программ |
Мы едем, едем, едем ... Методы разработки практичных и ориентированных на пользователя интерфейсов эффективны для создания проектов. Но когда дело доходит до практики, т.е. до программирования, начинаются проблемы. Можно легко начертить на бумаге, как будет выглядеть тот или иной интерфейс. Можно легко описать его поведение. Но реализовать проект в коде бывает иногда очень сложно, а в некоторых случаях и невозможно. Суть проблемы не зависит от используемой среды разработки и заключается в ограниченности и дискретности компонентов, из которых строится программа. Поясню, что имеется в виду. В любом современном средстве разработки приложений используется библиотека (библиотеки) готовых элементов управления - "компонентов". Примеры таких библиотек компонентов - MFC (Microsoft Foundation Classes, VCL (Visual Components Library), JFC (Java Foundation Classes) и т.д. Сюда можно также отнести и распространяемые отдельно элементы управления ActiveX. Набор свойств и поведение компонентов определяется их создателями и с трудом поддается изменению или дополнению. Если спроектированный интерфейс можно реализовать с помощью только имеющихся компонентов или слегка их изменив - нет проблем. Если же требуется что-то новое, или "лежащее между" готовыми компонентами, такая задача может стать неразрешимой. Здесь свобода творчества дизайнера интерфейсов сталкивается с суровой действительностью жизни программиста. В качестве метафоры для сложившейся проблемы можно представить себе сеть автодорог, проложенных по пересеченной местности между различными пунктами и задачу попасть из одного пункта (текущее состояние проекта) в другой (необходимое состояние проекта). Можно ехать к пункту назначения по дорогам, но путь может оказаться длинным, а в некоторых случаях дороги до конечного пункта может и не быть. Кратчайший же пункт ведет через горы и овраги. Машина может не проехать или даже сломаться. |
Итак, если
возникла вышеописанная проблема, решать ее можно
тремя способами:
Все три способа требуют больших затрат времени и усилий, а в последнем случае еще возможно и денег, так как искомый компонент может оказаться платным (за проезд по этой дороге будут брать деньги). Последний вариант решения затрагивает еще один аспект проблемы. В настоящее время вполне может существовать большое количество похожих компонентов, слегка или сильно различающихся друг от друга. Если поиск завершился удачно, найденный компонент может реализовать недостающие функции, но в то же время в нем может не хватать некоторых свойств, которые были в старом, или они могут работать иначе. В любом случае мы приходим к необходимости переделать уже готовый и возможно, отлаженный код. Но чаще всего происходит обратное: вновь найденный компонент содержит "лишние" свойства, не требуемые данной программе. В результате этот неиспользованный код будет включен в готовую систему. А мы еще удивляемся, почему современные программы такие огромные!
Довольно теории, перейду к примерам. Предположим, что в программе используется обычное поле для редактирования текста (рис.1 слева). Для макетирования интерфейса его было достаточно, но в готовой программе по замыслу разработчиков он должен обеспечивать еще и синтаксическое выделение текста (рис.1 справа). Первый компонент является практически стандартным для Windows, т.е. большая часть его кода находится в операционной системе. И, поскольку самостоятельная реализация синтаксического выделения текста - занятие трудоемкое и напрасное, был найден компонент, его реализующий. Но вместе с тем этот компонент позволял еще и форматировать фрагменты текста, а также сохранять и читать текст в различных форматах, что для данного проекта было совершенно ненужно.
Еще пример, хорошо знакомый разработчикам приложений для баз данных - элемент управления под общим названием Grid (рис. 2), служащий для отображения содержимого таблиц. Этот компонент, вероятно является лидером по числу существующих своих модификаций - от самых простых, до приближенных к листам Excel с формулами. Причем это количество постоянно увеличивается! Разве это не указывает на проблему? Даже такого количества вариантов одного и того же элемента управления не хватает для всех случаев его применения, и очередной программист со вздохом садится за клавиатуру. Что за напрасная трата времени ? |
Какое же может быть здесь решение? Во-первых, необходимо устранить причину появления новых элементов управления, встроив их в операционную систему, т.к. стандартных уже давно и явно не хватает. Необходимо провести анализ и выявить оптимальные свойства новых компонентов. Тем не менее саму возможность создавать свои элементы управления нужно оставить, ведь всех вариантов никогда не учесть. Однако, если значительная часть используемых сейчас компонентов будет встроена в ОС, это приведет к упрощению процесса разработки программ и уменьшению размера исполняемых файлов. Во-вторых, новых элементов не должно быть много, но каждый должен включать в себя максимальное количество необходимых функций. Например, Grid должен обеспечивать функциональность на уровне Excel, а окно редактирования - возможности Word.
В-третьих, необходимо еще одно нововведение. Универсальный Grid само по себе дело хорошее, но программисты знают, что избыточные возможности не просто существуют, они занимают дополнительную память при создании объекта в программе и ресурсы процессора при работе, что, мягко говоря, не хорошо. Решить проблему поможет "секционная" архитектура компонентов, когда они реализуются таким образом, что отдельные независимые друг от друга секции функций можно "отключать" еще на этапе разработки. Тем самым мы указываем, что данные возможности нам не нужны и использоваться не будут. В результате во время работы программы "отключенные" функции выполняться не будут и память под них выделяться тоже не будет. Конечно деление компонента на секции должно быть очень хорошо продумано. Например, для того же окна с текстом можно определить следующие секции: - базовую, только для отображения
текста (получаем обыкновенную надпись) Пока что затронутая в статье проблема далека от своего решения. Но давайте будем надеяться, что и мы с вами застанем то время, когда дороги будут проложены везде. |
