Une base de code Unity n'a pas besoin d'être un tas de "classes liées à un sujet".
Votre application gère les entrées de l'utilisateur, les calculs, les opérations de réseau et doit rendre une image à afficher à l'utilisateur à chaque image. Vous devez séparer les responsabilités.
En d'autres termes, vous devez essayer de réduire autant que possible le couplage entre votre vue et votre logique, et extraire vos opérations de mise en réseau dans un bloc séparé. Gardez également à l'esprit que vous devez concevoir votre module de jeu de manière à ce qu'il soit réutilisable autant que possible. Vous devez éviter d'utiliser la même structure de données dans différents modules et vous devez donc introduire un moyen d'assurer l'indépendance des données entre les modules apparentés.
Le principe SOLID
Le principe SOLID est un concept clé de la programmation orientée objet qui résume ces idées :
S : Single responsibility principle : chaque classe est responsable d'une et d'une seule tâche (ainsi, aucune interface utilisateur ne doit être affichée par votre classe d'interface réseau).
O : Open/closed principle : chaque module que vous développez doit être ouvert à l'extension mais fermé à la modification, c'est-à-dire que l'architecture doit anticiper les changements ultérieurs et donc fournir des moyens d'ajouter de nouveaux éléments connexes de manière simple par le biais de l'héritage, par exemple.
L : Liskov substitution principle : une sous-classe doit préserver l'objectif de sa classe mère, Les méthodes ou propriétés surchargées doivent avoir la même signification que dans la classe mère.
I : Interface segregation principle : l'interface est définie par de petits rôles uniques, une classe doit pouvoir l'implémenter et, le cas échéant, n'implémenter que les méthodes qui lui sont utiles.
D : Dependancy inversion principle : les modules de haut niveau ne doivent pas dépendre des modules de bas niveau, vous devez introduire une sorte d'abstraction par le biais d'une interface. Une excellente explication peut être trouvée ici : https://www.oodesign.com/dependency-inversion-principle.html
Clean Unity Architecture
Afin de rendre les applications Unity 3D plus robustes, nous allons décrire dans ce post comment in est possible d'appliquer le principe de Clean Architecture au développement d'applications Unity 3D.
Appelons-le Clean Unity.
Cette architecture répond à la nécessité de maintenir une base de code propre, avec des modules à responsabilité unique, testable et d'organiser le code avec des intentions plutôt que par une structure qui laisse transparaître les détails d'architecture bas niveau.
Le View Controller, l'Interactor et le Presenter sont les trois principaux composants de Clean Unity. Ils agissent en tant qu'entrées/sorties les uns des autres, comme le montre le diagramme suivant.
Le Controller est le point d'entrée de déclenchement de tous vos use cases, il va appeler les méthodes publiques du use case associé via une couche d'abstraction ou interface (en vert sur le diagramme ci-dessus).
Nous envoyons un objet DTO de requête en tant que paramètre de l'appel de fonction afin de garantir l'indépendance des données (les variables de l'interacteur ne dépendent pas directement des variables du contrôleur). Cela nous permet d'être libre de changer le contenu de la requête avec des changements minimes, c'est-à-dire en modifiant uniquement le DTO de la requête (une structure C# dans notre cas).
Le Interactor calcule ensuite les données nécessaires pour savoir ce que nous devons afficher, c'est bloc logique de votre application qui contient vos use cases, votre logique métier.
Remarque : si l'Interactor comporte une fonctionnalité trop complexe (par exemple, une tâche de mise en réseau pour récupérer un résultat), nous pouvons également extraire une partie de son code interne vers une autre classe que nous nommerons Worker.
L'Interactor envoie ensuite les données calculées à un bloc Presenter (par l'intermédiaire d'une interface) et ce bloc final est responsable du rendu de tous les types de retours d'information à l'utilisateur. Dans Unity 3D, ils peuvent prendre différentes formes : modifications de l'interface utilisateur en 2D, mouvements de transformation en 3D, animations, sons, etc. ; c'est pourquoi on peut également le séparer en plusieurs classes dédiées à chaque type de rendu.
Le Initializer contient et valide simplement toutes les références aux scènes et assets Unity.
Remarque : il peut également récupérer ces références dynamiquement si un objet du jeu est instancié sur la scène au cours de l'exécution (par un appel à FindObjectOfType par exemple).
L'architecture Clean Unity est une application de l'architecture Clean popularisée par Uncle Bob. Il convient donc de se référer aux principes fondamentaux pour une meilleure mise en application : en particulier les concepts de components, boundaries et models.
Et si vous saviez exactement quel fichier ouvrir et quelle méthode utiliser ? À quel point pourriez-vous être plus productif ? Imaginez que vos tests s'exécutent en quelques secondes au lieu de minutes ou d'heures. Et vous n'avez besoin d'aucun Unity Package à installer.
Achetez le Clean Unity Handbook pour obtenir un tutoriel clair expliquant comment mettre en place une architecture propre dans vos projets Unity en prenant l'exemple concret d'un module d'achievements générique. Il vous fournira également des modèles C# pour commencer à implémenter vos fonctionnalités réutilisables plus rapidement !
Dans ce Clean Unity Handbook, vous apprendrez comment :
- Identifier de potentiels bugs dès la phase de conception pour limiter au maximum leur nombre par la suite.
- Ajouter des nouvelles features plus facilement.
- Ecrire des méthodes et des classes plus courtes avec le principe de responsabilité unique (SRP)
- Découpler les dépendances de vos classes en établissant des limites bien définies via l'utilisation d'interfaces.
- Extraire la logique métier de vos View Controllers vers des classes Interactors testables unitairement.
- Construire des composants réutilisables pour vos différents projets.
- Ecrire des tests unitaires robustes et maintenables.
- Faire confiance à vos tests pour détecter les régressions.
- Appliquer ce que vous avez appris à des projets nouveaux ou existants, quelle que soit leur portée.
Tout cela sera mis en œuvre sur un module d'achievements/objectifs concret qui sera réutilisable pour vos différentes applications.
Nous l'utilisons pour le développement de nos applications de jeux tels que :
“Furious Bounce”, un pong multijoueur nouvelle génération.
En savoir plus ici.
Français 
English