The high link is bad, the low link is good.
I will not put it so black and white. A bit of coupling is necessary. In addition, some indirect ways to get rid of the coupling may introduce too much overhead. In particular for applications that need to respond in real time. They are compensations.
Yes, you want to avoid high coupling. However, if the introduction of patterns in an attempt to reduce coupling prevents you from first meeting your requirements (which may include response time, budgets, etc.), then it is not worth it.
In Java, when A creates an object B and calls one of its methods, it is said to be closely coupled. But if we create an IB interface, used from A where B implements IB, it is said to be flexibly coupled. I don't see why, since a change in the interface would have an impact on A and B. And a change on B would have an impact on IB and A. They still seem to be coupled to the call.
Yes, they are still docked calls. Well, it depends on how you define the metric. However, interfaces are not the right tool if you want to deal with it.
Regardless, with the interfaces, classes would be freely coupled, since A does not directly link to B. It could have other implementations of the interface.
A common antipatron is to create an interface that matches what the consumed class offers. You must create an interface that matches what the consumer class needs. See interface segregation. The interface becomes a requirement for the class consumed.
If you conceptualize the interface that way, the interface would only change when necessary for your consumers. When changing A, you can decide to change the interface or use a new one.
If we decide to change the interface when changing A, the change would spread from A to B. Instead of propagating from B to A. However, we don't have to decide to change the interface, or we can introduce an adapter that implements the interface and the wraps. B. That is, we have opportunities to stop the spread of change. That's what we want. And that is what the loose coupling buys us. We design to have more options, not less.
Again, that is not solving the call coupling.
The same reason applies to the Facade GoF design pattern. It is said to promote low coupling, since we put an intermediary between a subsystem and the customer code. In this case, it seems that we transfer the customer code problem to the Facade. Since a change in the subsystem would have an impact on the Facade instead of the customer code. The client code is no longer coupled to the subsystem, but the Facade is.
The facade hides everything you do behind it. It is similar to how an object encapsulates its state. The facade encapsulates a (sub) system. The consumer code only needs to talk to the facade and ignores the details behind it.
Of course, it is still docked. And yes, you have moved the problem to the Facade. However, thanks to the Facade, the consumer code does not have to change due to changes in what is behind the facade.
But the answers are not specific enough. First, since encapsulation is also about treating objects such as black boxes, the first response does not specify any gain when using interfaces compared to regular classes (= closed coupling, in the case of black boxes)
If you use the class directly, the class must implement what the consumer code needs. If the consumer code uses an interface instead, then it does not have to be implemented by any particular class. You can change the class without the consumer code knowing. The consumer code has less knowledge, therefore, it is less coupled.
What the interfaces provide is the decoupling between the interface and the implementation when there are multiple implementations. But it does not solve anything related to call coupling.
Correct, it's not about call coupling. You are the one who reduces the discussion to call the link and the interfaces. And then wondering why they provide nothing.
Interfaces are not the right tool to deal with call coupling. Instead, you want an event driven architecture, a consumer subscriber pattern or the like. That way, there may not even be an implementation on the other side. Of course, some infrastructure may be required, if not provided by the language and runtime. Oh, this is Java, yes, some infrastructure is required.