Какие последствия имеет многопоточность для архитектуры настольного приложения?

Я пишу многопоточное настольное приложение.

Обычно

я не уверен в том, какое влияние многопоточность оказывает на архитектуру. По архитектуре существует много литературы, но я не знаю ни одной, которая учитывала бы многопоточность. Существует много литературы о низкоуровневых материалах многопоточности (мьютексы, семафоры и т. Д.).

1. использует ApplicationKernel для создания объекта File ,
2. использует ApplicationPresentation для создания объекта FilePresentation ,
3. ] создает объект FileController , передавая File и FilePresentation конструктору.

Допустим, File обеспечивает длительную операцию Init () , которая не должна блокировать пользователя интерфейс. Мне пришло в голову два подхода:

1. File :: Init () возвращает объект, который инкапсулирует поток и может использоваться для регистрации наблюдателя, который получает уведомление о прогрессе, ошибках, завершении и т. Д. Это возлагает большую ответственность на FileController (кто бы быть наблюдателем), потому что теперь к нему обращаются как из основного, так и из рабочего потока.
2. Полностью скрыть рабочий поток от контроллера . File :: Init () ничего не вернет, но ApplicationKernel будет сигнализировать о создании, ходе и ошибках длительных операций в основном потоке. Это затянуло бы много коммуникаций через ApplicationKernel , превратив его в нечто вроде божественного объекта.

Какой из этих двух является общим подходом к многопоточности в настольном приложении (если есть)? Какие альтернативные подходы вы порекомендуете?