C++ find the most suitable design pattern for a general design issue

Question

I'm pretty exhausted trying to connect/link between practical issue to a theoretical equivalent .

I will choose a very very simple example trying to illusrate my problem.

Suppose I have a Worker class:

class Worker {
private : // default access modifier 
     int workerId;
};

Suppose I have a Table class:

class Table {
private : // default access modifier 
    int tableId;
};

Suppose I have a ResturantManager class:

class ResturantMangager
private: // default access modifier
    list<Table*> allTables;
    list<Worker*> allWorkers;
public:
    // the function should tell the worker that he should call one of its function,
    // its decision to what table to put the client returned by its function 
    // must be somehow updated in the allTables (mark the table he chose to put the client
    // as unavailable).
    void putClientInTable(const Worker& worker, const Client& client);
};

Now I want to allow the worker to put a client in one of the available tables and after that I want the Resturant's class data member allTables to mark this table (by ID lookup) as unavailable. That means that the Worker should be able to decide what table to choose (or the ResturantManager tells him - I can't see how It can be achieved differently) and then the ResturantManager's allTables must be updated either.

I'm looking a design pattern (http://sourcemaking.com/design_patterns) which most suitable to this idea.

Is there any design pattern approriate to this issue?

Thank you all.

Answer 1

"I'm just not sure if there is a design pattern which sutiable to this idea and I can use it. It is always better than inventing the wheel again?

A very agreeable approach. But to answer your question properly, you should ask yourself "what idea?". Patterns exist to solve general problems. Your problem deals with restaurants and workers, so as such, you might find it troublesome to choose a specific pattern.

Also, there is no such a thing as a "holy" design pattern to adopt in all situations. There isn't a design pattern which is suited for modeling restaurants, cars, or whatever. You have to abstract those details out of your model and figure out what is the essence of the problem you're solving.

What kind of relationship are you trying to establish between your classes? How shall these associations be navigated?

Programs are not static databases: they do something with your data, and your data structures should be designed in a way that best suits them for the kind of processing your algorithms are supposed to do. There is rarely such a thing as a "universally good" design. If someone tells you there his, listen to him with suspicion.

Is your program supposed to find out what table a certain customer is sitting at? Is it supposed to find out which customers are sitting at which table? Is it supposed to find out which waiters are serving which customer, or which table, or how many times each waiter has served the same table throughout the day?

In other words, what are the operational requirements of your program? How frequently is it likely to perform the above lookups? Are insertions expected to be more frequent than lookups? And lookups by name of a customer, or ID of a table, more frequent than just plain iterations over the whole set of tables/waiters/customers to print out a report?

You can't find the right design if you don't make it clear what should it be right for. So to sum up, there's two things you should do:

1. Identify (or at least try to make reasonable assumptions on) the operational requirements of your program;
2. Selecting the appropriate design pattern by reasoning in abstract terms, i.e. removing the details which are specific to your application domain.

Answer 2

A coupla thoughts.

• Your restaurant manager could probably just be the restaurant, as it contains the tables. Managers do not contain tables. :-)

• Workers and Tables should be kept in containers. The STL offers plenty.

• The function PutClientInTable could be a member of the Table class. That way you can tell if a table is occupied by "looking" at it (if you add "GetIsOccupied()" to the Table class).

• Restaurant could provide a public function "GetNextAvailableTable" for the workers to call.

Answer 3

As I see this, You want to keep updated about the status of all tables at anytime?

One design idea is to -maintain global data set in your parent or main class (in your example, Table* allTables in restaurant manager class). -write functions in your worker class which takes pointer of Table* as one of the arguments to work on. -call this functions with pointers to data set in main class.

Hope it helps.