Kevin Kofler (./5) :Je suis tout à fait d'accord sur le principe, ceci dit :
Mais normalement les dialogues sont clairement la responsabilité de la couche interface, la couche données n'a pas à produire une interface utilisateurs quelle qu'elle soit.
- comment la couche Application fait-elle pour proposer des valeurs limites correctes lors de la création/édition ? Elle demande pour chaque donnée à la couche Données ? Fastidieux. Et pourtant, pour chaque spinbox et autre entrée, il faut bien valider des valeurs. Une callback vers la couche Données (QValidator...) me semble pénible, pourtant l'Application ne peut pas inventer ces valeurs limites.
- Dans un cas comme celui-ci :
// Save the file
stream << QString(GAME_FILE_SIGNATURE) << GAME_FILE_VERSION << Name;
if (stream.status() != QDataStream::Ok) {
QMessageBox::critical(MainWindow::get(), tr("Error"), tr("Couldn't save to the file %1").arg(FullFilename));
return false;
}
Modified = false;
return true;Cette méthode (open()) qui appartient à la couche Données peut tomber sur plusieurs erreurs, alors deux solutions :-> elle affiche ses dialogues et renvoie false en cas d'échec
-> elle renvoie un code d'erreur, à tester pas la couche Application, qui devra afficher le message idoine. Ca nécessite de créer une énumération en plus, de faire un plus ou moins gros switch dans la partie Application. C'est plus propre sur le papier, mais ça complexifie le code.
J'ai fait ça parce que je pense que c'est mon juste milieu, mais je ne sais pas si c'est vraiment bien. Un illustre programmeur de notre siècle disait en substance que le bon codeur, c'est celui qui arrête de couper les cheveux en 4 au moment où il faut, c'est ce que j'essaye de faire (ok j'ai du mal
)Alors c'est sûr qu'au niveau réutilisabilité, je suis dans les choux avec ça, mais je dirais que je ne suis pas concerné par cette problématique.
Alors si vraiment ça vous semble bancal, dites-moi pourquoi, et surtout expliquez-moi comment la couche interface (je pense à toi Flanker, et ton modèle qui ressemble à client-serveur) peut proposer un dialogue de création/édition correct, sans mettre les pieds dans les données, et sans que Données expose ses trippes avec mille getters/setters.
edit -> hmmmarche plus la balise source ??
edit 2 -> merci pour les autres réponses, merci pour ton exemple Pen², je regarde, je comprends et j'y reviens. Kevin -> je n'utiliserai pas ce qui est KDE only, et non officiellement supporté. L'avantage de se cantonner à Qt, c'est que ça devrait éviter les mauvaises surprises.
