Should each class have an interface?

In the SOILD principle, almost all OILD requires interface intervention. Do I need to provide an interface for every class during development? Is this language-specific? When I use a multi-layer architecture for SSH, it is natural that I will build a service, service-impl, dao, dao-impl. However, you are developing A client or...

1. SOILDIn principleOILDAlmost all require interface intervention. Do I need to provide an interface for every class during development?
2. Is this language-specific? I'm doingSSHIt is natural to choose a multi-layer architecture.service,service-impl,dao,dao-impl. However, you are developing a client orASP.NET MVCIs it because of technical capability issues. InphpIt seems that there are very few objects to be connected. Is this related to language?
3. Is it necessary to adopt the "open and closed principle" in the early stage of development? Will there be more interfaces, making the code hard to read?

Reply content:

1. SOILDIn principleOILDAlmost all require interface intervention. Do I need to provide an interface for every class during development?
2. Is this language-specific? I'm doingSSHIt is natural to choose a multi-layer architecture.service,service-impl,dao,dao-impl. However, you are developing a client orASP.NET MVCIs it because of technical capability issues. InphpIt seems that there are very few objects to be connected. Is this related to language?
3. Is it necessary to adopt the "open and closed principle" in the early stage of development? Will there be more interfaces, making the code hard to read?

My suggestion is: refer to the three rules

For the first time, you don't have to worry about principles, suggestions, and so on.
The second time, I was alert when I began to repeat, but I was able to tolerate some violations of principles.
Repeat your code for the third time

Of course, if you have foreseen that the problem will come three times when you solve the problem for the first time, it is okay to write it in the third way. But if you predict that the problem will never come true, don't design so many things. Follow YAGNI.

References: refactoring book/YAGNI principles/DRY principles/premature optimization
SOLID vs YAGNI on stackoverflow