Такой вопрос: как истинные джедаи реализуют сабж? Скажем, конкретный случай: системный монитор, меряем кучу разных параметров в десятке-другом потоков, выводим результаты на двадцать разных вкладок программы, на сотню разных лейблов.
Собственно, задача решена, но, подозреваю, что "не по понятиям": создана... структура, с количеством элементов = количество окон для вывода инфы, затем через enum созданы определения-константы — номера (индексы) в этой структуре, и, собственно, в потоках используется что-то типа SetWindowText (StructWindowInfo[LABEL_CPU].hWnd, CurrentCpuInfo);
Т.е. в потоках используются константы — которые определяют, какой поток с какими окнами работает... Это при том... что, вроде, так делать нельзя — из "не главного потока" обращаться к окну, созданному "главным потоком"... Хотя... SetWindowText преобразуется в SendMessage, а это вроде законно... Плюс, сейчас задача — только вывод инфы из потоков. А если надо будет как-то управлять потоками — тогда все сильно усложнится....
Говоря вообще, осознаю свои пробелы в области... это называется "проектирование архитектуры", да? Может, кто посоветует литературу на эту тему?
Здравствуйте, Аноним, Вы писали:
А>Такой вопрос: как истинные джедаи реализуют сабж? Скажем, конкретный случай: системный монитор, меряем кучу разных параметров в десятке-другом потоков, выводим результаты на двадцать разных вкладок программы, на сотню разных лейблов.
Я обычно поступаю так: выношу весь GUI в отдельный поток и передаю ему данные от других (рабочих) потоков через очередь сообщений. Очередь сообщений реализую самостоятельно. Она напоминает виндовскую очередь. Рабочие и GUI потоки взаимодействую только посредством асинхронных сообщений.
Вычислительные потоки не должны ничего знать о GUI, потому что loose coupling, single responsibility principle и т.п. Вычислительные потоки изменяют некоторые данные, изменение которых должен отобразить GUI, потому делается так: при изменении своего состояния объект данных (или некоторый его wrapper, к примеру в MVC — models), который явлются издателем в рамках шаблона проектирования Observer, шлет событие, на которое подписаны заинтересованные GUI-классы (в MVC — views), а также по необходимости другие взаимосвязанные с первым фоновые вычислительные потоки. Одно но... оповещение придется синхронизировать с GUI-событиями. В итоге, потоки не знают о GUI, GUI не знает о потоках, объекты данных не знают ни о ком — а все работает. И изменение в такой design code внести просто: так как сущности слабо связаны, их можно изменять автономно, придерживаясь только установленного ранее контракта взаимодействия.
