Pour mon $BUILDINGS lui-même, d'accord, en tant que "liste de new", il peut rester comme étant un tableau.
En revanche, pour le $BUILDINGS original, il me semble plus adapté (mais pas obligatoire bien sûr) d'en faire une liste d'objets. Si cela avait été une table de BDD, chaque ligne aurait représenté un objet. On peut d'ailleurs mettre chaque classe dans un fichier séparé, mettre le tout dans un dossier, et parcourir le contenu de ce dossier pour construire "$BUILDINGS". Ainsi, quand on voudra ajouter un type de bâtiment, il suffira de faire une nouvelle classe et de l'ajouter au dossier (0 modification de code = moins de risque de bousiller un truc
).
Ok pour laisser les tableaux en "pas objet" quand ils sont à 1D, mais quand ils sont à 2D avec chaque ligne qui représente un "truc", cela me semble plus approprié de faire de "truc" une classe (surtout quand, comme ici, on a un paramètre "type" qui apparait: cela fait vachement 'class' à mon gout ^^).
Sinon, je suis d'accord pour stocker sous forme de tableaux les matrices (en encapsulant le tableau dans une classe si on veut) et les tableaux de paramètres où chaque élément est indépendant (par exemple, le tableau de combat des pokémons).
D'ailleurs, cela serait peut-être encode plus pertinent d'en faire des interfaces plutôt que des classes: ainsi, il suffirait d'implémenter l'interface à la classe correspondant à ce batiment, plutôt que d'avoir un $BUILDINGS centralisant le tout...
On peut toujours faire les deux: remplacer les "class" de l'exemple par des interfaces (avec des constantes), créer une classe par batiment qui se contente d'implémenter la bonne interface, et instancier ces classes spécifiques dans $BUILDINGS. Dans le reste du code, dans la classe "réelle" du batiment, on pourra alors implémenter la bonne interface.
En revanche, pour le $BUILDINGS original, il me semble plus adapté (mais pas obligatoire bien sûr) d'en faire une liste d'objets. Si cela avait été une table de BDD, chaque ligne aurait représenté un objet. On peut d'ailleurs mettre chaque classe dans un fichier séparé, mettre le tout dans un dossier, et parcourir le contenu de ce dossier pour construire "$BUILDINGS". Ainsi, quand on voudra ajouter un type de bâtiment, il suffira de faire une nouvelle classe et de l'ajouter au dossier (0 modification de code = moins de risque de bousiller un truc
).Ok pour laisser les tableaux en "pas objet" quand ils sont à 1D, mais quand ils sont à 2D avec chaque ligne qui représente un "truc", cela me semble plus approprié de faire de "truc" une classe (surtout quand, comme ici, on a un paramètre "type" qui apparait: cela fait vachement 'class' à mon gout ^^).
Sinon, je suis d'accord pour stocker sous forme de tableaux les matrices (en encapsulant le tableau dans une classe si on veut) et les tableaux de paramètres où chaque élément est indépendant (par exemple, le tableau de combat des pokémons).
D'ailleurs, cela serait peut-être encode plus pertinent d'en faire des interfaces plutôt que des classes: ainsi, il suffirait d'implémenter l'interface à la classe correspondant à ce batiment, plutôt que d'avoir un $BUILDINGS centralisant le tout...
On peut toujours faire les deux: remplacer les "class" de l'exemple par des interfaces (avec des constantes), créer une classe par batiment qui se contente d'implémenter la bonne interface, et instancier ces classes spécifiques dans $BUILDINGS. Dans le reste du code, dans la classe "réelle" du batiment, on pourra alors implémenter la bonne interface.