Feature flags revisited

Feature flags have always made me feel ambivalent. On one hand, I can relate to the need for having a mechanism to easily enable or disable particular features, while on the other hand, being a software engineer I pretty much loathe this concept, since feature flags make your code ugly more often than not. Especially if such a flag is left in place even after its corresponding feature has become fully operational, eliminating any practical need to be turned off on demand.

Cliché ahead in 3,2,1: not everything in life is black and white, and sometimes, even in the face of feature flags, we can still, well, save face.


Basically the options fall into the following categories:

Hard coded if statement

boolean enabled = true;

if(enabled) {
  feature.activate();
}

Configurable if statement

// "enabled" is injected using DI
MyCtor(boolean enabled){
  this.enabled = enabled;
}

// later on in your code
if(enabled) {
  feature.activate();
}

Hard coded polymorphism

MyFeature feature = new MyFeatureImpl();

// replace above line with this one to disable the feature
//MyFeature feature = new MyFeatureDummyImpl();

// this line doesn't know if it's activating the real feature, or the dummy one.
feature.activate();

Configurable polymorphism

// enabled can be injected using DI
MyFeature feature = enabled ? new MyFeatureImpl() : new MyFeatureDummyImpl();

// this line doesn't know if it's activating the real feature, or the dummy one.
feature.activate();


The configurable polymorphism looks almost bearable.
Taking it one step further, one could give up the if statement determining what implementation to initialize, by simply injecting the appropriate one. The downside of it is that in order to switch between the two implementations (the real one and the dummy) one would have to create two different beans, and manually wire things properly (i.e., inject the correct bean). It's definitely a feasible solution, though a bit too delicate, in my humble option, since it requires manually tossing beans around.

It would be great to get the simplicity of a configurable boolean flag along with the elegance of polymorphism, enter Spring Expression Language (SpEL).

Suppose we create 2 beans, a dummy implementation which effectively disables a feature, and the real one, with ids "myFeatureDummyImpl", and "myFeatureImpl" respectively, SpEL allows us to do the following:

<bean id="myLogic" class"bla.bla.yada.yada.MyLogic">
  <constructor-arg ref="#{${enabled} ? 'myFeatureImpl' : 'myFeatureDummyImpl'}"
</bean>

Now all we have to do in order to enable or disable our feature is to set the ${enabled} property to either "true" or "false", no need to explicitly temper with beans or bean ids.

Comments

  1. Oh, wow, I had absolutely no idea you can use boolean expressions like that in spring.
    This is so cool.

    ReplyDelete

Post a Comment

Popular posts from this blog

Eclipse vs. IntelliJ, an empirical rant

Reflecting on reflection in Scala and Java