The data consists of Chefs, Orders and a single Schedule. Note that Chefs rarely change, but Orders are constantly being created, removed and optionally edited, and the Schedule has to change in response.

The logic for the new Schedule really depends on all of the data including Chefs, Orders and the old Schedule. For that reason you really need to keep the scheduling logic together in a single place such as a Scheduler class.

Using test-driven development is really well suited to this problem. Start by writing unit tests for the simple cases and then build up to more complex ones where the Chefs already have stuff in their queue and then new orders come in or get removed or edited. Then in your Scheduler class, just write the most straightforward logic you can think of to express the rules. You are completely free to use whatever internal architecture or structure you want. Don’t get too complicated or tricky. Whenever you see an opportunity to make the logic simpler and easier to understand, do it, and just make sure all your tests still pass.

Now when you want to make a change, you add a new test case, and modify existing no-longer-correct test cases, and then you modify the logic of Scheduler until all the tests pass again. In this way you know you won’t break existing assumptions or logic.

I have used this successfully on several similar problems.

I can’t see this needing a switch statement. Here’s how I would design this. I would have some sort of controller or manager object, that assigns tasks. This object would know

• a list of chefs
• a method you can call on a chef, like “are you free?”
• a method you can call on a check to ask if it’s capable of cooking something, assuming it’s free

You ask this object “get me someone to do a raspberry pie” and it loops through the chefs till it finds a free one, asks if it can do raspberry pie, and if so, assigns that to it.

Meanwhile in the chef object you need to know what you can cook, your capacity of each thing, and what you’re cooking right now. You’re not cooking anything, you get asked if you’re free, you say yes, you get given something to cook so you track that, and if you’re asked again before it’s finished, you say no.

With your complication of one pie but five pizzas, you might combine the “are you free” and “can you cook” questions into “are you free to cook X?” which you would say no to whether it’s because you don’t know how or because you’re busy. That way someone with two pizzas on the go will say yes to a pizza but no to a pie.

The assigner object also needs to figure out what it will do if all the chefs say they are busy. Probably wait and ask again since chefs will finish what they’re doing and become free. You might do this with pause-and-poll, or by having chefs signal the assigner once they’re free.

The key to me is that the chefs know what and how much a time they can cook, not the assigner. The assigner knows how many chefs there are. Adding new pies means updating the chef class (possibly just a recompile if the list of pies is an enum and all chefs can always cook all kinds of pie) and whatever code decides that it’s time to make raspberry pie now. Generally the assigner code won’t need to change under these circumstances – it’s still looping through the chefs asking “can you do a cheese pizza yes or no?” and if it gets yes, assigning that to the chef and returning.