The first mistake people make is to think that Uncle Bob is the creator of SOLID. This acronym was created by Michael Feathers. And the concepts individually were created by other people, although Robert Martin gave his version of how each of the 5 items should be interpreted. So SOLID is one of those things that everyone understands in a way, and therefore no one knows for sure what it is, and it does not serve as a good parameter, but are good tips to think and discuss the subject.

And they are kind of purposefully vague. This is one of the criticisms that is made at the beginning. His problem is that if the person understands everything he is, he does not need it, and if the person only uses it as a basis for what he needs to accomplish the person gets "bitolada" and makes mistakes by following "magic formula".

Solid's ideas are good, but you always have to understand the whole context of it. Understand it in depth to know when and how to apply. Exaggeration in its use is a problem, like almost everything we do.

In general his problem is to put a lot of hanging, a lot of mechanism in what should be the domain. And he does not always produce the wonder that is expected of him, even when done right. It will still need a lot of refactoring. If it's to refactor, just put stuff on it when you need it.

Another related problem is that it mixes levels of abstraction, you find in the same code things that express your domain and things that help your code "work better".

What you should understand is that certain relationships between objects are difficult to undo and this is what matters throughout SOLID. Do not create dependencies where a refactoring will be too complicated. The secret is to eliminate dependencies, it is to allow composition. What matters is cohesion, a very old concept.

What software are we talking about?

This is something that is always left out. We are talking about a game? Something shipped? From an internal application? From a commercial product? From a public library or framework? Or something that has no importance or long life span?

Relation to OOP

Some say it helps OOP. There are those who say that it goes against, or at least that it is not about OOP. It doesn't seem to me that it's about OOP, everyone talks about one thing and overall talks about modularization, or even doing the opposite of what OOP preaches.

Principles important

I like other principles with priority, two of them are YAGNI and KISS that preach that you should do everything simple and only what you need. Of course with some care not to overdo it. In fact KISS says to do simple, but not simplistic, and YAGNI is not saying to leave the application completely naked.

Interestingly, the people who created and champion SOLID also strongly advocate legacy code, continuous improvement, and refactoring. Because well, not using SOLID until it is necessary meets the above two principles and it can be applied when needed in legacy code by doing refactoring. But only when the gain pays off.

Another principle that I like a lot, what I like the most, is the DRY. For the experience I have had in more than 35 years developing software, and in general working years on the same software, what makes maintenance easier is DRY. I get to exaggerate in the use of it, but it does not bring me big problem. Having a canonical system information is critical. When you start spreading the information you will lose control. And if you need to change something that is spread you will have problems, in addition to being much more confused to understand what is happening. Of course, the wrong use trying to reduce a circumstantial repetition can cause problems, so I always say that you have to know how to model with mastery, understand the problem in depth.

I find it unfortunate that they are creating a wave against DRY. DDD is very not DRY (in parts), SRP says it should have a reason to change one class, but not that a change of one class should not change others, and not having to change other places is more important.

Moreover, they seem to me only a sparse set of demands that are individually well-founded, but together have no cohesion at all. Why Will My Code Get solid if I apply them?

I agree. But I think they just threw together to sell the idea more easily. Forget that the software will be more solid. Understand that this in itself is just marketing. Stick to the individual principles themselves and understand them. Or to the original principles that are more important and that SOLID was created to market them better.

People like to buy these ideas, and the more it is repeated the more people want to follow it. It creates a virtuous circle for those who understand what it does and a vicious one for those who you don't understand. When people start doing it just because they read it is something they have to do it is wrong by definition, even if it works out by coincidence.

Dependency Inversion

Just what you haven't learned yet, which is usually implemented with that of DI (I already talked about it ), it is one of the things that most critical. Because most of the time it is created solely to facilitate testing. They don't even talk about what. And it is used ideologically. Anything let it be putting in the code without a need for it in itself I am against. If it is used because the software will look better is ok. If it is used to give flexibility and this is optional also ok. If it's just for testing has other ways to perform it. It is usually very simple to add this later.

Critical to each point

• SRP

  It's cool, but it's confusing. At first people understood that it was the DRY, today they say that it is another thing and it worries me. It's just about modularizing.

  One of his problems is that he can encourage creating too many classes, too many functions, making the code too complex, having to create linking elements, facilitators, or else very verbose codes to express what he needs because of the existence of so many components. And having so much it becomes easier to tinker with them individually, but it becomes very complicated to maintain and use.

  It is very difficult to define well what is sole responsibility. Almost everyone has to create a Cliente that derives from PessoaJuridica, and the moment it does this Cliente happens to have at least two responsibilities, but "no one" sees it. This is the fault of the canonical example ezrúxulo they use to teach OOP.

  In many cases a change in one class requires the change in another in an Associated way to function properly and in a way you don't know automatically. Refactoring to add something from solid late it is usually required in languages with a good type system, otherwise it does not compile. In other languages it can cause problems at runtime, unless the person creates a typing Control System in the code, which indicates that they have chosen the wrong language to do that.

  To tell the truth we don't have adequate tools to deal with it, even if it's desirable. And no one creates.

• OCP

  As a general idea is good, but in practice it creates complexity because everything requires making new versions. It is common to violate DRY because of this (ironically it should be the opposite). One way to avoid this is to separate responsibilities well, but when you do it the right way you start running away from OOP.

  In general it preaches the abuse of inheritance, even in the right way, but still use inheritance where perhaps you can do in a more flexible and easier way with composition.

  When everything is well planned and a new type it is created inherited from some kind that was thought to be base of something else, it can work. When you take something from one domain and inherit it in another domain to make it more flexible, you have something wrong, so it's best to let the object deal with the differences.

  One of the criticisms I make is that she sees inheritance in a basic way. Today some languages have more sophisticated mechanisms that allow something that is in the middle ground.

• LSP

  The idea is very good, mainly because she commands to avoid inheriting in a bungled way, without much sense. So reuse is avoided by Reuse, you need to have a reason to inherit. At the bottom she preaches the composition.

• ISP

  In general it's good, but it's more about contracts. The bad part is when they exaggerate just to follow this. Since you can refactor it is better not to segregate so much and segregate afterwards when necessary. Don't get it wrong, it's good to segregate, but watch out for do not overdo it. The worst is when the person creates an interface just by creating, without it being actually used. This is a mistake that only sins those who are very fanatical for SOLID and do not fully understand it, but among developers who are not beginners it is common to fall into this trap.

• DIP

  I mentioned above.

Conclusion

I like the idea of SOLID as hints of things you should watch out for when you are developing a software and points starting to study more on the subject.

None of these things guarantee quality in software. Quality is given when the person knows what he is doing and is dedicated to doing it correctly.

If Uncle Bob does that and it works out for him, great. But are you sure about this? Does it not end up doing the same job that you would do by not following SOLID when you have to give maintenance? Does he no longer have ease just because he knows how to do the right thing regardless of follow SOLID or not? We have no answers to this.

Who has proven that SOLID is good? Should we just believe he is? Is it religion?

SOLID is good, its irresponsible use is not. The benefits exist in specific cases when used correctly. Don't be alone in SOLID and don't demand to use it all.

To be fair it has much worse things, SOLID is not even that bad, but to be fairer it has better principles and guides that meet the same goal. What if it is applied with a less object-oriented ideal maybe it works better. Perhaps his biggest problem is the examples used and solutions offered.

In the general calculation the important thing is to know the pros and cons of it, it is silly to say that it is bad or good without a context.

I need to make time to substantiate this answer a little more. I have the basis of the problem, but I still need more research so as not to leave much in the air. In essence I put in Portuguese with my words the which is in all the links of the question, and some more knowledge.