Какую архитектуру выбрать для программы на Qt?

Question

[Ilia Zhitenev]

Добрый день! Подскажите какую архитектуру приложения лучше использовать. Есть задача - написать ПО для управления железкой по COM-порту. Несколькими железками. Для этого загружается конфиг, где описаны ID железок и их возможности и доступные параметры. Из этого конфига динамически загружается нужное количество крутилок и прочих элементов управления, там же указаны делители для значений параметров (железо выдает целые числа, а в реале это 0.1 или 0.01 доли реальных физических величин и программа зная делители переводит в нормальный вид). Есть несколько дополнительных окошек и менюшек, но в целом основная часть взаимодействия пользователя происходит в основном окне.

Для парсинга создал отдельный объект. Для экспорта настроек и импорта - отдельный. Отдельный объект-обёртка (QSerialPort) для ком-порта и т.д. Сейчас все эти объекты создаются внутри класса главного окна, а данные из конфига парсятся в большую структуру, которая по ссылке передаётся различным объектам, которые заполняют её (парсер) или читают данные из неё. Мне такой подход выглядит чайниковым (опыт в ООП у меня небольшой). Прошу совета у вас и поделиться опытом, мнением. Раньше много прогал железа на Си, хочу перестать писать вот такой вот С++ плюс Си код:)) Перейти больше к канонам ООП.

1. Нормально ли создавать все эти объекты и обеспечивать связь между ними в классе главного окна?? В принципе, очень много данных используется и преобразуется именно для вывода в этом окне, и в целом это удобно, нежели делать "миллион" сигнал-слотов и рулить это всё в main() вне класса главного окна.
2. Как "по-хорошему" делать передачу конфига от парсера другим объектам? Через get-теры? или допустимо и вот так вот по ссылке?

Также буду рад услышать и другие советы в тему. Благодарю!

п.с. может какую литературу посоветуете по проектированию на ООП?

Answer 1

[Толстый Лорри]

Я бы посоветовал:

• Не делать главный класс окна божественным объектом. Его нужно разделить на контролы-модули с их собственной кастомной логикой, валидацией и прочим, а связать между собой - сигналами и слотами.
  
• Отделять бизнес-логику от интерфейса. Для чего использовать внедрение зависимостей и абстрактные (чисто виртуальные) классы для декларирования API.
  

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

Итог: интерфейс декомпозирован, о бизнес-логике он не знает ничего, кроме предоставленного абстрактного API. Контролы знают друг о друге только в рамках сигналов/слотов между собой и списка зависимостей своих детей. Бизнес-логика не знает ничего об интерфейсе.