We must find a more elegant way to provide the arithmetic conditions of each strategy. Consider the NoFizzNoBuzzStrategy, how neat would it be to store the rules in a nicely formatted XML. You could use Guice's Builder pattern to provide a multi-stage target adaptive nested configurable constructor pattern that generates all the necessary code on the fly. Coupling this with a config parser, we can still exploit this change even when we switch to a MicroServices architecture, we will just request an updated config from the ESB whenever we need it.
I always wanted to combine the builder pattern and factories at the same time. If, by looking at them, you think we got too many of them anyway, feel free to use a FactoryFactoryFunctorGeneratorProxyBeanFactory<? super T implements AbstractFactory>.
We must find a more elegant way to provide the arithmetic conditions of each strategy. Consider the NoFizzNoBuzzStrategy, how neat would it be to store the rules in a nicely formatted XML. You could use Guice's Builder pattern to provide a multi-stage target adaptive nested configurable constructor pattern that generates all the necessary code on the fly. Coupling this with a config parser, we can still exploit this change even when we switch to a MicroServices architecture, we will just request an updated config from the ESB whenever we need it.
I always wanted to combine the builder pattern and factories at the same time. If, by looking at them, you think we got too many of them anyway, feel free to use a FactoryFactoryFunctorGeneratorProxyBeanFactory<? super T implements AbstractFactory>.
See for example this file. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition/blob/master/src/main/java/com/seriouscompany/business/java/fizzbuzz/packagenamingpackage/impl/strategies/NoFizzNoBuzzStrategy.java