This is my first project where we have tried our best to incorporate the OOPS principles. No database has been used since the project aim was to understand OOPs principles and simple text files have been used for the same. Also, not all our OOPs principles are correctly implemented, but it’s a first attempt, so please look out for errors!
The demo of the working product can be viewed here.
Assumptions:
1. Reservations are made for a future date only. Time slots e.g. 12-2pm, 2-4pm are booked for each reservation, hence, once the time has passed, the reservation is automatically considered void.
2. Each time the application is run, it is assumed that a new staff changes their shift. No database for staff has been included.
3. Real World time hasn’t been implemented in the code, the time and date are manually inserted by the staff for ease of testing the working of the app.
4 . When an item is removed from the main menu, it is assumed that the staff will manually also remove any promotional set that contains the menu item.
The code can be found on my github
Class Diagram:
For a better resolution image click here.
Sequence Diagram for making a reservation:
OOPS DESIGN CONSIDERATION
1. SINGLE RESPONSIBILITY PRINCIPLE: Each class is designed for one specific responsibility. For example, the “menu” classes (eg. mainCourseMenu) are designed to update/change the dish objects (mainCourse), whereas the information of “mainCourse” is all stored in text file. Therefore, “convertFromFile” class is created specially in charge of File I/O. Hence, “menu” classes will not take responsibilities of converting between text files and the program, and it is even better to be able to reuse “convertFromFile” in other places.
2. OPEN FOR EXTENSION/CLOSED FOR MODIFICATION PRINCIPLE: For instance the class items, that extends main course, dessert and drinks. The items class is closed for modification, however open for extension. Each subclass one has its own new attributes e.g. vegetarian or not, hot or cold, contains wafers or not etc. For ever new kind of item in the menu, we don’t need to modify the items class. However, we can extends it and add a new kind of item say, Snacks with a few new attributes and functions.
3. LISKOV SUBSTITUTION PRINCIPLE: In our “restaurant”, when an “order” is created, the dishes are added, changed or removed in type of “menuItem”, which is an interface implemented by “items”,and eventually dessert, menu, drinks and promotional items. However, the actual item added/removed are the instances of “mainCourse”, “drinks”,etc. Therefore, the object type used here is the sub-class of the sub-class of“menuItem”, and they work out simple, efficient and fine.
4. INTERFACE SEGREGATION PRINCIPLE: In our project, classes such as “items” and“promotionalSetPackage” implement multiple interfaces, which makes interfaces short and clear. This also makes program efficient, because for different class, only useful but short interfaces are used.
5. DEPENDENCY INJECTION PRINCIPLE: High-level modules should be independent from the low-level modules. For example, higher level module “MenuApp” creates, updates, removes and displays “menu”, not knowing the implementation of lower level or even what exactly is passed in, “mainCourseMenu”, “drinkMenu” or else. Hence, injecting lower lever modules into the higher level modules makes higher level modules more independent, and more likely to be reuse.To sum up our design considerations, the goal is to make the programs reusable, extendable, maintainable and the whole system work well.
bhavya0x83b 