Qt - diseño correcto del código de aplicación

Question

Me resultó difícil buscar un tema relacionado, así que esta es mi pregunta. Empecé a usar Qt hace dos días y, por lo tanto, no tengo ni idea de cómo hacerlo funcionar (en el lado del código).

[offtopic] Aquí hay un poco de historia: al principio pensé en separar la lógica de mi aplicación de su apariencia. Tenía algunas clases principales, otras para GUI (mostrar y controlar) y algún tipo de "puentes" entre, por ejemplo, mover datos de la clase A que tenía miembros de std :: list a clase B: QAbstractListView público, que tenía QStringList. Pero me di por vencido, cuando tuve que usar más y más código Qt (solicitudes HTTP, E/S de disco, regex). Mi código comenzó a verse como un desastre, y pensé en refactorizar mi código.

(De todas formas, es una buena idea fusionar estas dos cosas - la lógica de aplicación en Qt sub) clases() [/ offtopic]

y llegué a otro problema y es finalmente Relacionado a la de tema: ¿es mejor (por ejemplo, Qt-way), por ejemplo, tener una clase con miembros privados QWebPage y algunos métodos, ranuras y señales públicas para operar en ella o simplemente agregar mi funcionalidad en la subclase de QWebPage?

Answer 1

La herencia es una de las mejores cosas de OOP, si se usa correctamente.

Una "subclase", en todos los buenos diseños de OO, tiene que obedecer una regla simple: ¿ES el niño un TIPO de padre? En la literatura de POO, esto se suele llamar una relación "es una". Y más importante: el niño siempre tiene que hacer dos cosas: especializar un comportamiento genérico, o ampliar la funcionalidad del padre. Lo considero un olor a código cuando una subclase no lo hace.

Dicho esto, su decisión no tiene nada que ver con Qt, o con lo programáticamente mejor o peor. Debe tener sentido.

Un ejemplo: Si usted tuviera un QLabel que tenía que mostrar la puntuación de un juego, y sólo eso, podría ser una buena idea para hacer algo como

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)); 
    }; 

}; 

Por otro lado, si su el marcador tenía algunas luces encima, que debería parpadear cada vez que el puntaje cambiaba, si tenía una etiqueta para cada jugador, que tenía que cambiar su color según el puntaje, entonces sería mejor crear una clase ScoreBoard que TENÍA dos etiquetas, TENÍA dos luces, y luego implementa el comportamiento deseado.

conclusión es: heredar si tiene sentido en su diseño

Wikipedia has a good small article about an anti-pattern that appears when inheritance is used without care.