Сравнительный анализ библиотек классов для разработки графических интерфейсов MFC и QT

Сегодня практически невозможно представить себе приложение, не имеющее графического интерфейса пользователя (Graphic User Interface). Понятия программное обеспечение и GUI неразрывно связаны друг с другом. Библиотеки для создания пользовательского интерфейса применяются в большом количестве операционных систем. Начиная с Motif для ОС UNIX и заканчивая широко известной MFC (Microsoft Foundation Class) от Microsoft для ОС Windows. Хотя Windows API (Application Programming Interface) – интерфейс программирования приложений, обладает всеми необходимыми для создания графического интерфейса пользователя, использование доступных инструментов требует больших затрат и времени и практического опыта. Создание и использование таких библиотек как MFC и QT призвано ускорить и облегчить создание приложений с графическим интерфейсом.

Целью статьи является проведение сравнительного анализа библиотеки классов для разработки графических интерфейсов MFC и QT.

Microsoft Foundation Class (MFC) – это библиотека классов, графический инструментарий для операционных систем Windows [6].

Это надстройка над интерфейсом прикладного программирования (API) win32. Предоставляемый инструментарием MFC API имеет смешанный C/C++ — интерфейс.

QT – это кросс-платформенная библиотека, графический С++ — инструментарий, который разрабатывается с 1994 года Trolltech. Он доступен для Windows (любой версии), UNIX (любой версии), MacOS X[1].

Концепция «документ-представление» (Document/View)

Библиотека MFC требует от программиста использования модели «документ-представление» и шаблонов. Почти невозможно не использовать их. Но шаблоны имеют фиксированную структуру, и поэтому очень сложно расширить их возможности. Например, невозможно разделить область и отобразить два вида двух различных документов. Вторая проблема заключается в том, что шаблон создает вид, но не имеет к нему доступа. Все должно быть сделано документом, и это в некоторых случаях затрудняет разработку.

QT в свою очередь не ограничивает программиста какой-либо моделью дизайна. Без каких – либо ограничений программист может использовать модель «документ-представление» если сочтет это нужным. Или не использовать ее.

Сравнение псевдообъектной и объектной архитектур

Главное отличие между Qt и MFC- в их дизайне. MFC – это библиотека имеющая псевдообъектный дизайн, так как создавалась во время, когда объектно-ориентированные принципы программирования не было до конца сформулированы. Например, использует это библиотеку в некоторых случаях программист должен будет снабжать С-структуру 15-тью членами, из которых только один будет релевантным[3].

Qt – это библиотека построенная на объектно-ориентированной архитектуре. Её инструментарий имеет согласованное именование, наследование, организвацию классов и методов. Количество аргументов методов ограниченно только необходимыми. Их порядок постоянен для различных классов. Использовав однажды один из классов, программист легко сможет использовать и другие, так как они работают сходным образом[1].

Цикл сообщений

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

Работа QT базируется на механизме обратного выхода, основанном на передаче сигналов и их приёме слотами (Slots). Эта система является основным механизмом связи между объектами. Сигнал может передавать любое число аргументов. Необходимые сигналы подключаются к соответствующим слотам, так что в итоге программист всегда знает, что происходит. Число сигналов, передаваемых классом, обычно невелико (4-5), и все они очень хорошо документированы. Этот процесс находится под полным контролем программиста. Механизм использования сигналов и слотов приближенно напоминает Java listener, но он более легко весен и универсален [1-2].

Создание интерфейса.

MFC не обеспечивает компоновку элементов управления внутри окна: это создает проблемы при желании сделать окно измеряемого размера. Необходимо вручную перемещать элементы управления при изменении размеров окна (это объясняет, почему большинство диалоговых окон Windows неизменяемого размера).

Данная проблема приобретает большее значение для программ, интерфейс которых должен быть переведен на язык с более длинными словами или предложениями. Программист должен будет перекомпоновать программу для каждого такого языка.

Редактор ресурсов Visual Studio достаточно ограничен: можно расположить элементы управления в фиксированных позициях и только.

Некоторые свойства могут быть откорректированы, а мастер класса позволяет легко создавать переменные и методы. Однако стоит заметить, что создать вручную цикл сообщений, функцию DDX (Dialog Data Exchange) или макрос IMPLAMENT_DYNCREATE будет достаточно сложно.

QT имеет гибкий механизм компоновки, который является очень простым. Для создания пользовательского графического интерфейса QT предлагает инструмент QT Designer. С помощью него можно откорректировать любые свойства используемых элементов управления.

Программист не фиксирует жестко их расположение, а использует компоновщик (layout manager). Так же можно подключить сигналы к слотам. Это делает QT Designer больше, чем обычный дизайнер интерфейса. Он генерирует код, который программист фактически может читать и понимать. Поскольку сгенерированный код сохраняется в отдельном файле, его можно изменить в любой момент.

Qt Designer позволяет делать то, что невозможно в MFC, например, создать список с предзаполненными полями или использовать различного вида вкладки (tab controls).

Юникод

Чтобы отобразить юникод в MFC, необходимо скомпилировать и собрать приложение со специальными опциями. Программист должен добавить макрос (_T) к каждой строке, используемой в программе, и сменить тип сhar на TCHAR. Большим минусом является то, что программа, откомпилированная с поддержкой юникода, не будет работать с библиотеками DDL, откомпилированными без его поддержки. Если при разработке использовались сторонние библиотеки DDL, это может принести серьезные неудобства.

Строки в Qt являются объектами класса QString, который изначально поддерживает юникод. Поэтому не придется изменять код или использовать какие-либо опции при компиляции и сборке. Класс QString достаточно функционален, даже если не заботится об юникоде.

Поэтому поддержка юникода достигается весьма просто.

Большое различие между строковым классом MFC CString и QString заключается в их дизайне. CString основан на типе char* с несколькими методами. Преимущество такого подхода в том, что везде, где требуется переменная типа char*, можно использовать член класса CString. Однако недостатком такого подхода является то, что  можно изменить член  char* класса CString без обновления самого объекта класса. Также возникают трудности при преобразовании в юникод.

QString, напротив, содержит юникод-версию строки и обеспечивает тип char* только когда требуется. API Qt в качестве строчных аргументов всегда требует QString, поэтому программисту редко придется использовать тип char*. Класс QString также обладает некоторыми дополнительными возможностями, вроде совместного использования содержимого строки.

Локализация

MFC- программу можно локализировать. Для этого необходимо поместить каждую строку в строковую таблицу и везде в коде использовать функцию LoafString (IDENTIFIER). Затем необходимо поместить строковую таблицу в библиотеку DLL. Используя Visual Studio перевести строки в желаемый язык, преобразовать графические ресурсы (поэтому, что их текст не может быть помещен в строковую таблицу) и использовать эту библиотеку в программе достаточно сложно, переводчик не сможет сделать эту работу самостоятельно, ему потребуется помощь программиста. Также могут возникнуть проблемы из-за фиксированного позиционирования элементов управления в MFC. Так как их расположение определялось длиной не переведенных строк, более длинные переведенные фразы будут накладываться. Если в последствии программист изменяет некоторые строки или добавит новые, он должен будет убедиться, что перевод был обновлен.

В Qt программист всего лишь передает строки функции tr (). Это очень удобно при разработке – программист может изменять строки непосредственно в его коде. Специальная программа Qt Linguist извлекает все требующие перевода строки и в удобном виде их отобразит. Ее интерфейс обеспечивает удобный перевод, возможность использования словаря, просмотр контекста строки, обнаружение конфликта клавиатурных сокращений обнаружение новых не переведенных или измененных строк. Эта программа может использоваться переводчиком без познаний в области разработки программ. Редактор Qt Linguist доступен по лицензии GPL, поэтому его можно модифицировать. Перевод сохраняется в формате XML, поэтому он может быть легко использован в различных целях. Задача добавления к программе нового перевода заключается в создании нового файла с помощью Qt Linguist [2].

Распространение

При распространении приложения, созданного с помощью MFC, программист должен использовать MFC-библиотеку поставляемую вместе с Windows. При этом необходимо учитывать, что под одним и тем же названием, к примеру, MFC42.DLL, могут скрываться несколько различных версий этой библиотеки и в противном случае, ее обновить. Обновление библиотеки MFC может повлиять на работу многих приложений.

Названия библиотек Qt недвусмысленны (qt-mt303.dll),поэтому нет никакого риска, что установка библиотеки qt-mt303.dll. Также отсутствует проблема обновления системы в целом.

Вывод.

Анализируя все вышеперечисленные возможности и недостатки двух библиотек можно сделать вывод, что библиотека классов MFC во многом уступает Qt и является менее гибкой. В то же время, следует сказать о высокой стоимости корпоративной версии Qt. Тем не менее, разработчики библиотеки Qt выпускают GPL версию библиотеки, что делает ее доступной учебным заведениям и программистам, разработчикам, которые создают программы с открытым исходным кодом.

Литература

  1. Organick E.I. The Multics System / MA, M.I.T Press, 1972.
  2. Silberschatz A. Applied Operating System Concepts / Wiley, 2000
  3. Switzer R.W. Operating System, A. Practical Approach /London: Prenitce Hall Int, 1993.
  4. Таненбаум Э. Операционные системы: разработка и реализация. Классика CS / Питер, 2006. – 576 с.