Как программировать и как не программировать
Библиотека классов MFC является вредной для программиста
Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании Reliable Software


--------------------------------------------------------------------------------

Программирование для Windows считается трудным. Библиотеки классов делают программирование для Windows легче. Это истина или ложь?

bool IsWinProgEasier (Method method) {
if (method == WIN_CLASS_LIBRARIES) return false;
else return true;
}

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

Позвольте привести аналогию. Представьте, что вы покупаете набор Lego блоков. Вы можете купить универсальный набор, или специализированный набор для построения пиратского судна. Если все, что Вы хотите сделать, это создать пиратское судно, то второй вариант предпочтительнее. Но если Вы вдруг попробуете попробуете сделать из него Lego автомобиль, то Вам придется преодолеть несколько проблем. В конечном счете вы придумаете нечто, похожее на автомобиль, который будет иметь забавное колесо управления, использовать якорь для торможения, а водитель будет иметь деревянную культю и черную повязку на его глазе.

После работы с этим набором "пиратского" Лего в течении некоторого времени, Вы станете специалистом в формировании почти всего того, что могло бы быть сделано из универсального комплекта. Вы усвоите разные приемы, подобно тому, как удалить заплату с глаза пирата, как закрасить череп и кости и т.д. В конечном счете вы достигнете таких высот, когда количество знания, которое вы ассимилировали относительно Пиратского набора, будет намного больше, чем базисные принципы и техника, которые вы должны были бы узнать, чтобы использовать универсальный Lego. С той вершины вы будете выбрасывать большие деньги после первых малых затрат, вкладывая капитал во все более сложные (и сложные) Пиратские наборы.

Что же Вам делать? Мой совет: накоротко урезать ваши потери, начав сейчас же изучать программирование для Windows. API Windows - не является красивой или простой вещью. Именно поэтому все эти библиотеки классов стали настолько популярными в первое время. Но если Вы хотите выращивать красивые цветы, вам необходимо будет испачкать ваши руки. Объектное программирование и Windows далеки друг от друга, но я не хочу, чтобы Вы повторно изобретали колесо. Имеются некоторые простые OO методы, которые помогут Вам инкапсулировать уродливое лицо Windows API.

Побочный эффект окажется то, что вы будете способны создавать Windows программы, которые являются достаточно малыми, чтобы быть легко загружаемыми из Интернета. Малые программы загружаются очень быстро - они не нуждаются в чем-либо, имеющемся в MFC dll библиотеках. Я спорю с любым MFC энтузиастом, что он не напишет игру "Морской бой", которая будет меньше по размеру, чем наша, и будет обладать теми же функциональным возможностям.

Давайте же начнем наш просмотр Win32 API с самой простой возможной Windows программы ... Hello Windows!.


--------------------------------------------------------------------------------

Имеется превосходная статья Элен Ульман (Ellen Ullman), которае должна быть рекомендована для чтения каждому, кто все еще чувствует позывы к использованию MFC или OWL. Она доступно интерактивно:

Часть 1
Часть 2
или, в печатном виде, в августовском издании журнала Харпера за 1998 год. Предлагаем Вам несколько цитат:

"... В этом мире программирования, написание моего кода перемещалось с акцента на задачу, в сторону становления набором придатков к архитектуре системы, выстроенной Microsoft."

"... Для чего изучать весь сложный код, который волшебники генерируют для меня, если он и так всегда работает?"

"... Искушение никогда не знать, что лежит в основе той легкости, подобно ослабляющей пассивности телевидения. Успокаивающая пустота, когда театр темен. Как приятно ощущать себя потребителем! (подчеркнуто мной. А.Л.)"


--------------------------------------------------------------------------------

Если вы - энтузиаст объектно-ориентированного программирования, то найдете это цитирование официальных Руководящих принципов MFC для написания расширений библиотеки классов довольно забавным.

Ограничьте использование "Private" в Ваших классах. Это необходимо, чтобы пользователи, были способны использовать разработанные Вами MFC-дружественные классы способами, которые Вы могли бы первоначально не предусмотреть. Храня большую часть методов, элементов данных, и общих операторов публично, Вы допускаете гибкость в их использовании. В MFC, даже функции, объявленные в разделе Реализации класса обычно общие (public) или защищенные (protected).

--------------------------------------------------------------------------------

Рекомендуемая литература:

Brent E. Rector, Joseph M. Newcomer. Win32 Programming. Addison-Wesley
Очень полное и детализированное представление Win32 API. Превосходные ссылки.


--------------------------------------------------------------------------------

И имеется письмо от одного из наших посетителей, Дейва Линенберга ( Dave Linenberg).

Я потратил приблизительно 20 минут, просматривая ваш сайт, и действительно наслаждался вашими взглядами на программирование - особенно относительно вздутого характера MFC. Я не мог не поделиться своими наблюдениями.

Я начал писать Windows-программы, использующие API в 1991-1992 годах (обучаясь по первой книги Петцолда) ... а затем, слушая все эти разговоры об объектно ориентированном программном обеспечении, я попробовал изучать MFC. Я пролистал книгу Просиса, и проработал все упражнения. Я просмотрел пару сотен страниц исходного текста MFC, и наткнулся на большое количество неописанного наполнения. Я изучил внутреннюю организацию MFC. Я был подготовлен, чтобы действительно понять MFC ...., но я этого не смог сделать. Эта библиотека вызывала довольно сильное отвращение. MFC, которая делает простые вещи, является чрезвычайно сложной. Потратив 1 год на сырой API, и на увязку его с некоторыми хорошими объектно ориентированными парадигмами, образцами и книгами по программированию на C++, таким как книги Экела (Eckel) или Майераса (Meyers), можно получить намного больше, чем пытаться заняться MFC. Каждый думает, что написание 5 строк программы в MFC или некотором каркасе, чтобы создать окно - это лучше или проще, чем изучение API. Я согласился бы с этим в том случае, если бы каркас был полностью понят - потому что те 5 строк, сцепленные в тысячи строк программы с небольшими возможностями делают намного больше, чем маломасштабные SDI/MDI книжные примеры программ.

Почему Microsoft не может инкапсулировать библиотеки для C эффективно? К чему все эти непроизводительные затраты?

Сначала я был очарован архитектурой документ/вид. Я еще не знал то, что до этого был соответствующий "образец" (pattern). А через MFC было мое первое с ним столкновение. Поскольку мои программы стали беспорядочными циклическими зависимостями, я, реализуя парадигму документ-вид, понял, что MFC ужасна. По крайней мере, в их реализации этой идеи!! Когда-либо обратите внимание, что примеры программ очень малы в книгах. Большинство книг никогда не касается того, как реализовать взаимодействия больших наборов классов. Что было бы, если бы я имел большую программу с 1000 видами, и 1000 документами, и все они находились бы во взаимосвязи. Все передавли бы сообщения. Что, если бы это была многопотчная или распределенная программа...., Какой был бы беспорядок при использовании архитектуры документ/вид, реализованной с использованием MFC. Вот такие пироги!

Вот тут написано: "Программируйте без MFC!!"
Я могу вот что на это ответить, мне всегда было сложно создавать красивые пользовательские интерфейсы в VC++, чтобы хоть как-то облегчить мой труд, я юзаю MFC, там где интерфейс не так важен, я пользую API, но отказываться от MFC по-моему нельзя, да вы же загнётесь писать прогу, в которой есть куча всяких RichTextBox'ов, Toolbar'ов, и т.д...

Да, странная статья.
Такое впечатление, что слушаешь рекламу по телевизору.
"Представляем новую суперхренотерку. Раньше я терла хрен вручную, на руках появлялись мозоли. Но с новой суперхренотеркой все проблемы исчезли!".
Отличие только в том, что эта реклама не за, а против.
MFC далеко не ангел, но в большинстве житейских случаев позволяет эффективно решить задачу. И решать использовать MFC или нет, надо исходя из постановки конкретной задачи.
Да и кому нужно в сотый раз прописывать весь этот API-шный геморрой, когда можно спокойно (в подавляющем большинстве случаев) доверить стандартную работу MFC, а самому сосредаточиться на решение задачи.
P.S. Но знать API ой как полезно!

Цитата(Temnozor @ 01.7.2002, 14:04)

Да, странная статья. Такое впечатление, что слушаешь рекламу по телевизору. "Представляем новую суперхренотерку. Раньше я терла хрен вручную, на руках появлялись мозоли. Но с новой суперхренотеркой все проблемы исчезли!". Отличие только в том, что эта реклама не за, а против.

                                   

Золотые слова!

Писать только на MFC без API нельзя, но и обратное тоже геморой. Использую и то и то.

Цитата(Sheff @ 29.6.2002, 18:01)

мне всегда было сложно создавать красивые пользовательские интерфейсы в VC++, чтобы хоть как-то облегчить мой труд, я юзаю MFC, там где интерфейс не так важен, я пользую API, но отказываться от MFC по-моему нельзя, да вы же загнётесь писать прогу, в которой есть куча всяких RichTextBox'ов, Toolbar'ов, и т.д...

Ежели делать стандартный интерфейс, например, для работы с текстом и т.п., то можно и визардом воспользоваться. А когда надо сделать что-то не совсем стандартное, то с МФЦ писать не намного проще, чем на АПИ, единственное, что ускоряется процесс создания каркаса приложения (классы, функции и пр.). А так МФЦ - это же оболочка АПИ и особенной разницы, пожалуй, нет. Что немного удобнее - да, но, мне кажется, меньше, чем на 20%.
Если четко запланировать, что будет в вашей программе, то и на голом АПИ можно довольно быстро написать.
PS
Попробуйте RichEditCtrl разместите на диалоге. Особенной разницы от АПИ не будет, ежели захотите, чтобы RichEdit полноценно работал.
PPS
С компонентами, безусловно, все намного проще (ежели свои не создавать )

Вообще, конечно, интересный вопрос. Я и сам не могу сказать, что MFC такая замечательная библиотека.Дельфийский VCL, на мой взгляд, гораздо лучше продуман. Единственно, чего там не хватает, так это как раз документ-вид. Но я бы сказал, вопрос не только в том, что на API вам будет тяжело писать, но и в том, сколько времени у вас это займет. Хотя если честно, мне тяжело вообразить, как писать на чистом API не облекая его ни в какие классы. Тут возникает еще один вопрос, а почему нет альтернативных MFC библиотек (исключая VCL)? Или они есть, но мы оних не знаем?

А OWL?

Цитата(Fantasist @ 11.7.2002, 11:44)

Тут возникает еще один вопрос, а почему нет альтернативных MFC библиотек (исключая VCL)? Или они есть, но мы оних не знаем?

Так VCL не альтернатива, она вообще другая.
А MFC - просто оболочка API....

Я писала и на чистом API (правда очень маленькие программки) и в OWL пыталась разобраться (пока в декрет не ушла). Теперь пытаюсь осилить MFS.
Мое мнение такое:
если долго работать на API (при этом использовать методы ООП), то рано или поздно у тебя создастся своя библиотека, чем-то похожая на две перечисленные. Наверняка она будет охватывать более узкий круг вопросов, но будет ли она лучше?

Хотя меня до сих пор мучают подобные вопросы:
зачем пользоваться классом CDC, если все его функции можно реализовать, взяв HDC и используя WinAPI?

Хотя документ-вид – это круто. Была в восторге. А вот визард меня при первом взгляде привел в ужас: все работает, но как. В результате на то, что бы разобраться в этом уходит чуть ли не больше времени, чем на создание своего кода.