Unity : Couplage fort et spaghetti

Chose promis, chose due, je reviens vers vous avec le premier tips concernant l’éditeur Unity. Une chose assez déroutante lorsqu’on commence à scripter avec Unity est l’interaction entre les scripts (écrit à travers mono ou visual studio) et l’éditeur Unity.

En fait, Unity fonctionne vraiment de façon très basique et ressemble plus à un outil qui permet d’intégrer et de lier ensemble plusieurs types de contenu du code, de la 3d, du son, des animations qu’un outil fait pour développer du jeu. Finis le temps du homemade, on rentre dans un processus industrialisé et sans doute moins fun.

En bref pour commencer à utiliser des scripts sous Unity, il va surtout falloir faire du click,click, en glissant déposant dans un objet 3D (gameobject) ou son inspector, le script. La fenêtre inspector sert à définir les composants de l’objet 3d, et aussi sous certaines conditions les variables de ta classe c#.

Une fois ton script déposé, l’inspector de l’objet va interagir d’une façon assez déroutante (..) Déjà que tu sois en mode édition ou simulation, ta classe va être instanciée. Imaginons que tu veuilles voir ou éditer le contenu d’une variable de ton objet (au sens c#) à partir de cet inspecteur, il va falloir que tu passes en publique l’exposition de ta variable.

public int score = 0;

De plus si tu édites la valeur de cette variable via l’inspector (avant le lancement de la simulation ou pendant), la valeur que tu donnes écrase la valeur d’initialisation codée dans la classe.

public int score = 0;

score vaut 100 dans l'éditeur

la valeur réelle sera 100.

L’exposition publique des variables est un véritable problème car cela signifie que l’ensemble des interactions définies via l’éditeur Unity, entre les objets c# ne se fait pas à travers des méthodes mais directement via les propriétés des objets c# (..)

Comme tu dois le savoir en objet, un des principes de base est l’encapsulation des données pour éviter que le code d’une classe ne se retrouve pas erreur de conception, déplacé dans une autre classe.

Hors quand tu rends publiquement accessible la propriété d’un objet depuis l’extérieur de cet objet, forcément d’autres objets vont traiter et modifier directement la propriété de l’objet.

citation de wikipedia:

Un couplage fort est à proscrire pour plusieurs raisons :
    Un couplage fort génère l'antipattern plat de spaghetti :
        On ne peut pas déterminer le qui, le quoi et le comment d’une modification de données.
    Un couplage fort implique nécessairement une faible indépendance fonctionnelle :
        Le composant logiciel est difficilement réutilisable,
        Le composant logiciel est difficilement testable.
    Si deux tâches accèdent, par couplage fort, à une ressource commune (ressource critique) et qu'elles s'exécutent en exclusion mutuelle, alors si une des tâches reste bloquée en section critique elle bloque automatiquement l'autre :
        Risque d'interblocage.

Les composants perdent leur autonomie. On peut difficilement remplacer un composant par un autre. Les structures fonctionnant avec du couplage fort sont donc peu souples et peu ouvertes.

Bref vous l’aurez compris, cet implémentation depuis l’éditeur a du et va encore pousser des centaines de codeurs ou développeurs de jeux video à faire du code bullshit.

Une façon plus élégante de traiter ce type de problématique aurait été d’afficher dans l’éditeur toutes les méthodes publiques de l’objet.

exemple:

private int scoreboard = 0;
public void setScore(int score){
scoreboard = score;
};

Malheureusement, ce type de code n’a aucun effet, et Unity pour nous faciliter la tâche nous propose simplement et logiquement de recoder et d’étendre les possibilités de son inspector (lol).

Heureusement, il existe une première solution de contournement applicable pour les variables de type primitif.

[SerializeField]
private int scoreboard = 0;

La directive SerializeField aura donc pour effet de rendre visible et éditable la variable dans l’inspector, tout en conservant son caractère privé dans le code.

Je reviendrais dans un autre tutorial sur la deuxième méthode qui consiste à étendre la classe editor.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s