4 ms·
I don't really see what this program would gain from an "enterprise fizzbuzz" implementation. It is simple, it works, everyone can understand the code and upda
by xaedes 8y ago
I don't really see what this program would gain from an "enterprise fizzbuzz" implementation.
It is simple, it works, everyone can understand the code and update it.
That is actually very valuable, especially for a project like this which tends to need maintenance to keep alive (whenever some wrapped command changes).
- vbsteven 8y agoAdding 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.
- xaedes 8y agoI think the best point for class implementation you mention is to have all the related stuff in one place. That convinces me most =)