Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Отвечаю в корень, потому как не хочу квотить длинный пост :-) 25.07.03 13:30 Число просмотров: 1679
Автор: amirul <Serge> Статус: The Elderman
|
Отвечу на все что вспомню
Насчет "нельзя" вводить глобальных обработчиков. Если бы этого действительно нельзя было делать, то это было бы запрещено самим языком. А раз язык разрешает - значит действительно просто "крайне нежелательно". Но! Если уж следовать одной из парадигм программирования, то следовать как можно точнее. Если хочется писать на Plain API (большинство своих программ я так и пишу - ну не люблю я MFC) - писать от начала и до конца и не смешивать. Если использовать ООП, то пытаться сделать как можно более ОО-ным.
***************
К сожалению я никогда не сталкивался с дизайн паттернами и даже не представляю себе что это такое. Изучить за пару часов до такой степени, чтобы давать советы я не смогу, поэтому здесь тебе придется решать самому.
***************
Насчет удобства броадкаст рассылки - все таки я считаю это весьма спорным. Но объяснить это вряд ли смогу. Просто весь мой опыт программирования показыает, что такие вещи всегда можно решить по-другому (если уж мы вообще решили связываться с ООП), причем малой кровью.
***************
По поводу примера со Сценой. Сцена не может быть "тупой" по определению (если она правильно спроектирована/реализована). Иначе можно предположить что и Животное может быть тупым и не уметь передвигаться (а просто дергать конечностями в приступе эпилепсии). Возможно, пример слишком упрощенный, и Сцену можно было бы раздробить еще на несколько классов, но она всегда управляет тем, что на ней происходит. И именно Сцена является диспетчером того, в какой последовательности кто ходит. Причем работает с глобальными объектами - слонами, мышами, дрессировщиками и т.д. А если Животные посходили с ума и начали двигаться хаотично, значит или так надо, или Сцена смоделирована неверно.
***************
Опасения, что ООП-шная иерархия будет трудно поддаваться изменениям несколько необоснованны. Как раз в ООП можно изменить любую часть проекта и все останется работать, если не изменять интерфейсы. Проблемы возникнут как раз с глобальными (пусть даже инкапсулированными в какой-то класс-диспетчер) обработчиками. Основной путь по которому развивались парадигмы программирования - это уменьшение количества зависимостей между частями программы. Потому как, чем их меньше, тем меньше вероятность, что программист чего-то упустит.
В этом плане непосредственные зависимости объекта-родителя с парой-тройкой своих детей гораздо выгоднее (рост количества связей линейный по отношению к количеству объектов), чем зависимость каждого объекта от диспетчера, а диспетчера от каждого объекта. В этом случае проявляется связь каждый-с-каждым (квадратичный рост зависимостей).
Это хорошо видно на примере маршрутизации TCP/IP (я приводил этот пример в одном из предыдущих постов).
****************
> На самом деле хотелось рассмотреть более общий случай, когда объектов
> достаточно много, так что выстроить их иерархию не то, чтобы трудно, а
> трудно уследить за всем по мере до_проектирования задачи.
Как раз в общем случае, чем больше объектов и чем сложнее между ними зависимости, тем проще оказывается с ними работать, когда они собраны в иерархию. Проектирование этой иерархии в общем случае выполняется задолго до того, как написана хоть одна строчка кода. Но после того, как она спроектирована - все становится почти тривиальным (и реализация, и сопровождение, и изменение). Изменение конечно же будет тривиальным, если новые требования не заставляют сломать всю иерархию, а только добавляют/удаляют ветви/листья.
****************
> В BCB++ c таб-компонентом проще. Из облати его видимости можно получить
> доступ ко всем контролам на каждой закладке, т.е. обабатывать поведение
> контролов по «ЕнаблеКонтролс» в одном методе, а не в 20-и.
Да там есть класс для страницы. Там вообще многие вещи от того, что вся форма создается только динамически, совершенно не полагаясь на ресурс типа RT_DIALOG. Я считаю это скорее недостатком, ну да ладно. В MFC тоже можно сделать выключение целой страницы, используя EnumChildWindows, причем сделать это в одном месте - в базовом классе CPage.
****************
ЗЫ: Если чего забыл - не обессудь. Я уже тоже почти потерял нить рассуждений :-)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
