Yup. See, this is why I struggle to recommend this book. > In some ways, the Command pattern is a way of emulating closures in languages that don’t have them.

Yup. See, this is why I struggle to recommend this book. > In some ways, the Command pattern is a way of emulating closures in languages that don’t have them. ... > For me, the usefulness of the Command pattern really shows how effective the functional paradigm is for many problems. So close, yet so far. The Command pattern is a brilliantly useful pattern, and I've seen it used to great effect; but it's not remotely about callbacks or closures; thats just an implementation detail. You're completely right, do you really need a JumpCommand, a JumpCommandHandler, and an UndoJumpCommand (?? What does that even mean?) when you could just have one class, called Player, with a method `jump`? No. You don't. It's a daft example. The Command pattern is about have composable atomic state transactions over your game state. For example, if you have a SpawnMonsterCommand, and a ApplyStatusEffectCommand, you can create a hoard of raging monsters using a SpawnHoardCommand; that calls the SpawnMonsterCommand 100x and then calls ApplyStatusEffectCommand to the monsters. Then you can have a SpawnBattleCommand that calls SpawnHoardCommand twice, with a different faction, or say, three times with 3 different factions to generate a battle. Or perhaps you're using an async resolution model, where you're commands are like MoveToLocationCommand, and AttackTargetCommand; and you need to start the MoveToLocationCommand then wait for it to finish before you run the AttackTargetCommand. Abstracting the functionality into small chunks lets you easily build complex chained behaviour, and you can even test it easily because each 'Command' is an isolated and known behaviour. ...but yeah, totally. A flurry of classes. Don't use it if you don't get some value from it. Having an undoable 'JumpCommand' falls firmly into the 'dont bother' category.