QT: Это хорошая идея, чтобы основывать мои доменные объекты на QObject?

Question

Я довольно новичок в использовании инфраструктуры QT в сочетании с C ++. Мне было интересно: это хорошая идея, чтобы мои классы доменов основывались на QObject? Или я должен делать это только для классов выше в иерархии? (ближе к уровню пользовательского интерфейса). Документация QT не ясна по этому вопросу:

Взято из документации QT:

Мета-объектная система представляет собой расширение C ++, которое делает язык более подходящим для программирования компонентов с истинным компонентом.

Очевидно, что я хочу создать свое приложение хорошо структурированным способом. В течение последних нескольких дней я просматривал документацию по QT, чтобы найти ответ на этот вопрос. Я не хочу совершать элементарную ошибку, которая сделает мое приложение бессильным на всю вечность; -).

Я уже посмотрел основную документацию по QObject и модели объектов Qt. Я также нашел статью freshmeat , которая помогла, но не помогла мне прийти к выводу. Что-то еще, что смущает меня, - то, что сам QT, кажется, не последовательн в этом вопросе, потому что не все классы QT используют QObject в качестве базового класса.

Преимущества использования QObject в качестве базового класса, как я их вижу:

• Иерархия
• Сигналы и слоты
• Свойства
• Возможность использовать охраняемые указатели
• Интернационализация

Однако в большинстве классов моего домена мне не нужны эти функции. Есть ли для этого правило лучшей практики? Или должно быть правило: используйте его, если вам требуется какой-либо из пунктов, упомянутых выше?

Надеюсь, это меня не смутило: -)

Answer 1

В общем, если нет «неотложных потребностей», вам лучше оставить классы вашего домена «ванильными».Это дает вам наибольшую гибкость в будущем (например, повторное использование их в среде без Qt).

Answer 2

Есть веская причина не наследовать без необходимости QObject, и это прямо в документации .

Нет конструктора копирования или оператора присваивания

QObject не имеет ни конструктора копирования ни оператор присваивания. [...]

Основным следствием является то, что вы следует использовать указатели на QObject (или ваш подкласс QObject), где вы могли бы в противном случае соблазн использовать Подкласс QObject как значение. За Например, без конструктора копирования, вы не можете использовать подкласс QObject как значение, которое будет храниться в одном из контейнерные классы. Вы должны хранить указатели.

Answer 3

Эта проблема не так велика, как вы думаете.Это действительно не имеет большого значения.Я бы сказал, если вы это сделаете или нет, на самом деле все будет по-другому.Так что, как правило, не просто чтобы все упростить.Однако, если вам нужны сигнальные слоты или что-либо реализованное Qt, продолжайте, это все равно не будет стоить так много.

Answer 4

«Используйте его, если вам требуется какой-либо из пунктов, упомянутых выше» - сложно сказать лучше. Нет причин добавлять ненужные функциональные возможности в каждый класс. Подумайте также о классах, определенных в разделяемых библиотеках: они могут использоваться не-Qt-клиентами, если вы не выводите их из QObject.

Answer 5

Я учусь (читаю документ), но еще не начал использовать Qt, вот мое мнение по вашему вопросу.Всегда хорошо иметь один корневой объект (CObject в MFC, TObject в VCL), поэтому определите свой собственный корневой объект, такой как YourOwnRootObject.Если вы считаете, что вам больше всего нужен QObject, сделайте YourOwnRootObject наследуемым от QObject, в противном случае оставьте YourOwnRootObject в покое, пока вам не понадобится QObject.

Answer 6

Я бы почти хотел ответить на вопрос, противоположный вашему, это не плохая идея.Должны ли они быть QObjects, зависит от ваших потребностей.Для меня возможность использовать свойства и отражения почти стоит больше, чем сигнал и слоты.QMetaObject может быть очень полезным для гибких стратегий программирования