How to deal with dependency inversion?

Question

Programming

I read a recent article about SOLID. The example in the article is clear to me, but one thing is not clear. In the section where the author starts talking about dependency inversion, there is a paragraph:

To do this, in his C module, he created an interface, and wrote a simple adapter that takes a dependency from the desired module and provides access only to the desired method. Now if you fix something, you can fix the "breakdown" in one place.

And I'm confused. What is an adapter? What does "accept addiction" mean? What is this addiction anyway? And how did it suddenly happen that now it will be possible to fix the "breakdown" in one place?
Please explain with your fingers.
ps maybe there are still good and simple articles about solid for fools? I will be grateful for the link.

Answer 1

What is an adapter?

See. Do you have a micro USB cable? And there is a hole in the new macbook - Usb type c. As you can see, they don't fit into each other. And you can take a microUSB -> USB type-c adapter.
This is the essence of the adapter. interface conversion. We made the interface of the thing we need, then we took a ready-made thing that seems to do what we need, and made an adapter that closes inconsistencies in the interfaces.
Thus, if problems suddenly appear in a month, you can replace the "finished thing" with another ready-made one, make another adapter, and that's it. Changes in terms of code that uses the interface we need will only be in the adapter used.
This achieves independence.
Suppose we have a method for changing a user's password. To do this safely, we need to hash the password and store it in a hashed form. That is, we need some kind of thing that will hash these passwords. We don’t want to know anything about it, we want it to be given to us:

public function changePassword(string $password, PasswordEncoder $encoder)
{
    $this->password = $encoder->encode($password);      
}

This is the dependency of our method. He depends on him. The dialogue between objects can be imagined as follows:
- Hey, change the password to this one
- Ok, just give me a hasher of passwords, I really need it
- What do you want?
- Yes, anyone with this type
- Well, ok. Here is the password and hasher. Do things.
Dependencies are everything we use to get things done. These are not only libraries, but also just classes, functions, etc. All "third party" code in terms of our code. And the most important thing is that "our" code is the one we are working on at a given time, and not all that we have written. Even the functions that are in the programming language out of the box are dependencies. But you can’t get away from them anywhere, and therefore you shouldn’t mess with them. Or if the library has long-term support and it is tired, you can also just use it. But if this is a craft on github with 10 stars and there is still not a single release - but you really need it, possible breakdowns in it (and they will be sooner or later) should be "closed"

Answer 2

https://ru.wikipedia.org/wiki/Adapter_(project_template...

What does "accept addiction" mean?

Gets another object needed for its operation.

And how did it suddenly happen that now it will be possible to fix the "breakdown" in one place?

C and B now have dependencies on different adapter classes of module E, and by interface from their own module, rather than direct dependencies.