Problems With SOLID Methodology

S - Single Responsibility Principle
A class should have one and only one reason to change, meaning that a class should have only one job.
- This is the opposite of Object Oriented programming where a class is a group of related elements and the methods that use those elements (all wrapped into one class).
- This principle causes all the methods that use a group of data elements to be scattered all over the place.
- It's difficult to find where all the code is relating to that object.
- The objects in Object Oriented programming are real. They exist in real life and they exist in the database.
- By breaking up all the functions of what is a representation of a real world object into multiple classes, you make the concept of inheritance and polymorphism difficult.
O - Open-Closed Principle
Objects or entities should be open for extension but closed for modification.
- Think about that. Closed for modification? You can't modify it? What if you need to modify it? Are you going to make a copy of it and call the copy? Yes, you are. Because it might be reused somewhere. Modifying it might break something else. Welcome to the fear . . . Fear of making changes.
L - Liskov Substitution Principle
This means that every subclass or derived class should be substitutable for their base or parent class.
I - Interface Segregation Principle
A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.
- How I see this get implemented is that every class has an interface. The interface is used instead of the class. Then, every time you want to change a class, you have to change its interface also. This is helpful for unit testing using Moq. But you shouldn't be doing unit testing. You should be doing integration testing. The problem with unit testing is that the units might work, but when you connect them together, it fails. If you're going to have to do integration testing anyways, then you don't need unit testing. If all your API does is call a stored procedure, then that stored procedure that tests it is your integration test.
D - Dependency Inversion Principle
Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.
- This is where they try to break up the API into a bunch of little classes that are in a heirarchy of abstract classes working down to concrete classes.
- This causes code to be put in many classes. If you have to change one, you probably have to change all of them.
- They'll often put these different classes of this heirarchy in different folders.
- They might even have different classes in this heirarchy in different projects.
- I hope that you can debug it by pressing F11 to step into the child class.
- If one of their hops uses Client.PostAsJSONAsync, F11 won't work. You can't step into the next level because the rest of the abstraction is in a different process.
- Most web applications don't need that complexity. There's data in the web page. The user changes the data. The changes get saved. There are different web pages with different data on each page. There's some data entry, some searches. Inserts and deletes and updates. It's simple stuff. You don't need an abstract heirarchy. Just send the data to the stored procedure and do the update.