I have to design a simple server-client model for the billing system of some fictitious restaurant.
After spending about 10-15 hours on the UML diagram, I haven’t gotten that far. The main issue I am struggling is with the client side OO design.
The current two ideas are:
Design A
In this design, I am essentially stuffing all things related to handling menus, tables and any other restaurant related object into a single class (Client). That being said, it poses a scalability issue and also violates the single responsibility principle of OO design.
However, it greatly simplifies the communication between the Client class and things it needs to handle (e.g. Menus) since they are part of the Client class.
Design B
In this design, tasks are much more distributed for the client side. For instance, the Client class will be dealing with restaurant objects (i.e. menu and tables) through instantiated objects rather than directly.
Also, for the Menu/Table classes to access the Database class, they must go through the Client class which means there must be some communication between the Client and the Menu/Table classes. For this purpose the abstract Request class exists. It essentially stores things up in a queue which the Client class can then later on pickup.
But now the design already feels convoluted especially the path that a request will take; a request will be raised in the Client class which will then passed down into an instantiated Menu/Table object, thereafter it will be picked up by the Client class hence a loop (Client –> Menu/Table –> Client).
So at the end of the day, which design should I choose and how can I improve on them?
Design C
At the end of the day, Design C is what I ended up using:
- It removes the superfluous need for the Requests class between the Client and the objects it uses compared to Design B.
- It is by far much more OO than Design A.
I think you are missing a Restaurant class and a Reservation class.
- A restaurant has a fixed-size collection of tables
- A reservation links a client to a table for a period of time (which is just a date in your example).
Think of it in real-world terms – you contact a Restaurant to make a reservation for a particular date. You may call to cancel that reservation. Modelling the real-world will simplify your coding immensely.
With your design C, you have a method client.findEmptyTable(). This is odd – surely it should be something along the lines of restaurant.findEmptyTable(date).
Also, this question is probably more suited to the Code Review forum.