QT: действительно ли это - хорошая идея основывать мои объекты области на QObject?
Я довольно плохо знаком с использованием спокойной платформы в сочетании с C++. Я задавался вопросом: действительно ли это - хорошая идея основывать мои доменные классы на QObject? Или я должен только сделать это для классов выше в иерархии? (ближе к уровню пользовательского интерфейса). Спокойная документация не является четкой на этом:
Взятый из спокойной документации:
Система метаобъекта является расширением C++, которое делает язык, лучше подходящий для истинного программирования GUI компонента.
Очевидно, я хочу создать свое приложение хорошим хорошо структурированным способом. За прошедшие несколько дней я просматривал спокойную документацию для нахождения ответа на этот вопрос. Я не хочу делать некоторую элементарную ошибку, которая сделает мою хромоту приложения для всей вечности ;-).
Я уже посмотрел на основную документацию для QObject и спокойной Объектной модели. Я также нашел freshmeat статью, которая помогла, но действительно не помогла мне сделать вывод. Что-то еще, что смущает меня, - то, что сам QT, кажется, не последователен по этому вопросу, потому что не все спокойные классы используют QObject в качестве базового класса.
Преимущества использования QObject как базовый класс, поскольку я вижу их:
- Иерархия
- Сигналы и слоты
- Свойства
- Способность использовать охраняемые указатели
- Интернационализация
Однако я не требую ни одной из этих технических возможностей в большинстве моих доменных классов. Существует ли правило наиболее успешной практики для этого? Или если правило: используйте его при требовании какой-либо из упомянутых выше точек?
Надежда я не сделал это слишком сбивающим с толку :-)
6 ответов
В общем, если нет «настоятельной необходимости», вам лучше оставить свои доменные классы «ванильными». Это дает вам наибольшую гибкость в будущем (например, повторное использование их в среде, не являющееся Qt).
"Используйте его, если вам нужен любой из пунктов, упомянутых выше" - трудно сказать лучше. Нет причин добавлять ненужную функциональность в каждый класс. Подумайте также о классах, определенных в общих библиотеках: они могут быть использованы клиентами, не относящимися к Qt, если вы не выводите их из QObject.
Я почти хотел бы ответить на ваш вопрос, противоположный вашему, это не плохая идея. Должны ли они быть QObjects , зависит от ваших потребностей. Для меня возможность использовать свойства и отражение почти стоит больше, чем сигнал и слоты. QMetaObject может быть очень полезен для гибких стратегий программирования
Эта проблема не такая «большая», как вы могли бы подумать. Это действительно не имеет большого значения. Я бы сказал, что если вы это сделаете или нет, это действительно не будет так уж и по-другому. Так что, как правило, не делайте этого, просто чтобы упростить ситуацию. Если, однако, вам нужны сигнальные слоты или что-то, что Qt реально, продолжайте, это в любом случае не стоит так уж и много.
Есть хорошая причина не наследоваться от QObject без необходимости, и она прямо там, в документации.
Нет конструктора копирования или оператора присваивания
У QObject нет ни конструктора копирования ни оператора присваивания. [...]
Основным следствием этого является то, что вы должны использовать указатели на QObject (или на ваш подкласс QObject) там, где вы могли бы иначе возникнет соблазн использовать ваш подкласс QObject в качестве значения. Для например, без конструктора копирования, вы не можете использовать подкласс QObject в качестве значения, которое будет храниться в одном из контейнерных классов. Вы должны хранить указатели.
Я учусь (читаю документ), но еще не начал использовать Qt, вот мое мнение по вашему вопросу. Всегда хорошо иметь один корневой объект (CObject в MFC, TObject в VCL), поэтому определите собственный корневой объект, например YourOwnRootObject. Если вы думаете, что вам больше всего нужен QObject, сделайте YourOwnRootObject наследованным от QObject, в противном случае оставьте YourOwnRootObject в покое, пока вам не понадобится QObject.