Qt - prawidłowy projekt kodu aplikacji

Question

Trudno było mi znaleźć pokrewny temat, więc oto moje pytanie. Zacząłem używać Qt jak dwa dni temu i dlatego nie mam pojęcia, jak sprawić, by działał (po stronie kodowej).

[Offtopic] Oto trochę historii: na początku myślałem o oddzieleniu logiki mojej aplikacji od jej wyglądu. Miałem kilka klas podstawowych, inne dla GUI (wyświetlanie i kontrolowanie) i pewnego rodzaju "pomosty" pomiędzy, na przykład, przenosić dane z klasy A, która miała członków std :: list do klasy B: publiczny QAbstractListView, który miał QStringList. Ale poddałem się, kiedy musiałem używać coraz więcej kodów Qt (żądania HTTP, I/O dysku, regex). Mój kod zaczął wyglądać jak bałagan, pomyślałem o refaktoryzacji mojego kodu.

(Tak czy inaczej, jest to dobry pomysł, aby połączyć te dwie rzeczy? - logika aplikacji w Qt (pod) grup) [/ offtopic]

I przyszedł inny problem i to w końcu związane z pytaniem w topic: czy lepiej (na przykład Qt-way) mieć klasę z prywatnym QWebPage i niektórymi publicznymi metodami, slotami i sygnałami do działania na nim lub po prostu dodać moją funkcjonalność w podklasie QWebPage?

Answer 1

Dziedziczenie to jedna z największych rzeczy OOP, jeśli jest używana poprawnie.

"Podklasa", we wszystkich dobrych projektach OO, musi spełniać prostą zasadę: CZY dziecko jest RODZAJEM rodzica? Nazywa się to zwykle w literaturze OOP relacją "jest". A co ważniejsze: dziecko musi zawsze robić dwie rzeczy: specjalizować ogólne zachowanie, lub przedłużyć funkcjonalność ojca. Uważam, że jest to zapach kodu, gdy podklasa nie działa.

Powiedziałeś, że twoja decyzja nie ma nic wspólnego z Qt, ani z tym, co programowo lepsze lub gorsze. To powinno mieć sens.

przykład: Jeśli miał QLabel który miał pokazać wynik gry, a jedynie, że może to być dobry pomysł, aby zrobić coś jak

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

}; 

Z drugiej strony, jeśli tablica wyników miała na sobie kilka świateł, które powinny mrugać za każdym razem, gdy wynik się zmienił, gdyby miał jedną etykietę dla każdego gracza, która musiała zmienić kolor w zależności od wyniku, wtedy lepiej byłoby utworzyć klasę ScoreBoard, którą HAD dwie etykiety, HAD dwa światła, a następnie zaimplementuj zamierzone zachowanie.

Konkluzja jest: dziedziczyć czy ma to sens na projekt

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