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.