Salut tout le monde !!

Je fais un jeu en C++ avec la SFML et j'ai vue, il n'y a pas longtemps, la structure ECS et voici mon problème:

                                                                    objet

                                AfficherSprite                                       Et là, je voudrais faire ça:

                   MonPerso           MesEnemis                                       Fichier

                                                                                                        Map      Collision

                                                                                                 ChangementDeNiveau

                                                                                                         ConfigJeu

Mais, j'ai entendue dire que ce n'était pas bon de faire une classe (ConfigJeu) qui hérite des fonctions de plein d'autre classe: ChangementDeNiveau qui hérite des fonctions et des attributs Map et Collision qui hérite des fonctions et des attributs de Fichier qui hérite aussi de objet(phrase spécial ).

Donc si quelqu'un à une réponse au sujet, merci de répondre !!!!!!

-
Edité par Titicplusplus 1 décembre 2018 à 20:02:49

Pour commencer, il  n'y a pas de réelle question dans ton post...

Quant a la question implicite, ça n'a rien à voir l'ECS. Pour moi, un fichier Config de jeu est juste un fichier qui où est écris toutes les constantes et valeurs par défauts nécessaire lors de l'initialisation de ton jeu. Cela n'a rien à voir avec l'ECS ou l'OO.

De plus l'ECS n'est, ni une architecture magique qui va résoudre tous tes problèmes, ni une architecture qui remplace totalement OO.

Soit tu as fait du Java avant, soit tu as attrappé le syndrome du programmeur Java: Tout n'est pas forcement classe. 

-
Edité par eugchriss 2 décembre 2018 à 0:25:33

Je ne suis pas sûr d'avoir compris (ni trouvé) la question. Mais si j'ai bien compris, c'est un schéma d'héritage que tu as fait dans ton post.

Pour être franc, j'y comprends rien . Le seul conseil que je peux te donner, c'est de mieux nommer tes classes.

"AfficherSprite" et "ChangementNiveau" ne sont pas des noms de classes, "Afficher" est un verbe et "Changement" est une action. rappelle-toi qu'une classe est faite pour être instanciée, le nom d'une classe doit donc être composé d'un ou plusieurs noms.

Personnellement, j'accorde beaucoup d'importance au nommage des classes dans le code, la façon dont une classe est nommée influencera la façon dont tu la percevras pour le reste de ton projet. Si ta classe est mal nommée, tu risque d'oublier ou de tomber dans le flou sur ce qu'elle représente.

Et si jamais tu as de la peine à trouver un nom cohérent pour une de tes classes, il faut peut-être remettre en question son existence même, parce que si aucune combinaison de mots de l'anglais ou du français ne permet de décrire ce que représente ta classe en un nombre raisonnable de caractères, c'est que :

• Elle fait trop de choses ou représente plusieurs choses à la fois
• OU
• Elle représente un concept trop abstrait pour être compris par un être humain (autre que toi bien sûr )

Et aussi, évite de considérer une classe comme juste "un groupe de méthodes", si ta classe n'a que des méthodes comme membres, c'est qu'elle n'a aucune raison d'être instanciée. Dans ce cas, ce n'est pas une classe et tu peux autant mettre tes méthodes dans un namespace (parce que en C++ on fait pas de classes statiques ).

La règle fondamentale de la programmation orientée objet est la notion de service. Créer une classe pour créer une classe n'a aucun sens, c'est juste absurde. Je créé une classe pour qu'elle remplisse un rôle, qu'elle assure un service dans mon programme. Cette notion de service est centrale, c'est elle et elle seule qui décide du design d'une classe.