kij_82
4070Messages postés
7 avril 2005Date d'inscription
24 septembre 2010Dernière intervention
12 févr. 2009 à 17:36
Bonjour,
Déjà tu as bien compris qu'il faut dissocier le coté graphique du moteur de ta future application c'est une bonne chose.
Concernant l'organisation de tes classes, effectivement le mieux est de les regrouper dans des packages liés à leur fonctionnalité. Un (ou plusieurs) packages / sous packages pour tout ce qui se rapporte à l'interface graphique. Idem pour ce qui est du moteur de l'application, d'autres pour des "utilitaires" par exemple, dans lesquel tu regroupe les interfaces de constantes, des classes abstraites pour des fonctionnalités indépendante du contexte (fonction de base, etc.)
Pour ce qui est ensuite de savoir par quoi commencer, ça dépend des gens et des goûts de chacun mais j'aurai tendance à dire qu'il faut toujours s'atteler au programme même et ses fonctionnalités plutôt qu'à l'aspect graphique.
Attention, cela n'empêche en rien de penser à l'un en pensant à l'autre, au contraire il faut pouvoir élaborer ces deux aspects ensemble selon ton but final.
Par exemple, mettons que tu développe un jeu de dame: pour élaborer ta fonction de déplacement d'un pion, il faudra bien que tu ai pensé à la manière dont tu vas afficher tes composants graphiquement (case, pions, etc.)
Au final je dirai qu'il faut que tu commence par définir tous ce que ton projet doit faire, la manière dont il va le faire, les moyens que tu veux y mettre (tu peux faire ça en 2D ou 3D par exemple pour l'aspect graphique), etc.
Ensuite fait le moteur, et enfin le graphique. (ou les deux en parallèle)
