Salut,
Ce qu'il faut comprendre c'est que, quel que soit le langage envisagé, la finalité reste toujours la même: faire comprendre à quelque chose d'aussi bête qu'un ordinateur, qui agira comme un brave petit soldat prêt à sauter si on lui en donne l'ordre (et si on lui a expliqué comment faire
) sans poser de question...
Il existe donc ce que l'on pourrait appeler les "principes de base" communs à tous les langages impératifs (et les langages OO sont des langages impératifs avant tout
) comme les structures de tests, les boucles et autres joyeusetés du genre (certaines structures de données peuvent d'ailleurs entrer dans cette catégorie
)
Il n'est donc pas très étonnant que, prenant n'importe quel livre destiné "aux débutants" traitant de n'importe quel langage, on commence systématiquement par t'expliquer ces principes de base
Ensuite, vient le coté "OO" des langues, qui arrive, lui aussi, avec une série de principes communs...
Encore une fois, à partir du moment où tu as compris ce qu'est une classe et une fonction membre, il n'est pas étonnant que tu aies l'impression d'une "resucée" en passant d'un langage à l'autre car c'est, en gros, "tout le temps la même chose"
Finalement, si on regarde java, C# et C++ avec un oeil critique, on s'aperçoit assez facilement que la grosse différence est la "philosophie" du langage et que toutes les différences qui existent ne découlent que de cette différence de philosophie
Après tout, un langage de programmation reste fort proche, sémantiquement parlant, de n'importe quel langue : ce n'est jamais qu'un moyen de dialoguer avec quelque chose ou quelqu'un.
La seule différence entre le français ou l'anglais et un langage de programmation, c'est que l'un des interlocuteur est bête comme mes pieds (et je ne vise pas la personne qui est derrière son clavier en disant cela
)
Le fait, c'est qu'après avoir lu un livre sur n'importe quel langage orienté objets, jusqu'au classes, tu ne sais encore "que" comment organiser ton code...
Seulement, tu n'as visiblement pas "percuté" sur un problème important
:
Tout programme n'est qu'une suite d'instructions ayant pour but de remplir certains besoins.
Seulement, pour que le programme soit efficace, il faut... avoir conscience des besoins qu'il doit remplir
L'écriture du code n'est en fait que la dernière étape à effectuer entre le moment où l'on a une idée ( "je voudrais créer un shoot them up" ) et le moment où l'idée en question est concrétisée par l'existence d'un programme qui... fait ce que l'on attend de lui.
Entre ces deux moment, il y a une série d'étapes qui doivent être franchies, comme:
- l'analyse fonctionnelle : le fait d'exprimer clairement ce que l'on veut
- l'analyse technique : le fait de déterminer l'ensemble des fonctions, des structures et des classes qui nous permettront d'obtenir ce que l'on veut
- La création éventuelle d'algorithme : le fait de trouver la logique "la moins mauvaise" permettant de nous assurer que, partant d'une situation A, nous arriverons bel et bien à une situation B correcte
Ce n'est qu'après que l'on peut envisager "sereinement" d'écrire le code qui correspondra aux algorithmes et aux structures de données que l'on a décidé d'utiliser
Bien sur toutes ces étapes peuvent se faire en plusieurs fois, et il est même largement conseillé qu'elles se fassent en plusieurs fois.
On remarque en effet que les besoins évoluent énormément au fil du temps, ne serait-ce qu'il n'est pas rare que la mise en oeuvre (le fait d'écrire le code, ou de l'exécuter) ne mette en évidence des problèmes auxquels on n'avait pas forcément pensé.
Il n'est donc pas rare de "revenir" sur certains algorithmes, sur l'analyse technique, voir, carrément, sur l'analyse fonctionnelle parce que l'on s'est rendu compte, en écrivant le code que "décidément, non, là, y a quelque chose qui va pas"
Encore une fois, il n'y a pas grand chose à faire : une classe sprite aura toutes les chances de ressembler furieusement à n'importe quelle autre classe sprite déjà créée dans le même langage, à seulement quelques détails près
Par contre, ce qu'il faut comprendre, c'est qu'il existe différents "niveaux" dans une application:
- La partie que je qualifierais de "métier" (on parle souvent de "modèle" ) : c'est la partie dans laquelle tu regroupes l'ensemble des données que tu manipules de manière à en faire un tout cohérent.
C'est aussi dans cette partie que tu places les règles qui doivent être respectées de manière systématique
- La partie qui permet à l'utilisateur d'appréhender les donnée (on parle souvent de "vue" ) : c'est l'ensemble des fonctions et des classes qui permettent à l'utilisateur d'avoir un aperçu des données manipulées.
C'est aussi cette partie qui a la responsabilité de récupérer les intentions de l'utilisateur au moyen des différents périphériques qu'il peut utiliser (clavier, souris, ... )
-Enfin, il y a la partie qui fait le lien entre les deux (on parle souvent de "controleur") en transmettant les informations issues des données métier d'une part et en signalant aux données les manipulations qu'elle doivent subir sur base de l'interprétation des entrées utilisateur.
C'est aussi cette partie qui se chargera, si une erreur survient, de la transmettre dans un format "compréhensible" à la vue pour que celle-ci puisse en informer l'utilisateur.
Ce qu'il faut aussi comprendre, c'est que toute classe ou fonction ne vaut que par l'usage qui en est fait...
Une classe ou une fonction qui aurait été créée mais qui ne serait pas utilisée n'est, en définitive, qu'un moyen trouvé par le développeur pour perdre du temps, parfois à son corps défendant
Ainsi, ton sprite, vu que c'est l'exemple que tu donnes, ne vaut que si tu as, à coté de ton sprite, le moyen de le positionner, celui de décider de le créer, celui de décider de le détruire et celui de l'afficher, à la bonne position...
Créer un shoot'em up
Répondre avec citation
Envoyé par phi1981
A méditer: La solution la plus simple est toujours la moins compliquée
Partager