Спасибо, amirul, за постинг.
******************************************
>> Замечу, что объекты указанных классов (а значит и
>> соответствующие контролы) «НЕЗАВИСИМЫ» в том смысле, что
> >они почти ничего не знают друг о друге (идеология MFC).
>Нет, у MFC другая идеология. В плане абстракции данных он даже не совсем ООП, так как все >данные держит открытыми - непозволительная вольность. Я не очень люблю MFC, но совсем за >другие вещи.
A:
Я был не точен.
****************************************************
>переменные для обращения к объектам (см "Дополнение к дополнению"). Есть один глобальный >theApp. В нем можно хранить указатели на диалоги (но насколько я понял диалог один, так что >этого не надо). В эти диалоги из ClassWizard-а подобавлять переменных, через которые потом >можно будет обращаться к контролам (в частности CTabCtrl).
A:
В первом посте - один диалог для «затравки». Впрочем, я об этом уже тебе пропостил. На самом деле хотелось рассмотреть более общий случай, когда объектов достаточно много, так что выстроить их иерархию не то, чтобы трудно, а трудно уследить за всем по мере до_проектирования задачи.
Ты прав, если логика приложения не перегружена. Ну, было бы просто оболдуйством не делать так, как ты говоришь, в этом случа, и что соответствует ООП в полной мере.
Однако думаю, что хранить указатели в качестве «отдельных» приват членов CMyApp удобно в случае, если мы твёрдо стоим ТОЛЬКО на иерархической модели, не допуская «ГОРИЗОНТАЛЕЙ» ни при каких обстоятельствах, и если число объектов невелико. По существу то, что мы храним – это рут-листья.
Если же, например, в CMyApp хранить список указателей, то вызов части методов этих объектов можно упростить за счёт широковещательной рассылки соответствующей мессаги. Как ни крути, использование медиаторов, не медиаторов, рассылка сообщений или вызов виртуальных методов бродкастом – это будет «горизонталь». Почему не использовать, если удобно, объясни?
****************************************************
> xxx.FillControls(UM_STARTUP);
> xxx.DisplayControls(UM_STARTUP);
Я кстати не совсем понял, зачем эти две функции разделены, если они всегда идут парой.
A:
Скорее стереотип, чем необходимость. Как мне кажется - удобно для разделения логики получения данных, от логики их отображения. Разделение - косметическое, чтобы функции, ответственные за отображение, не маячили перед глазами, когда занят работой с данными. Началось присутствие твин-пикс давно, когда ещё только появились винды 2.0. Тогда не только программирование для вин, но и сами винды многие считали извратом. Стех времён тащу это. Инерция.
****************************************************
>>Мой вариант:
>>// стартуем приложение MFC VC++
и далее…
Да, стильно. Нет вопросов, если можно обойтись только одним объектом для хранения указателей на объекты, виртуальные методы которых будет вызывать одноименный метод theApp.
****************************************************
>>Я же говорю. С CPage-ами надо поступать проще:
>>class CPage: public CDialog {
…
>>public:
>>virtual void OnStartup() = 0;
>>virtual void OnRead() = 0;
>>virtual void OnEdit() = 0;
>>// ...
>>}
Ясно… Правильная обработка;))).
>>Вот поэтому, нужно чтоб объект делал только то что знает как делать точно. То бишь >>приложение переводит в новое состояние своих детей, диалог - своих, а страницы просто >>переводят контролы в нужное состояние. А использование виртуальных функций при этом >>помогает отделить интерфейс от реализации.
Ну что здесь скажешь, кроме да.
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
