Adding polymorphism for easier maintenance does not mean "enterprise fizzbuzz". I'm talking about one 1 abstract class to define the interface and 1 implementat

Adding polymorphism for easier maintenance does not mean "enterprise fizzbuzz". I'm talking about one 1 abstract class to define the interface and 1 implementation class per package manager. That's N+1 classes (N = # of package managers). It means all logic for a specific package manager is gathered in one place instead of spread out over many files and the compiler can prevent us making stupid mistakes like forgetting to add a subcommand or mistyping the packagename in the big if/if/if statement. In the current implementation we have (X = numberOfPMs*numberOfCommands) string compares which are not checked by the compiler. That means X potential typo's that each need a unit test just to verify that the implementation is hooked up correctly. I would say that a class based implementation like this is simpler and prevents more errors during maintenance than the current version. Don't put down OOP and classes just because hating on GoF patterns is all the rage in 2018, they exist for a reason. This is a clear case for applying them.