Наследование является одним из величайших свойств ООП, если оно используется правильно.
«Подкласс» во всех хороших ОО-проектах должен подчиняться простому правилу: является ли ребенок ВИДОМ родительского? В ООП литературе это обычно называют отношениями "есть".
И что еще более важно: ребенок всегда должен делать две вещи: специализировать общее поведение или расширять функциональность отца. Я считаю это запахом кода, когда подкласс не делает ни того, ни другого.
Тем не менее, ваше решение не имеет ничего общего с Qt или с тем, что программно лучше или хуже. Это должно иметь смысл.
Пример: если у вас был QLabel, который должен был показывать счет в игре, и только это, было бы неплохо сделать что-то вроде
class MyScoreBoard : public QLabel
{
private:
int scoreP1;
int scoreP2;
Game *_g;
public:
MyScoreBoard(QWidget *parent = 0) :
QLabel(parent)
{
scoreP1 = 0;
scoreP2 = 0;
connect(_g, SIGNAL(scoreChanged(int,int)), this, SLOT(updateScore(int,int)));
}
public slot:
updateScore(int a, int b) {
scoreP1 = a;
scoreP2 = b;
this->setText(QString::number(scoreP1) + "x" + QString::number(scoreP2));
};
};
С другой стороны, если на вашем табло было несколько огней, которые должны мигать всякий раз, когда счет изменился, если у него был один ярлык для каждого игрока, который должен был менять свой цвет в зависимости от счета, то он было бы лучше создать класс ScoreBoard, который имел бы две метки, имел бы две подсветки, а затем реализовать предполагаемое поведение.
Итог: наследовать, если это имеет смысл в вашем дизайне
В Википедии есть хорошая небольшая статья об анти-паттерне, который появляется, когда наследование используется без заботы.