thought-works: Object oriented design for a Restaurant
Let us do the OO-design for a Restaurant today. Let me first describe how the restaurant we want to model works. These are the different actors in the model and i have listed the different actions against each actor
* Customer
Above is the class diagram for the restaurant we described above. To keep the matter simple i have assumed certain things like customer not changing his order once placed, customer not cancelling the order, unlimited queue size for pending queue and finished queue. However accommodating these exceptions is relatively easy. Just like the Coffee shop design here also there is asynchronous nature to the order processing which can neatly handled via messaging.
http://thought-works.blogspot.com/2015/12/restaurent-design-another-round.html
The different players are
Our next milestone is to design classes to support the above use cases. Without much difficulty we can arrive the need for classes Customer, Cashier, Chef and Waiter and their operations(Actors in the use cases have their classes).
In the use case model we are talking about adding order to queue, adding cheque request to queue. These queue classes are also part of the class diagram accordingly. I did not mention the operations and attributes of *Queue classes as they are obvious.
Restaurant's operations typically are table centric(what i mean is they typically talk in terms like a barbecued chicken for table no 1, prepare the cheque for table no 5 etc). In this system we just need to store the details like customer name (this also is not mandatory at least would be helpful to address him in the bill/custom feedback form).
But any point of time we should have information of what orders are coming from which table, which customer is seated at which table. (Putting the table id into the customer object is not the right thing to track the customer table association as table id does not naturally look to be an attribute of a customer object).
Similarly we need to know which orders are coming from which table( it is actually customers seated at that table). Here also storing table id in order to track the association does not seem correct.
We use two maps to track the association between customers and tables, tables and orders.
Table: capaciy
Read full article from thought-works: Object oriented design for a Restaurant
Let us do the OO-design for a Restaurant today. Let me first describe how the restaurant we want to model works. These are the different actors in the model and i have listed the different actions against each actor
* Customer
- Selects the dish from the menu and call upon a waiter
- Places the order
- Enjoys his meal once the dish is served on his plate
- Asks for the bill
- Pays for the services
* Waiter
- Responds to the customers calls on the tables he is waiting
- Takes the customer's order
- Places the order in the pending order queue
- Waits for the order ready notifications
- Once notification is received, collects the dish and serves the dish to the corresponding customer
- Receives the bill request from customer
- Asks the Cashier to prepare the bill
- Gives the bill to the customer and accepts the payment
* Cashier
- Accepts the prepare bill request from the waiter for the given order details
- Prepares the bills and hands it over to the waiter
- Accepts the cash from the waiter towards the order
* Chef
- Gets the next order from the pending order queue
- Prepares the dish and push the order to finished order queue
- Sends a notification that the order is ready
Please take a look at the Coffee Shop Design as the restaurant design we are attempting here is derived from that. The differences between a Coffee shop and Restaurant are
- In a coffee shop there is no waiter. Customer selects the dish and directly places the order with the cashier. In a restaurant there is the waiter who handles all the interaction with the customer.
- In a coffee shop, customer upon getting notified that the order is ready, he collects the coffee himself. He waits for the order ready notification. In a restaurant, waiter waits for the order ready notification and once ready serves the dishes to the customer.
 |
| OO design for a restaurant |
Above is the class diagram for the restaurant we described above. To keep the matter simple i have assumed certain things like customer not changing his order once placed, customer not cancelling the order, unlimited queue size for pending queue and finished queue. However accommodating these exceptions is relatively easy. Just like the Coffee shop design here also there is asynchronous nature to the order processing which can neatly handled via messaging.
http://thought-works.blogspot.com/2015/12/restaurent-design-another-round.html
The different players are
- Customer
- Waiter
- Chef
- Cashier
Our next milestone is to design classes to support the above use cases. Without much difficulty we can arrive the need for classes Customer, Cashier, Chef and Waiter and their operations(Actors in the use cases have their classes).
In the use case model we are talking about adding order to queue, adding cheque request to queue. These queue classes are also part of the class diagram accordingly. I did not mention the operations and attributes of *Queue classes as they are obvious.
Restaurant's operations typically are table centric(what i mean is they typically talk in terms like a barbecued chicken for table no 1, prepare the cheque for table no 5 etc). In this system we just need to store the details like customer name (this also is not mandatory at least would be helpful to address him in the bill/custom feedback form).
But any point of time we should have information of what orders are coming from which table, which customer is seated at which table. (Putting the table id into the customer object is not the right thing to track the customer table association as table id does not naturally look to be an attribute of a customer object).
Similarly we need to know which orders are coming from which table( it is actually customers seated at that table). Here also storing table id in order to track the association does not seem correct.
We use two maps to track the association between customers and tables, tables and orders.
Table: capaciy
Read full article from thought-works: Object oriented design for a Restaurant
