While the current implementation works, there are some improvements that can be made with the naming and structure of what is currently in the CommandRegistry module.
Some thoughts -
Inside the context of the CommandRegistry, adding Command to a prefixed action (removeCommand, getCommand, etc.) is redundant and add no value. (could be pointed to CLEAN-CODE.md#dont-add-gratuitous-context as an example)
Ensure the distinction between CommandDefinition and program.Command is made and we are not unintentionally swapping the two. While right now the CommandDefinition interface is the primary object we use to register program.Command objects, they are not the same thing, and should not be used interchangeably
A lot of the logic for retrieving, transforming, etc. of CommandDefinitions should be pulled out into a shared module/object. Stuff like mapping, filtering, sorting will quickly be done all over the place and it will be better to consolidate where that is happening. It does not directly relate to the registration of commands, and can be used elsewhere.
Same goes for the retrieval, sorting, mapping of the actual program.Command objects. This might make more sense as a utility class so that it isn't cluttering up the logic in CommandRegistry
This issue is a high level note of the work to be done based on a refactoring session. I expect to be the one that takes this on, but I am more than happy to pair with someone or answer any questions someone might have if they would like to take on some of the work before I get back to it.
While the current implementation works, there are some improvements that can be made with the naming and structure of what is currently in the
CommandRegistrymodule.Some thoughts -
CommandRegistry, addingCommandto a prefixed action (removeCommand,getCommand, etc.) is redundant and add no value. (could be pointed to CLEAN-CODE.md#dont-add-gratuitous-context as an example)CommandDefinitionandprogram.Commandis made and we are not unintentionally swapping the two. While right now theCommandDefinitioninterface is the primary object we use to registerprogram.Commandobjects, they are not the same thing, and should not be used interchangeablyCommandDefinitions should be pulled out into a shared module/object. Stuff like mapping, filtering, sorting will quickly be done all over the place and it will be better to consolidate where that is happening. It does not directly relate to the registration of commands, and can be used elsewhere.program.Commandobjects. This might make more sense as a utility class so that it isn't cluttering up the logic inCommandRegistryThis issue is a high level note of the work to be done based on a refactoring session. I expect to be the one that takes this on, but I am more than happy to pair with someone or answer any questions someone might have if they would like to take on some of the work before I get back to it.