Things that generalize tend to lose the essence of context.
However, I don't think dependency inversion is supposed to mean that client code will still work if implementer code breaks. Correctly me if I am wrong, the interface is meant to be a contract between the client and the implementer. The contract doesn't do the work. It is used to express what the client expects and what the implementer must satisfy. If the implementer code breaks, we just go out there and get someone else to bid for that contract.
Now, it is certainly true that both side of the abstraction barrier change way too often in reality(Or is it ?). I wonder is it really better with/without the concept of contract. Certainly in other aspects of our lives, when things are serious, we always have this concept of contract in place. Do we need them in code? I don't know...
Just my two cents.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you on two counts:
However, I don't think dependency inversion is supposed to mean that client code will still work if implementer code breaks. Correctly me if I am wrong, the interface is meant to be a contract between the client and the implementer. The contract doesn't do the work. It is used to express what the client expects and what the implementer must satisfy. If the implementer code breaks, we just go out there and get someone else to bid for that contract.
Now, it is certainly true that both side of the abstraction barrier change way too often in reality(Or is it ?). I wonder is it really better with/without the concept of contract. Certainly in other aspects of our lives, when things are serious, we always have this concept of contract in place. Do we need them in code? I don't know...
Just my two cents.