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:
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.
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?