You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The class model that you propose does not reflect the actual interaction between a Hotel, its Rooms and its Food services. This lack of a proper model also causes a series of SOLID violations, which limits the program's flexibility and expansion.
SOLID violation:
A monolithic Hotel class that, violation of SRP
Abuse of switch in the Hotel functions, violation of OCP
Lack of abstraction for the customer, violation of DIP
Lack of abstraction for the gender, violation of DIP
Poorly implemented inheritance, LSP violation
These violations also reflect misuse of OOP, instead of storing data as classes itself. instead of using switches for saving these properties like the price of only 4 food items and only for types of bedroom, burning ta values in code instead of depending on variables and abstractions.
The proposed new model separates the responsibilities of the Hotel into the classes Floor, Reception and Restaurant breaking down the monolithic Hotel class. The abstraction of the customer as the class Client provides an abstraction that also supports the use of the collection for saving n number of customer in the new Booking class, which take care of all services related to the customer time in the Hotel like its Room and the Food order from the restaurant. This last service is supported by Food_order, which provides an abstraction for every food service used by the Client.
The class Floor allows easy management of Rooms, which now contain all the attributes of an actual room and every single one can be configured with the necessary price, capacity and luxury or not luxury. This also eliminates the use of inheritance for the room, which in a real Hotel will not make sense.
A reflector version of the code applying this model can be found here: https://github.com/gabreilAlexKH/Tarea_SOLID.git
This just incorporates the new model and gets rid of the overuse of switches in the methods. The logic of the methods is kept, but now they accept the Room or the Room´s Floor or its current Booking as parameters. But it does not support Exception handling as the original one and the long-term storage has been eliminated, because it did not work in the original.
The main class has suffered minor modifications, just eliminating the switches for options 4 and 5:
If you have any questions, please refer to the above-mentioned repository.
The text was updated successfully, but these errors were encountered:
src/Main.java:302: AvoidDuplicateLiterals: AvoidDuplicateLiterals: The String literal "===============" appears 4 times in this file; the first occurrence is on line 302
src/Main.java:302: SystemPrintln: SystemPrintln: Usage of System.out/err
src/Main.java:303: AvoidDuplicateLiterals: AvoidDuplicateLiterals: The String literal "Item Quantity Price" appears 4 times in this file; the first occurrence is on line 303
src/Main.java:303: SystemPrintln: SystemPrintln: Usage of System.out/err
src/Main.java:304: AvoidDuplicateLiterals: AvoidDuplicateLiterals: The String literal "-------------------------" appears 4 times in this file; the first occurrence is on line 304
Duplication object and field violate the OOP design
This message is for educational purposes:
The class model that you propose does not reflect the actual interaction between a Hotel, its Rooms and its Food services. This lack of a proper model also causes a series of SOLID violations, which limits the program's flexibility and expansion.
SOLID violation:
These violations also reflect misuse of OOP, instead of storing data as classes itself. instead of using switches for saving these properties like the price of only 4 food items and only for types of bedroom, burning ta values in code instead of depending on variables and abstractions.
The proposed new model separates the responsibilities of the Hotel into the classes Floor, Reception and Restaurant breaking down the monolithic Hotel class. The abstraction of the customer as the class Client provides an abstraction that also supports the use of the collection for saving n number of customer in the new Booking class, which take care of all services related to the customer time in the Hotel like its Room and the Food order from the restaurant. This last service is supported by Food_order, which provides an abstraction for every food service used by the Client.
The class Floor allows easy management of Rooms, which now contain all the attributes of an actual room and every single one can be configured with the necessary price, capacity and luxury or not luxury. This also eliminates the use of inheritance for the room, which in a real Hotel will not make sense.
A reflector version of the code applying this model can be found here: https://github.com/gabreilAlexKH/Tarea_SOLID.git
This just incorporates the new model and gets rid of the overuse of switches in the methods. The logic of the methods is kept, but now they accept the Room or the Room´s Floor or its current Booking as parameters. But it does not support Exception handling as the original one and the long-term storage has been eliminated, because it did not work in the original.
The main class has suffered minor modifications, just eliminating the switches for options 4 and 5:
If you have any questions, please refer to the above-mentioned repository.
The text was updated successfully, but these errors were encountered: