It's a software design problem that creeps up in a bunch of contexts. In my world of scientific software, one frequently works with software implementations of mathematical models and algorithms. Frequently, these models have relationships with other models and they sometimes can even be categorized hierarchically. (For instance, numerical algorithms that perform integration.) If the goal is to build a library of related models (hey! modular, reusable), the level of code abstraction can become quite complex. Design by Contract concepts can be used to abstractly provide 'evaluate()' methods, but most models require model-specific information in order to evaluate properly. At some point the abstraction leaks and the developer is forced to write some massive switch or reflection statement to evaluate a particular algorithm with its specific arguments. At this point, the software design is broken.
This is just an exploration of a possible solution. I was reading an excellent overview article about the state design pattern and it got me brainstorming. I wondered if it could be re-purposed for the design problem stated above. I did some pen-&-paper work to sketch out my idea, but I needed to go further. So, like any software developer, I started thinking by writing -- code.
Well, it's the medium that I most frequently observe this problem in. Of course, the problem is language-agnostic, but languages have different ways of treating the problem. I'm fastest in Java, especially when thinking in DbC patterns. Oh, and I already have an example of this problem in another git repo and I'm shamelessly stealing code from it to work with.
To Be Continued...