bien entendu on ne peut pas attendre autre chose d'un mec du steering commitee de KDE, environnement qui se base avant tout sur Qt. Ca fait rien, c'est pas grave.
Kevin Kofler (./182) :
Mais cela n'implique pas non plus forcément qu'ils le conseilleraient à un débutant.
Sasume (./177) :
Le type de message en void *, c’est une mauvaise idée. Le destinataire ne saura pas vraiment quel est le message, à moins de faire de l’introspection, mais c’est généralement une mauvaise idée.
Sasume (./138) :
Une façon simple de faire ça c’est de configurer ton bouton à l’initialisation en lui passant en paramètre l’action à réaliser. Et au moment convenu, le bouton exécutera l’action. Qu’est-ce qu’une Action ? Ça peut être une classe abstraite (ce qu’on appelle une interface en conception objet) qui contient une opération virtuelle pure (abstraite) : execute(). Tu pourras ainsi simplement créer une classe pour chaque action, lui faire implémenter l’opération execute() où tu lui feras faire ce que tu voudras, et ensuite passer une instance de cet classe en paramètre à ton icône, qui se chargera d’appeler sa méthode execute.
Graphiquement, ça donne cette architecture :
Fichier joint :
(action.png)
class TaskManager
{
public:
TaskManager();
void loadTitle();
void startGame();
void mainLoop();
private:
Module *activeModule;
Module *titleModule;
Module *gameModule;
boolean quit;
};
TaskManager::TaskManager()
{
titleModule = new TitleModule(this);
gameModule = new GameModule(this);
activeModule = titleModule;
quit = false;
}
void TaskManager::loadTitle() {
activeModule = titleModule;
}
void TaskManager::startGame() {
activeModule = gameModule;
}
void TaskManager::mainLoop()
{
while (!quit) {
activeModule->run();
}
}
typedef void (*CallBack)(void);
class Icon : public Component
{
public:
Icon(CallBack callBack);
void onClicked();
private:
Callback callBack;
};
Icon::Icon(CallBack callBack)
{
this->callBack = callBack;
}
void Icon::onClicked() {
callBack();
}
class Module
{
public:
virtual void run() = 0;
};
class TitleModule : public StaticModule
{
public:
TitleModule(TaskManager *tm);
private:
Icon *startGame;
};
TitleModule::TitleModule(TaskManager *tm)
{
startGame = new Icon(tm->startGame);
}
void TitleModule::run()
{
// s’afficher et gérer les icônes
// si une icône est cliquée, appeler
// son opération onClicked
}
Sasume (./188) :
Ouais, le truc un peu chiant, c’est que c’est un élément à l’intérieur d’un module qui doit activer le switch de modules, alors qu’un module n’a pas forcément connaissance des autres modules.
Sasume (./188) :
La solution très simple, c’est que chaque module connaisse le TaskManager, comme ça il peut directement lui dire quoi faire en fonction des boutons qui sont cliqués. Mais du coup ça introduit un couplage entre les modules et le TaskManager…
Sasume (./188) :
Pour découpler ça, il faut que chaque module ne fasse que « notifier » un observateur (qui sera le TaskManager) quand un événement important a lieu. Tu peux jeter un coup d’œil au design pattern Observe
Sasume (./188) :
Je pense que ça n’est pas si grave que chaque Module connaisse le TaskManager (parce que sinon on n’en finit pas de mettre de la distance entre les classes, il y a bien un moment où il faut s’arrêter…).
void TaskManager::mainLoop() { while (!quit) { activeModule->run(); } }
PlanePtr = activeModule->CreatePlane(); <consultation de Message s'il y a un message pour quitter> <attente/synchro> MainScreen.dispPlane(PlanePtr);
Folco (./189) :Non, ton idée me paraît plutôt bonne.
Mon concept est moins bon que ce que tu proposes ?
squalyl (./202) :
le problème c'est quand tu te retrouves avec des erreurs incompréhensibles en utilisant n'importe quoi avec qvariant, et que de toute ta vie tu n'as JAMAIS entendu parler de QMetaObject, et que tu perds une demi journée en cherchant ce qu'il faut faire </vecu>.
Kevin Kofler (./204) :
et que de toute ta vie tu n'as JAMAIS entendu parler de QMetaObject
Folco (./208) :
Par exemple, un truc qui a été un véritable flash fut ça : http://fr.wikipedia.org/wiki/Extreme_programming#Conception_simple
Je fais toujours compliqué, évolutif et tout ce qu'on veut. Forcément, comme c'est trop compliqué pour moi, ça n'évolue jamais parce que ce n'est jamais finalisé.