Decision making and maintenance

Question

I'm trying to find an elegant way to implement a decision making algorithm that allow easy maintenance because the conditions for the decision making might change often.

I'm going to try and be more specific with an example here :

Let's say I'm trying to manage a team of Cooking chefs in a restaurant kitchen.

Every chef knows how to cook 3 types of pies : Apple pie, pumpkin pie and raspberry pie and 2 types of pizza : cheese pizza and bacon pizza. They all know how to cook everything.

Now, I would like to send orders to these chief regarding what's coming for the clients.

The conditions are :

A chief can only cook one pie at a time. If I order a chef to cook an apple pie for example, I cannot order him to cook a raspberry pie or a pumpkin pie unless the apple pie is done or I send an cancel request for the apple pie.

I can ask a chef to cook up to 5 pizzas at a time, given it's for different clients.

I woud like to create an algorithm that returns the set of orders I'm allowed to send to a specific chef, regarding what he already is cooking.

I'm working with c++. I could write a simple switch/case statement, but the maintenance would not be easy if conditions change or new pies are added, and so...

I'm kinda stuck and really don't see how I could encapsulate the conditions and decision making to decrease couplign beetween conditions and to allow easy maintenance on the conditions of pie cooking.

How would you handle complexe decision making algorithm implementation?

Answer 1

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.

Answer 2

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.