If I were to solve this, adding the new code to the switch seems to me like overkill.

I would try writing an application that uses plugins in a searchable directory. Then you solve each problem in its own plugin and the main program just consists of the logic to find and execute the plugins.

Of course to enhance finding the plugins there could be several design decisions:

Name the plugin file by a given structure so it is obvious which problem is solved:

ep-001.dll
ep-002.dll
...

That has the problem of forbidding user defined names, however it offers efficiency in that you can directly load only the needed plugin if you know the number. The other solution is to give the plugin class (that you will need anyway for a common interface to query for the solution) a function that returns the problem number. This allows for arbitrarily named plugins, but also for duplicates and has the disadvantage of loading all plugins that are there to see if the one containing the requested solution is there.

Since you are not that much efficiency bound on this problem I would suggest the second alternative because it has a much nicer OO interface (IMHO).

If I were to solve this, adding the new code to the switch seems to me like overkill.

I would try writing an application that uses plugins in a searchable directory. Then you solve each problem in its own plugin and the main program just consists of the logic to find and execute the plugins.

Of course to enhance finding the plugins there some possible designs:

Naming the plugin after the solved problem

Name the plugin file by a given structure so it is obvious which problem is solved:

ep-001.dll
ep-002.dll
...

That has the problem of forbidding user defined names, however it offers efficiency in that you can directly load only the needed plugin if you know the number.

Give the plugin class a problemNumber function

The other solution is to give the plugin class (that you will need anyway for a common interface to query for the solution) a function that returns the problem number. This allows for arbitrarily named plugins, but also for duplicates and has the disadvantage of loading all plugins that are there to see if the one containing the requested solution is there.

Since you are not that much efficiency bound on this problem I would suggest the second alternative because it has a much nicer OO interface (IMHO).

If I were to solve this, adding the new code to the switch seems to me like overkill.

I would try writing an application that uses plugins in a searchable directory. Then you solve each problem in its own plugin and the main program just consists in the logic to find and execute the plugins.

If I were to solve this, adding the new code to the switch seems to me like overkill.

I would try writing an application that uses plugins in a searchable directory. Then you solve each problem in its own plugin and the main program just consists of the logic to find and execute the plugins.

Of course to enhance finding the plugins there could be several design decisions:

Name the plugin file by a given structure so it is obvious which problem is solved:

ep-001.dll
ep-002.dll
...

That has the problem of forbidding user defined names, however it offers efficiency in that you can directly load only the needed plugin if you know the number. The other solution is to give the plugin class (that you will need anyway for a common interface to query for the solution) a function that returns the problem number. This allows for arbitrarily named plugins, but also for duplicates and has the disadvantage of loading all plugins that are there to see if the one containing the requested solution is there.

Since you are not that much efficiency bound on this problem I would suggest the second alternative because it has a much nicer OO interface (IMHO).