Coupling Theory vs reality 2

Coupling Theory vs reality 2

Coupling is defined as the knowledge one object has about another one, which describes how dependent they are. The more dependent, the worse, since changes in one would impact in the second. There are different coupling types:

http://www.principles-wiki.net/principles:low_coupling

Let's assume we talk about call coupling.

In Java, when A creates an object B and calls one of its methods it's said to be tightly coupled. But if we create an interface IB, used from A where B implements IB it's said to be loosely coupled. I don't see why since one change in the interface would have an impact in A and B. And one change in B would have an impact in IB and A. They still seem to be call dependent.

The same rationale applies to the Facade GoF design pattern. It's said it promotes low coupling, since we put an intermediary between a subsystem and the client code. In this case, it looks like we transferred the problem from the client code to the Facade. Since a change in the subsystem would have an impact on the Facade instead of the client code. The client code is no longer coupled to the subsystem but the Facade is.

I don't see how coupling is reduced.

This has been asked in: "How is loose coupling achieved using interfaces in Java when an implementation class is mandatory and bound to interface contract?" (-> "Coupling Theory vs. reality" has been closed).

But the answers are not specific enough. First, since encapsulation is also about treating objects as black boxes, the first answer does not specify any gain by using interfaces compared to regular classes (= tight coupling, in case it's all about black boxes). Therefore the answer is invalid. What interfaces provide is decoupling between the interface and the implementation when multiple implementations exist. But doesn't solve anything related to call coupling. May be the link provided above should add a new category called "implementation coupling". Regardless of this, the solution is still interface dependent -> call coupling. In the second answer it mentions data coupling, but as far as I know the issue is about call coupling.

The rest of the answers are irrelevant.

Regarding "Design Patterns - Understanding Facade Pattern", I understand the Facade pattern. I'm only asking about the coupling reduced by the pattern. Which based on my reasoning is not reduced but transferred.

This subject has been treated but no proper answer has been given.