Мысли об MFC
От: AlexGin Беларусь  
Дата: 28.04.17 17:04
Оценка: 3 (2) +5
Всё приведенное ниже, это лично мои соображения по самой библиотеке MFC и по поводу места данного продукта в современном мире
Кроме того, здесь: http://rsdn.org/forum/cpp.qt/6769008.1
Автор: MasterZiv
Дата: 27.04.17
— я обещал товарищу MasterZiv вернуться к теме
обсуждения MFC (только уже в данном разделе, а не в разделе по Qt).

Я начал заниматься на MFC в 1999 году. Точнее скажу, что это была первая освоенная мной библиотека классов.
После неё было: Borland C++ Builder (VCL); .NET (C#) и, наконец, Qt. Посему — вроде как есть с чем сравнить.
Впрочем — сравнивать C# и MFC как-то нелогично (разные базовые языки), поэтому оставим только то, что на C++
Попутно замечу, что для некоторых проектов я применяю MFC и на сегодняшний день.

ДОСТОИНСТВА:
1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)
надстройка над WIN API, то она весит совсем не много. По современным меркам — практически ничего.

2) Интуитивная ясность библиотеки MFC для разработчиков, владеющих WIN API. Библиотека классов MFC представляет
набор классов и методов для тех сущностей, которые составляют основу оконного интерфейса Windows, что упрощает
понимание сущностей, определенных в библиотеке MFC.

3) Большой объем наработок — как в интернете (codeguru, codeproject и т.д.), так и в старых репозиториях разработчиков,
посему — возможность быстро получить ответ (в т.ч. и здесь — на КЫВТе) по самым различным аспектам применения.

4) За счёт простоты, благодаря наличию исходников и уже указанным наработкам — большая кастомизируемость
(возможность сделать то, что хочет левая пятка Заказчика).

5) Следует отметить, что MFC развивается (правда экстенсивно) — MFC Feature Pack позволает разрабатывать
приложения с довольно современным GUI. Тот факт, что в оставку MSVC2015 вернули MBCS — Multi Byte Character Set
(которую уже выбросили из MSVC2013) — также несомненно свидетельствует о некоторой популярности MFC в наши дни.

НЕДОСТАТКИ (как всегда — обратная сторона достоинств):
a) Достаточно простые на сегодняшний день вещи, оказывается сделать совсем не просто. Конечно, если работал с MFC
долгие годы, то выход найдёшь. Но это уже совсем другая история
Так, например, ComboBox в составе тулбара: в Qt несколько строк; на MFC — куча кода
Ладно, оставим GUI. Посмотрим в сторону поддержки популярных СУБД. Однако, тут картина и того хуже. Если VCL и Qt
имеют приличную поддержку СУБД, то для MFC — приходится искать и приспосабливать разные костылики, чтобы
выполнить совсем не сложный SQL запрос.

b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC. Программируя на MFC, разработчик
всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
техническими сущностями.

c) Перенос готового класса из старого в новый проект — это для MFC также пляска с бубном!
Если я хочу перенести окно (в смысле — наследник CWnd), то пеернести файлы заголовочника (*.h) и исходника (*.cpp)
оказывается явно недостаточно. Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками
переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!

d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.
Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую
тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах —
напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View

e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.
Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP
Это решение в стиле старого доброго ANSI C, но никак не в стиле современного C++
Если я в диалоговое окно (средствами студии) добавляю новый контрол, то этот новый member класса...
... с какого-то перепугу объявляется как public — вместо private (или на худой конец protected).
Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет
отступление от идей нормального объектно-ориентированного дизайна.

Я прекрасно понимаю, что есть требования совместимости со старым кодом, но ведь могли же ввести, наряду с поддержкой старого, и какие-либо
новые варианты — соответствующие сегодняшнему уровню развития технологий...
Или же M$ уже собралась хоронить MFC

Вывод: применение MFC на сегодняшний день имеет смысл в простых проектах, где важна именно легкость.
Нередко это просто диалоговое окно со статически прилинкованной библиотекой MFC.
Для более сложных проектов — очевиден выбор Qt.
Для старых проектов, где этому MFC сто лет, и нет возможности/финансов перейти на что-то новое, также актуально применение MFC.

Благодарю всех, у кого хватило терпения дочитать до этой строчки!
И еще более благодарю тех, кто выразит свои мысли по данному поводу!
Отредактировано 28.04.2017 17:51 AlexGin . Предыдущая версия . Еще …
Отредактировано 28.04.2017 17:43 AlexGin . Предыдущая версия .
Отредактировано 28.04.2017 17:10 AlexGin . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.