https://gameprogrammingpatterns.com/command.html
- pas mal pour le undo redo (je l'ai deja +/- guess, mais y'a surrement des trucs a en tirer)
- pour les interactions les "ordres" entre differents objects, ca rend le trucs plus clean ? (sinon observer, mais plus de call direct)
http://gameprogrammingpatterns.com/flyweight.html
- pour les cubes (c'est l'instance que j'ai le plus en jeu)
- j'ai bien compris la 2eme partie
  observer
Je le connais, mais je pourrais aller plus loin avec le player, par example
Est-ce que je doit unregistrer des Instance pour qu'elles soient bien free ? (si elle a register un signal, elle ne sera ptet pas free)
"Si tu dois penser aux 2 bouts, ce n'est peut etre pas le bon pattern"

prototype

en gros : avoir une instance d'example et la cloner pour creer les prochaines (ce que je fais avec les ressources)
la partie sur JS peut etre interessante a creuser

singleton

en gros une FSM (finite state machine) ou chaque etat est encapsule dans une class
- donc mon joueur pourrait avoir une propriete PlayerState qui pourrait etre IdleState ou MovingState
- quand j'entre dans le MovingState ca pourrait changer le is_moving a ce moment
- pourquoi poas faire du pushdown, quand je veux stack differents etats ?

ca me semble un peut trop simple, peut etre que quelque chose m'echappe
dans le jeu, c'est la class Cube qui est a la base de chaque cube
c'est vrai que je pourrais mettre les interactions entre les cubes et le jeu seulement dans Cube pour reduire le coupling entre les subclass et le reste du jeu
- surtout si ca change un state
- a voir si les "forwarding" sont pertinents
c'est comme une facade, ou c'est la base classe qui cache tout

prendre le temps de decouper chaque class, voir comment je peut la rendre moins couplee avec le reste !