Информация об изменениях

Сообщение Re[2]: Мысли об MFC от 03.05.2017 16:46

Изменено 03.05.2017 17:04 AlexGin

Re[2]: Мысли об MFC
Здравствуйте, уважаемый MasterZiv, Вы писали:

MZ>Ну, тогда не могу не поучаствовать в топике

Рад приветствовать, уважаемый MasterZiv

AG>1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)


MZ>Ну, очень удивительно слышать такое, но я тебя понимаю. В смысле, я бы сказал так же, но многие разработчики это не

MZ>понимают. Для многих MFC -- это огромный и страшный монстр.
Стараюсь быть объективным. Это скорее маленькая рабочая лошадка

AG> Ладно, оставим GUI. Посмотрим в сторону поддержки популярных СУБД. Однако, тут картина и того хуже. Если VCL и Qt

AG> имеют приличную поддержку СУБД, то для MFC — приходится искать и приспосабливать разные костылики, чтобы
AG> выполнить совсем не сложный SQL запрос.

MZ>Да нужно просто сразу сказать, что в MFC поддержки программирования с СУБД просто нет. То лихое поделие, что

MZ>туда вставили во времена 6.0 годится только для галочки в маркетинговых статьях.
+100500

AG>b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC.

MZ>Не согласен. Очень зависит от того, какой проект, какой код, как написан и т.п.
MZ>Например, мой лично код на MFC всегда был конфеткой...
Всё дело в том, что на MFC очень много чего лишнего приходится делать руками.
Пример: ProgressBar или ComboBox в составе ToolBar-a головного окна (для проекта MFC Feature Pack) — для MFC куча всякого кода,
дополнительные классы с переопределёнными вирт-методами и т.д.
То же самое для Qt — несколько скромных (весьма простых) строчек кода.

AG>Программируя на MFC, разработчик

AG>всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
AG>Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
AG>Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
AG>техническими сущностями.
MZ>Не согласен. Очень сильно не согласен.
Насчёт документ/вид — вопрос: почему ТЕ ЖЕ ЛЮДИ не оставили эту идею в .NET?
Ведь ни в WinForms, ни в WPF этой навязчивой идеи Doc/View не наблюдается.
Теперь DoDataExchange и прочие низкоуровневые штуковины: все они уходят корнями в стрый добрый WinAPI.
Они уходят корнями туда, даже в тех случаях, когда вроде как нет аналогичной глобальной апи-шной функции (абсолютного аналога).
Да, для конца 1990-х и начала 2000-х это было шикарно. Однако, на сегодняшний день это уже не так...

AG> Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками

AG> переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
AG> просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
AG> В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!

MZ>Ну, ресурсы -- это отдельная тема и собственно с MFC или QT оно слабо связано.

Организация 'виджетов' в Qt кардинально отличается от WinAPI — отсюда ИМХО и "ноги растут".
MZ>Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.
Если в солюшене порядка 50-ти проектов, это уже превращается в некоторый гемморой

AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.

MZ>Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
MZ>Странная логика...
Model/View для Qt — это совсем другое, идеология Model/View для Qt — это вариант развития, он ненавязчив, в отличии от Doc/View для MFC
Пример: в MFC Doc/View навязан всегда (для MDI и даже для SDI конструкции), при этом он не связан с каким либо паттерном проектирования — он
просто представляет собой атавизм, актуальный разве что для текстовых редакторов
Для Qt — Model/View это вариант архитектуры проекта (он помогает согласовать изменение данных для паттерна MVC в проекте) —
в самом простом случае можно обойтись и без него, создав полноценное (SDI,MDI,диалоговое) приложение с современным GUI.

MZ>Вот MDI архаичен, вот это -- да, на 100%, и очень плохо, что эта архитектура фреймов врезана в самый что ни на есть

MZ>позвоночник MFC. Вот это -- реально очень плохо и негибко.

AG>e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.

AG> Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP

MZ>Это не Observer

Просто одна из его (не весьма удачных) реализаций. Скажу так — Observer, но изуродованный до неузнаваемости

MZ>Observer -- это как раз Doc/View...

Где там отсылка сообщений? Где подписывание на сообщения? ...натягиваем сову на глобус...

AG> Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет

AG> отступление от идей нормального объектно-ориентированного дизайна.

MZ>В общем, у тебя привратное, однобокое представление об ООП, так что, ну, можно конечно тебя послушать на эту тему, но

MZ>это не интересно. MFC -- это самый что ни на есть ООП.

Моё представление об ООП сформировалось из анализа тех решений, что есть прежде всего в .NET.
Но даже в современном C++, эти решения уже ушли от того, что принято в MFC (ушли далекооо).

MZ>Код MFC тем не менее достаточно архаичен, там почти не используются шаблоны и generic programming, там не испльзуется STL,

MZ>и ещё много чего.
+100500

MZ>Да нет же, всё не так. Если нужно программирование desktop UI под Windows, то фактически альтернативы MFC как не было, так и нет.


Ну давай смотреть, какие есть альтернативы и для чего:
1) .NET
1.1. WindowsForms
1.2. WPF
2) Qt;
3) Java (да, несколько не нативно, н отем не менее).
MZ>Не зависимо от сложности проекта. Дело в другом, что и UI только под Win уже мало кто хочет, и вообще Desktop мало кто хочет.
В определенной нише — много (очень много) кто хочет!
MZ>Вот в таких условиях MFC точно пасует. Не потянет.
Конечно же, документооборот теперь почти весь на Web-е (что-то есть на .NET-е и Java); а большая ниша технических desktop проектов — на Qt.

В общем — дискуссии нашей пора в КСВ
Re[2]: Мысли об MFC
Здравствуйте, уважаемый MasterZiv, Вы писали:

MZ>Ну, тогда не могу не поучаствовать в топике

Рад приветствовать, уважаемый MasterZiv

AG>1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)


MZ>Ну, очень удивительно слышать такое, но я тебя понимаю. В смысле, я бы сказал так же, но многие разработчики это не

MZ>понимают. Для многих MFC -- это огромный и страшный монстр.
Стараюсь быть объективным. Это скорее маленькая рабочая лошадка

AG>b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC.

MZ>Не согласен. Очень зависит от того, какой проект, какой код, как написан и т.п.
MZ>Например, мой лично код на MFC всегда был конфеткой...

Всё дело в том, что на MFC очень много чего лишнего приходится делать руками.
Пример: ProgressBar или ComboBox в составе ToolBar-a головного окна (для проекта MFC Feature Pack) — для MFC куча всякого кода,
дополнительные классы с переопределёнными вирт-методами и т.д.
То же самое для Qt — несколько скромных (весьма простых) строчек кода.
Замечу, что здесь не следует воспринимать что-либо как обиду (не наезжаю я на твой код), просто констатирую очевидный факт для MFC.

AG>Программируя на MFC, разработчик

AG>всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
AG>Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
AG>Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
AG>техническими сущностями.
MZ>Не согласен. Очень сильно не согласен.

Мне, почему-то не примпомнится аналог DoDataExchange для WindowsForms.
Значит всё-таки что-то в консерватории (в M$) подправили...

Насчёт документ/вид — вопрос: почему ТЕ ЖЕ ЛЮДИ не оставили эту идею в .NET?
Ведь ни в WinForms, ни в WPF этой навязчивой идеи Doc/View не наблюдается.
В ASP.NET MVC — приняты совсем иные идеи, которые куда более перспективны, нежели документ/вид...

Теперь DoDataExchange и прочие низкоуровневые штуковины: все они уходят корнями в стрый добрый WinAPI.
Они уходят корнями туда, даже в тех случаях, когда вроде как нет аналогичной глобальной апи-шной функции (абсолютного аналога).
Да, для конца 1990-х и начала 2000-х это было шикарно. Однако, на сегодняшний день это уже не так.

AG> Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками

AG> переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
AG> просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
AG> В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!

MZ>Ну, ресурсы -- это отдельная тема и собственно с MFC или QT оно слабо связано.

Организация 'виджетов' в Qt кардинально отличается от WinAPI — отсюда ИМХО и "ноги растут".
MZ>Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.
Если в солюшене порядка 50-ти проектов, это уже превращается в нехилый геморой

AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.

MZ>Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
MZ>Странная логика...
Model/View для Qt — это совсем другое, идеология Model/View для Qt — это вариант развития, он ненавязчив, в отличии от Doc/View для MFC
Пример: в MFC Doc/View навязан всегда (для MDI и даже для SDI конструкции), при этом он не связан с каким либо паттерном проектирования — он
просто представляет собой атавизм, актуальный разве что для текстовых редакторов
Для Qt — Model/View это вариант архитектуры проекта (он помогает согласовать изменение данных для паттерна MVC в проекте) —
в самом простом случае можно обойтись и без него, создав полноценное (SDI,MDI,диалоговое) приложение с современным GUI.

MZ>Вот MDI архаичен, вот это -- да, на 100%, и очень плохо, что эта архитектура фреймов врезана в самый что ни на есть

MZ>позвоночник MFC. Вот это -- реально очень плохо и негибко.
MDI иногда позволяет решить проблему, а иногда создаёт проблемы — всё зависит от проекта.

AG>e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.

AG> Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP

MZ>Это не Observer

Просто одна из его (не весьма удачных) реализаций. Скажу так — Observer, но изуродованный до неузнаваемости

MZ>Observer -- это как раз Doc/View...

Где там отсылка сообщений? Где подписывание на сообщения? ...натягиваем сову на глобус...

AG> Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет

AG> отступление от идей нормального объектно-ориентированного дизайна.

MZ>В общем, у тебя привратное, однобокое представление об ООП, так что, ну, можно конечно тебя послушать на эту тему, но

MZ>это не интересно. MFC -- это самый что ни на есть ООП.

Моё представление об ООП сформировалось из анализа тех решений, что есть в современных ЯВУ и прежде всего в .NET.
Но даже в современном C++, эти решения уже ушли от того, что принято в MFC (ушли далекооо).

MZ>Код MFC тем не менее достаточно архаичен, там почти не используются шаблоны и generic programming, там не испльзуется STL,

MZ>и ещё много чего.
+100500
Похоже, что MFC появился до внедрения STL — вот и объяснение.

MZ>Да нет же, всё не так. Если нужно программирование desktop UI под Windows, то фактически альтернативы MFC как не было, так и нет.


Ну давай смотреть, какие есть альтернативы и для чего:
1) .NET
1.1. WindowsForms
1.2. WPF
2) Qt;
3) Java (да, несколько не нативно, н отем не менее).
MZ>Не зависимо от сложности проекта. Дело в другом, что и UI только под Win уже мало кто хочет, и вообще Desktop мало кто хочет.
В определенной нише — много (очень много) кто хочет!
MZ>Вот в таких условиях MFC точно пасует. Не потянет.
Конечно же, документооборот теперь почти весь на Web-е (что-то есть на .NET-е и Java); а большая ниша технических desktop проектов — на Qt.

В общем — дискуссии нашей пора в КСВ