How to use design patterns correctly?

Question

OOP

Good day to all! I am currently reading a book by the Gang of Four and, in parallel, "Design Patterns" by the Freemen. And some things really blow my mind.
So far, taken out of there, this is what we need to strive for loose coupling and programming at the level of interfaces, not implementations. But when it comes to real application, I fall into a stupor.
Those. it is clear that we have some modules that can (and probably even will) be used in other places (other projects, etc.). And there (in modules / services) you really use all these patterns and everything is cool.
But when it comes to using these modules, some kind of mess begins. There are controllers / views (something else). They are tied to a specific project and will not be used anywhere else (except as snippets).
Why would they pass a bunch of dependencies? Why make them loosely coupled?
Wouldn't it be easier for them to pull all dependencies from the global application object (which, in fact, will be a singleton and SL (Service Locator) or DIC (Dependency Injection Container))?
Maybe I'm misunderstanding something?

Answer 1

Hello author. Here are my thoughts on the matter:
1. Understanding programming patterns only comes with experience. Reading a book alone, without practice, will give you practically nothing. The material is quickly forgotten. Personally, I read about half of the book, after which I had to put it aside for a while. As I said, without training on examples, the material was quickly forgotten. He came to mind again when reading the book "Principles, Patterns and Methods of Agile Development in C#". There are a lot of detailed examples in the book, and it was after doing them that I began to realize the essence of some patterns.
Of course, one cannot assume that the pattern is any strict rule. Some of the patterns we implement ourselves even before reading any books. A pattern is a possible and convenient solution that can be applied to solve a problem. Don't try to memorize patterns or paste them wherever you can. You just need to write as much code as possible, then you automatically begin to see situations where you can apply the pattern.
2. About the weak connection. In all books, of course, they write that loose coupling is good. But in fact, such an architecture is not always justified, and software development experts periodically remind us of this. In practice, this means that you do not need to apply interfaces everywhere just because you can do it. If you are sure that your classes are unlikely to ever be replaced by others, then I personally believe that they can be safely used by each other without the principle of dependency inversion. Well, a question for unit testing. Of course, strong coupling interferes with unit testing, but if you do not plan to do it, then maybe you should not build redundant abstractions.
Personally, I also think that the above is less true for application and web applications (where modularity and testing is really important), and more true for gaming applications. Personally, I can hardly imagine a game in which each game object (a tank, a plane, for example) will implement an interface, so that theoretically someday we will replace the tank with a bio-robot. But it's true, lyrics.
3.About reuse. A friend of mine, a senior developer who has worked in serious organizations, says that code reuse is a myth. Personally, I only reused some helper functions. Well, or at best, several classes and interfaces to support modularity. In my opinion, it is not particularly necessary to talk about what can be taken and transferred from project to project the entire architecture.
4. About the controllers. As far as I understand (I have little development experience), the main point of making controllers dependent on interfaces is only to test these controllers (although I don’t quite understand why). A controller is really a thing that is very likely to be used only on a specific site. Also, this controller will be tied to some interface that provides business logic. Again, the likelihood that one business logic class will be replaced by another class with the same methods tends to zero, especially considering that the business logic class depends on the interface that provides methods for obtaining data. (if you want to change the way data is received - you change, for example, the repository class, the business logic remains the same). In this regard, I see so far only one reason to tie controllers to interfaces, and not to specific classes of business logic - this is testing. You will stabilize the business logic interface and test the controller independently of all other modules. If I'm wrong, please correct me, of course.