Какую архитектуру выбрать для программы на Qt? Добрый день! Подскажите какую архитектуру приложения лучше использовать. Есть задача - написать ПО для управления железкой по COM-порту. Несколькими железками. Для этого загружается конфиг, где описаны ID железок и их возможности и доступные параметры. Из этого конфига динамически загружается нужное количество крутилок и прочих элементов управления, там же указаны делители для значений параметров (железо выдает целые числа, а в реале это 0.1 или 0.01 доли реальных физических величин и программа зная делители переводит в нормальный вид). Есть несколько дополнительных окошек и менюшек, но в целом основная часть взаимодействия пользователя происходит в основном окне.
Для парсинга создал отдельный объект. Для экспорта настроек и импорта - отдельный. Отдельный объект-обёртка (QSerialPort) для ком-порта и т.д. Сейчас все эти объекты создаются внутри класса главного окна, а данные из конфига парсятся в большую структуру, которая по ссылке передаётся различным объектам, которые заполняют её (парсер) или читают данные из неё. Мне такой подход выглядит чайниковым (опыт в ООП у меня небольшой). Прошу совета у вас и поделиться опытом, мнением. Раньше много прогал железа на Си, хочу перестать писать вот такой вот С++ плюс Си код:)) Перейти больше к канонам ООП.
1. Нормально ли создавать все эти объекты и обеспечивать связь между ними в классе главного окна?? В принципе, очень много данных используется и преобразуется именно для вывода в этом окне, и в целом это удобно, нежели делать "миллион" сигнал-слотов и рулить это всё в main() вне класса главного окна.
2. Как "по-хорошему" делать передачу конфига от парсера другим объектам? Через get-теры? или допустимо и вот так вот по ссылке?
Также буду рад услышать и другие советы в тему. Благодарю!
п.с. может какую литературу посоветуете по проектированию на ООП?
Какую архитектуру выбрать для программы на Qt? Добрый день! Подскажите какую архитектуру приложения лучше использовать. Есть задача - написать ПО для управления железкой по COM-порту. Несколькими железками. Для этого загружается конфиг, где описаны ID железок и их возможности и доступные параметры. Из этого конфига динамически загружается нужное количество крутилок и прочих элементов управления, там же указаны делители для значений параметров (железо выдает целые числа, а в реале это 0.1 или 0.01 доли реальных физических величин и программа зная делители переводит в нормальный вид). Есть несколько дополнительных окошек и менюшек, но в целом основная часть взаимодействия пользователя происходит в основном окне.
Для парсинга создал отдельный объект. Для экспорта настроек и импорта - отдельный. Отдельный объект-обёртка (QSerialPort) для ком-порта и т.д. Сейчас все эти объекты создаются внутри класса главного окна, а данные из конфига парсятся в большую структуру, которая по ссылке передаётся различным объектам, которые заполняют её (парсер) или читают данные из неё. Мне такой подход выглядит чайниковым (опыт в ООП у меня небольшой). Прошу совета у вас и поделиться опытом, мнением. Раньше много прогал железа на Си, хочу перестать писать вот такой вот С++ плюс Си код:)) Перейти больше к канонам ООП.
1. Нормально ли создавать все эти объекты и обеспечивать связь между ними в классе главного окна?? В принципе, очень много данных используется и преобразуется именно для вывода в этом окне, и в целом это удобно, нежели делать "миллион" сигнал-слотов и рулить это всё в main() вне класса главного окна.
2. Как "по-хорошему" делать передачу конфига от парсера другим объектам? Через get-теры? или допустимо и вот так вот по ссылке?
Также буду рад услышать и другие советы в тему. Благодарю!
п.с. может какую литературу посоветуете по проектированию на ООП?
Для парсинга создал отдельный объект. Для экспорта настроек и импорта - отдельный. Отдельный объект-обёртка (QSerialPort) для ком-порта и т.д. Сейчас все эти объекты создаются внутри класса главного окна, а данные из конфига парсятся в большую структуру, которая по ссылке передаётся различным объектам, которые заполняют её (парсер) или читают данные из неё. Мне такой подход выглядит чайниковым (опыт в ООП у меня небольшой). Прошу совета у вас и поделиться опытом, мнением. Раньше много прогал железа на Си, хочу перестать писать вот такой вот С++ плюс Си код:)) Перейти больше к канонам ООП.
1. Нормально ли создавать все эти объекты и обеспечивать связь между ними в классе главного окна?? В принципе, очень много данных используется и преобразуется именно для вывода в этом окне, и в целом это удобно, нежели делать "миллион" сигнал-слотов и рулить это всё в main() вне класса главного окна.
2. Как "по-хорошему" делать передачу конфига от парсера другим объектам? Через get-теры? или допустимо и вот так вот по ссылке?
Также буду рад услышать и другие советы в тему. Благодарю!
п.с. может какую литературу посоветуете по проектированию на ООП?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Для программы на Qt, которая взаимодействует с несколькими железками через COM-порт, лучше всего выбрать архитектуру Model-View-Controller (MVC).
Нормально создавать все эти объекты и обеспечивать связь между ними в классе главного окна. В рамках архитектуры MVC, класс главного окна будет играть роль контроллера, который управляет моделью (объектами для работы с конфигом, COM-портом и т.д.) и отображением (видом). Это позволит разделить логику работы приложения от отображения данных пользователю и упростит поддержку и расширение программы.
Передачу конфига от парсера другим объектам лучше всего делать через сеттеры или конструкторы объектов. Использование ссылок тоже может быть допустимо, но это может сделать код менее читаемым и увеличить сложность управления памятью.
Для дополнительного изучения ООП и проектирования программ на нем, могу порекомендовать книгу "Чистый код. Создание, анализ и рефакторинг" Роберта Мартина. Эта книга содержит много полезных советов по написанию чистого, структурированного и эффективного кода, а также об основных принципах ООП.
С учетом вашего опыта и желания перейти к более каноническому ООП, рекомендую также изучить принципы SOLID (S - Single responsibility, O - Open/closed, L - Liskov Substitution, I - Interface segregation, D - Dependency Inversion). Эти принципы помогут вам разрабатывать более гибкие и поддерживаемые программы.