Skip to main content

acc_base, acc1 et acc2 — séparation des responsabilités

Principe

La vraie logique Accounting partagée côté serveur vit dans acc_base. acc1 et acc2 sont des wrappers qui instancient la même base avec un GameUid différent et exposent les commandes sous le namespace propre au jeu.

Utils

classDiagram
class GameSpecificUtilsAccBase
class GameSpecificUtilsAcc1
class GameSpecificUtilsAcc2
GameSpecificUtilsAccBase <|-- GameSpecificUtilsAcc1
GameSpecificUtilsAccBase <|-- GameSpecificUtilsAcc2

GameSpecificUtilsAcc1() appelle GameSpecificUtilsAccBase.call(this, "acc1"); Acc2 fait la même chose avec "acc2". Les deux enregistrent ensuite leur instance dans utilsByGameUid et exposent utilsAccGameSpecific.

Ce qui appartient à acc_base

  • constantes et préférences Accounting;
  • mapping bill → buy/sell;
  • partenaires et comptes impactés;
  • seed de Team Module;
  • amortissement d'immobilisations;
  • calculs contrats/régularisations;
  • settings régionaux;
  • résolution act/module/page settings;
  • comptes utilisés et structure de pages;
  • conditions/visibilité;
  • prix et helpers partagés.

Command wrappers

Les dossiers acc_base/command, acc1/command et acc2/command contiennent des scripts de mêmes familles : answer key, generate results, custom command, reopen module, correction mode, etc. Les wrappers Acc1/Acc2 assurent surtout le namespace et la sélection des static data game-specific.

Unity

La même règle s'applique : le framework se trouve dans Assets/Src/Game/Data/ByModule et Assets/Src/UI/SimByModule; seules les vraies différences de contenu/assets vont sous Assets/GameSpecific/acc1 ou acc2.

Règle de maintenance

Si une modification doit fonctionner de la même façon dans Acc1 et Acc2, elle ne doit pas être dupliquée dans deux fichiers game-specific. La placer dans le framework By Module ou acc_base selon qu'elle est générique au framework ou spécifique au domaine Accounting.

Où placer une nouvelle règle Accounting

Règle Emplacement Valable pour tout By Module, même un futur jeu non Accounting _utils/by_module. Spécifique à la comptabilité mais commune Acc1/Acc2 acc_base. Différence réelle Acc1 seulement acc1. Différence réelle Acc2 seulement acc2.

Ajouter un helper Accounting partagé

    Ajouter la fonction à GameSpecificUtilsAccBase. Utiliser this.* lorsque la fonction fait partie de l'API de l'instance. Réutiliser les constantes/preferences déjà exposées par la base. Vérifier que GameSpecificUtilsAcc1 et Acc2 héritent automatiquement du comportement. Tester les deux jeux, car leurs static data peuvent différer même si le code est commun.

    Éviter la duplication acc1/acc2

    Si deux fichiers game-specific contiennent la même fonction à quelques valeurs près, déplacer la logique dans acc_base et passer la différence par static data/settings. Les wrappers game-specific doivent rester minces.

    Debug d'un “utilsAccGameSpecific is not defined”

      Vérifier que le wrapper game-specific inclut son fichier utils. Vérifier que l'instance GameSpecificUtilsAcc1/Acc2 a été construite. Vérifier l'ordre des bridge.include(). Dans le debugger local, inclure le même game-specific que le script réel. Ne pas supposer que le test runner est neutre : il inclut actuellement Acc2 dans son bootstrap.
      Back to top