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
Hi, me and my team where checking your project and we wanted to suggest you some changes in orden to apply the S.O.L.I.D principles.
SRP, this principle states that every module or class should have responsibility over a single part of the functionality provided by the software and since everything is in one class you are violating it. One way of solving this is making a separted class for the operations, in your project you use a method called calc for solving the math problems, so in this new class Operation we can have this method, and at the same time apply the principle giving this classs the single responsability to calculate each operation.
Now by making this another problem comes along, now we are violating the DIP principle because it states that "High-level modules should not depend on low-level modules. Both should depend on abstractions", thats why we can make a new package Operations, and inside this one create a father class Operation and each of the possible operation (such as Add, Substract, etc) child classes. Also by doing this we are applying the LSP principle correctly because it states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program, and here each subclass (child) will recieve the same parameters (double x, double y) and return a result.
Thank you for your time, I apologize in case I said something mistaken.
The text was updated successfully, but these errors were encountered:
Hi, me and my team where checking your project and we wanted to suggest you some changes in orden to apply the S.O.L.I.D principles.
SRP, this principle states that every module or class should have responsibility over a single part of the functionality provided by the software and since everything is in one class you are violating it. One way of solving this is making a separted class for the operations, in your project you use a method called calc for solving the math problems, so in this new class Operation we can have this method, and at the same time apply the principle giving this classs the single responsability to calculate each operation.
Now by making this another problem comes along, now we are violating the DIP principle because it states that "High-level modules should not depend on low-level modules. Both should depend on abstractions", thats why we can make a new package Operations, and inside this one create a father class Operation and each of the possible operation (such as Add, Substract, etc) child classes. Also by doing this we are applying the LSP principle correctly because it states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program, and here each subclass (child) will recieve the same parameters (double x, double y) and return a result.
Thank you for your time, I apologize in case I said something mistaken.
The text was updated successfully, but these errors were encountered: