Class: module:sim/command/Commander

Both the command pattern and the memento pattern are used here. Commands are performed to make changes to the mementos. Memento Pattern: Caretaker: ConfigKeeper class. It keeps config as a list of mementos. Originator: sender returned by CommandStore.addSender, used by menuItem, Candidate, Voter, etc Mementos: Config is a list of mementos. It's not a strict pattern. Also, the way we are storing commands is like storing mementos of a commands (not strictly). Command Pattern: * Client: a CandidateCommander, VoterCommander, MenuItem, etc * Command: Here, a command is a memento of a way to make a command. CommandStore stores lists of ways to make commands. mostly with a name and an action. Also, History stores a list of commands. Sender: A sender is returned by CommandStore.addSender. Receiver: a property of a Candidate, Voter, MenuItem, etc. For example, Candidate.setXY calls CandidateCommander.setXYSenderForList.go(id, value), which then calls Candidate.setXYAction to set Candidate.x and Candidate.y This isn't exactly either pattern. Instead of commands with execute functions, we use CommandStore, a class that stores lists of ways to make commands, given parameters. Instead of mementos, the lists of ways to make commands act as mementos. Initially, the three component classes here were part of one larger class, but hopefully it is easier to read code that is shorter and sticks to one context. This class is similar to the mediator in the mediator pattern. References: * [Command Pattern on refactoring.guru](https://refactoring.guru/design-patterns/command) * [Memento Pattern on refactoring.guru](https://refactoring.guru/design-patterns/memento) * [Mediator Pattern on refactoring.guru](https://refactoring.guru/design-patterns/mediator)