Instead of creating multiple instances of the Command and CommandData in CommandBuilder.build, we can create single Command and store the aliases as List<String> and in BuildEnvironment.addCommand we can point primary name and each aliases to same instance of the Command.
Benefits:
Lookup time won't be affected. As we will still search the commands by LinkedHashMap#get, so the lookup time will still be O(1).
Startup of the application will get reduced, due to less work to do (not creating multiple soft copies of same command).
Heap size will be smaller.
Better to generalize the commands i.e. when creating a "help" command or something like that, we want to put aliases of commands together, and in current architecture we have to iterate through all the Command instances which are both alias and parent to respond with a message which will be expensive.
Will be easier to lookup for the other aliases, in current architecture if we want to find all the aliases for a command by one of its alias, we have to go through find Command instance representing alias then find parent command name from the aliasInfo and then re query the commands to find the parent Command instance cast its aliasInfo to AliasInfo.Parent then get list of all aliases.
Instead of creating multiple instances of the Command and CommandData in CommandBuilder.build, we can create single Command and store the aliases as
List<String>and in BuildEnvironment.addCommand we can point primary name and each aliases to same instance of the Command.Benefits: