Discussion :

[TomHardcore_]

Bonjour, bonsoir tout le monde !

Je ne suis qu'en deuxième année de maths-info et donc je ne fait pas encore d'architecture logicielle, mais en ce moment je m'y interesse à fond. Je tiens un blog sur la programmation, les maths et les jeux vidéo et j'ai écrit un article de présentation du modèle MVC. J'aimerais des avis de personnes plus expérimenté dessus :
- Ais-je bien compris le modèle et écrit un article sans erreur ?
- Est-ce bien expliqué ?
- Ais-je homis des choses importante ?
- etc...

Je voudrais faire un article le plus détaillé possible, de plus je veux savoir si j'ai bien compris ce qu'est le modèle MVC vu que je vais retaper un bout de code de mon jeu de game jam selon ce pattern (à savoir la partie menus, settings, grille d'affichage des niveaux débloqué, gestion niveau lock/unlock etc..) pour m'entraîner.

Lien : https://krankerapfel.fr/2017/10/07/d...le-modele-mvc/

Merci beaucoup et désolé pour l'orthographe j'y boss !

[foetus]

• il s’agit de modèles permettant d’apporter des solutions -> non, le patron de conception décrit les grandes lignes d'une solution.
• peuvent donc s’appliquer en toutes circonstances -> justement non les patrons ne sont pas des solutions clef en main, mais des solutions à adapter.
• Chaque patron appartient surtout à une catégorie. Il y en a 3 de base : fonctionnel, créationnel et "je ne sais plus"

MVC :
*) il est le seul module à interagir directement avec la data base -> oui et non. le modèle interagit avec les données. Quelles soient en base ou en fichier, c'est un détail d'implémentation.

*) C’est par le biais de cette interface graphique que le joueur recevra les informations / Mais surtout il est le seul à récupérer les inputs de l’utilisateur -> oui et non. Dans un MVC, c'est le contrôleur qui reçoit les entrées. Dans un MVP (et peut être MVVM), c'est la vue qui reçoit les entrées.

*) Elle ne manipule aucune données, elle se contente de les recevoir du modèle et de les rendre à l’écran / il coordonne les transactions entre la View et le Model. -> la vue a des données d'affichage : par exemple des états. Et de plus, dans un vrai MVC la vue peut interagir avec le modèle pour récupérer des données d'affichage. Par exemple les traductions.

*) modifier l’un n’impactera aucunement sur l’autre -> oui et non. Si tu ne pousses pas la conception d'une partie à fond, tu peux à avoir à modifier 2 voire 3 parties.
Par exemple, si tu codes un modèle en version CRUD.
Tout également, si tu rajoutes des traitements à ton modèle, il faut bien que soit le contrôleur soit la vue les utilisent.

*) Model, c’est le cœur du programme, c’est là que s’effectuent les calcules et le traitement des données. Il contient toute la logique du jeu, c’est-à-dire les règles qui régissent l’univers virtuels comme la physique, les événements, le comportement des pnj, mais aussi l’état actuels de chaque objets, les variables globales tel les volumes sonores etc… ->
Perdu, avec un MVC, tu auras :

• les règles spécifique aux données -> dans le modèle. Un exemple : le chiffrement des données
• les règles spécifique à la vue -> dans la vue. Un exemple, un bouton "trois états"
• Toutes les autres règles dans le contrôleur. Ce sont essentiellement des règles métier ("business logic")

Et encore. On peut aller encore plus loin que le MVC et introduire une notion de "Domain Logic".


fautes :

• scénario infernale
• notre logicielle x3
• d’autre plateforme -> on porte sur au moins 2 plateformes
• bien d’autre -> pleins d'autres
• plusieurs personnes dont des experts on déjà testée et approuvée -> ont et le féminin
• calcules
• l’univers virtuels
• l’état actuels
• chaque objets
• tout les éléments
• ont complémentaire -> vérifier le pluriel
• qui leurs permettent -> c'est la modélisation qui permet
• laisser tombé
• peuvent être ajouter
• je vous promet

Anglais inutile :

• features -> fonctionnalités
• pattern x4 -> patron
• software -> logiciel
• pnj
• data base -> base de données.
• View -> vue
• Controller -> contrôleur
• Model -> modèle
• inputs -> entrées

Tout les bouts de phrases d'un débutant :

• pour cela en Programmation Orienté Objet (POO), on a la chance d’avoir des outils efficaces : les designs pattern. -> en procédural, il y a aussi des méthodes pour travailler [plus ou moins] proprement. J'ai fait une formation et c'était pareil avec les formateurs : procédural == gros tas de m$rd$, objet == le truc ultime. Et les patrons peuvent être adaptés en procédural (mais peut être pas tous par contre)
• nous éviter les codes redondants (ré-utilisabilité) -> avant de faire du générique, il faut faire du spécifique et donc de la redondance
• la simplicité -> c'est le plus dur à obtenir. KISS ce n'est pas simple
• La qualité de votre logiciel dépend donc des performances permises -> la qualité c'est ce que demande le client et si c'est fonctionnel. Si la performance n'est pas demandée (un jeu à 30 fps vs un jeu à 60 fps) on s'en fiche.
• l’association de plusieurs d’entre eux est souvent plus efficace -> empiler les patrons de conception, il faut vraiment voir.

[TomHardcore_]

Merci foetus pour ta réponse bien détaillée ! J'ai néanmoins quelques questions :

peuvent donc s’appliquer en toutes circonstances -> justement non les patrons ne sont pas des solutions clef en main, mais des solutions à adapter.

- En faite ce que je voulais dire c'est qu'on peut les appliquer peut importe le langage et/ou le moteur de jeu utilisé. C'est bien le cas ?

Chaque patron appartient surtout à une catégorie. Il y en a 3 de base : fonctionnel, créationnel et "je ne sais plus"

- Je crois que c'est structurel et que le MVC en est un de structure justement. Ou alors c'est une sous catégorie, je vais me renseigné plus en détails.

il est le seul module à interagir directement avec la data base -> oui et non. le modèle interagit avec les données. Quelles soient en base ou en fichier, c'est un détail d'implémentation

- D'accord pour ça ! Mais du coup est-ce que c'est bien uniquement le modèle qui interroge les données où est-ce que la vue aussi ? J'ai beaucoup hésité pour ça, je ne suis pas sûr d'avoir bien compris les articles que j'ai lu. Mais d'après le point suivant, si j'ai compris ce que tu m'as dit, quand la vue a besoin de récupérer des données, elle les reçoit du modèle, donc pas besoin d'interagir directement avec les fichiers ou la base. C'est ça?

l’association de plusieurs d’entre eux est souvent plus efficace -> empiler les patrons de conception, il faut vraiment voir.

- J'ai lu ça dans un livre à la bibliothèque universitaire. Après peut-être qu'il aurait été plus judicieux d'expliquer qu'un patron est adaptable, on est pas obligé de l'utiliser tel qu'il est, et qu'en plus on peut en combiner plusieurs si on est dans un cas où il est interessant de le faire. non ?

En tout cas merci pour toutes tes réponses, heureusement que je lis ça avant de re travailler le code de mon projet sinon en faîte je l'aurais fais totalement de travers ! D'ailleurs, ça s'annonce plus complexe que je ne l'avais imaginer ^^

Je vais apporter une première correction à mon article

EDIT : Je suis en train de me demander s'il est correct de remplacer :

nous éviter les codes redondants (ré-utilisabilité)

par "nous permettre de minimiser la redondance" ou "nous permettre d'écrire du code ré-utilisable"

[foetus]

En faite ce que je voulais dire c'est qu'on peut les appliquer peut importe le langage et/ou le moteur de jeu utilisé. C'est bien le cas ?

Justement on peut les importer, mais il faudra sûrement l'adapter au langage et/ ou au moteur de jeu utilisé

Prends ton MVC On te dit le modèle interagit avec les données. Mais jamais on te dit comment ? une base de données ? Quel SGBD ? un fichier ? Quel format ?
Voire même quel MVC ? un vrai MVC ? un MVP ? un MVVM ?

Si tu codes ton MVC en java avec un ORM java, pour passer au C++/ Unreal Engine tu vas avoir des problèmes

Mais d'après le point suivant, si j'ai compris ce que tu m'as dit, quand la vue a besoin de récupérer des données, elle les reçoit du modèle, donc pas besoin d'interagir directement avec les fichiers ou la base. C'est ça?

Oui, c'est la séparation des concepts (<- traduction qui n'existe pas en français, Separation of concerns lien wiki)

Le contrôleur sait que le modèle permet de charger/ décharger des textures. Le contrôleur sait que la vue sait afficher en 1024x768. La vue peut demander au modèle les traductions.

Mais, le contrôleur n'a pas à savoir comment sont stockées/ chargées les textures. C'est le modèle qui le gère et c'est un détail d'implémentation.
Le contrôleur n'a pas à savoir comment est fait l'affichage (OpenGL vs DirectX) C'est la vue qui le gère et c'est un détail d'implémentation.
La vue n'a pas à savoir comment sont stockées/ chargées les traductions. C'est le modèle qui le gère et c'est un détail d'implémentation.

Chacun expose une interface/ des objets que les 2 autres peuvent utiliser.

C'est d'ailleurs pour cette raison que la logique est découpée en [au moins] 3 parties et répartie à bon escient.

Après peut-être qu'il aurait été plus judicieux d'expliquer qu'un patron est adaptable, on est pas obligé de l'utiliser tel qu'il est, et qu'en plus on peut en combiner plusieurs si on est dans un cas où il est interessant de le faire. non ?

Un patron de conception c'est les grandes lignes d'une solution. Donc qui dit solution dit problème.

Il faut déjà rencontrer un problème , et réfléchir à comment le résoudre : quel est l'étendue du problème : il touche l'architecture, la logique, les données, ... ? Est ce-qu'on le résout proprement ou salement ? rapidemment - on a un peu de temps ? ...

Et une fois cela "mis en lumière", on peut décider d'utiliser aucun, 1 ou plusieurs patrons. Mais pas autrement.

[TomHardcore_]

Hum je comprends mieux, je vais plutôt écrire qu'ils sont adaptables à tout langages/moteurs alors. Je n'avais pas prévut de parler de MVVM (et je ne connaissais pas MVP) mais peut-être que c'est mieux d'au moins les évoquer dans mon article finalement, histoire d'expliquer les variantes et possibilités.

Je pense que je vais parler aussi de la "séparation des concepts", en faite c'est carrément plus claire quand on a ça en tête ! On sait mieux ce qu'on fait

+ Je ne sais pas si tu as vue mon edit :

EDIT : Je suis en train de me demander s'il est correct de remplacer : "nous éviter les codes redondants (ré-utilisabilité)" par "nous permettre de minimiser la redondance" ou "nous permettre d'écrire du code ré-utilisable"

Qu'en penses-tu ?

[foetus]

Je suis en train de me demander s'il est correct de remplacer : "nous éviter les codes redondants (ré-utilisabilité)" par "nous permettre de minimiser la redondance" ou "nous permettre d'écrire du code ré-utilisable"

Avant de parler de ré-utilisable, commence par faire 1 MVC correctement
Le côté ré-utilisable c'est avec au moins 3 MVCs, 3 projets. On commence par faire du spécifique avant du générique.

Et tu tombes sur la mauvaise personne : je ne trouve pas que le code ré-utilisable soit un critère important parce que soit tu as des dépendances, soit tu as du code minimaliste (par exemple un squelette ("backbone"))

Et justement, pour un jeu vidéo, c'est intéressant de réutiliser tout le code de chargement/ déchargement des textures, le code d'affichage.
Mais par contre réutiliser la base de données et les traductions c'est quand même très limité

Et c'est ce que je te disais : pour pouvoir réutiliser, il faut pousser la conception à fond et planquer son modèle ses vues derrière des layers, des proxis, ou autres petits frères.
L'autre avantage de cela, c'est de pouvoir changer facilement une partie de son code si on ne touche pas à l'interface.
Par exemple, on passe d'un rendu OpenGL à un rendu DirectX, de SQLite à mysql, d'une base de données relationnelle à NOSQL, ...

[foetus]

la simplicité -> c'est le plus dur à obtenir. KISS ce n'est pas simple

Je reviens pour donner un lien wiki et préciser une notion puisque tu es débutant : Principe KISS

[TomHardcore_]

Désolé j'ai été abscent quelque temps !

Merci pour le lien

J'ai pas encore eu le temps de mettre en pratique le modèle MVC, je vais essayer de trouver un moment ce week-end. Ce sera certainement plus claire pour moi déjà si je pratiquais