What are good/common practices to manage disabling/enabling functionality items in GUI applications for different licenses/permissions?

Question

I have worked on two different desktop applications and both had the problem of enabling/disabling functionality and associated GUI elements depending on available licenses or "user-roles".

In the first application I worked on, a mess was created by cluttering the code with conditionals that checked for certain licenses. I now work on another application for which work has just recently started and where a similar problem occured. Now I am looking for a good way to solve the problem in a "better" way.

The problems with the system we had were:

• We had many many places in the code that looked like
  if( !check_license( MY_LICENSE ) ) myWidget->setVisible(false);
  or
  if( !check_license( MY_LICENSE ) ) return;
  These kind of lines cluttered the code in many places and were hard to maintain when a piece of functionality should be disabled/enabled for a certain license.

• Sales people often asked: "Can I do this and that with licence xy?" We had a table in a wiki that tried to solve that problem but it was rather coarse grained so we often had to look into the code to find the answer.

So here is the question:
How can one reduce the "clutter-effect" and what are the best ways to have a central register for functionality items.

I think the sollution should contain the following concepts.

• The notion of a functionality item, that is explicitly mentioned in the code.
• The notion of a functionality block to which multiple functionality items can be asigned.
• An entity "FunctionalityRegister" that allows registering functionality items with functionality blocks that can print a list of functionality items for each functionality block
• An entity that can be asked if a functionality item is currently enabled

I have not concrete ideas how one can reduce the number of places where the program asks if an functionality item is enabled. I would like to here your ideas on that problem.

I would also like to see sugestions for techniques that reduces the "code-size" of one enabledness request to a minium. This is dependent on the used technology so I have to mention that we use C++/Qt.

How was the problem solved in the applications you know and what where the advantages and disadvantages?

Answer 1

I have not concrete ideas how one can reduce the number of places where the program asks if an functionality item is enabled.

That isn't needed. If a functionality involves changes to the user interface in 7 places, then there must be 7 places that check haveFeature(Bit.TIME_TRAVEL) in the code base. This is not a violation of DRY.

What should be reduced, preferably to 1, is the number of places that determine the behaviour of haveFeature(). Ideally, both the code base and your user support pople will take this knowledge from one and the same authoritative document. For instance, you could maintain a list/spread sheet/interpretive dance choreography/whatever in your version-controlled repository and auto-generate both the internal user-support web page and the decision code within haveFeature() from it, as a normal part of your build process.