Question: 1) Does LSP also apply to interfaces, meaning that we should be able to use a class implementing a specific interface and still get the expected behavior? 

2) If that is indeed the case, then why is programming to an interface considered a good thing ( BTW- I know that programming to an interface increases loose coupling ), if one of the main reasons against using inheritance is due to risk of not complying to LSP? Perhaps because:

a) benefits of loose coupling outweight the risks of not complying to LSP

b) compared to inheritance, chances that a class ( implementing an interface ) will not adher to LSP are much smaller 

thank you

Answer: 
I'm comparing/contrasting my code practice with LSP at the moment. I think it must be all to do with expectation and deciding how to define what should be expected. I'm not convinced that substitution always means the same thing. For instance, if I defined 

```
interface ICalculation 
{ 
    double Calculate(double A, double B); 
} 

```

with the intention of defining `class Add : ICalculation`, `class Subtract : ICalculation`, `class Multiply : ICalculation` and `class Divide : ICalculation`, I believe that those classes should perform the respective `Calculation(A, B)`, however, I do not believe they should all pass the same unit tests. I like to use interfaces for extensibility, where each extension has a different function. In the case of a car braking, I would give classes the interface IBrakable and do this: 

```
var myBrakableCar = MyCar as IBrakable;
if(myBrakableCar != null) 
{
    myBrakableCar.Brake();
}

```

I believe that classes should be predictable in their use, but also useful. Useful comes top. 

I'm just going to create a new concept - "Respective Substition": it does what it says on the tin.
Ad 1): Yes. However, it is hard to make interfaces enforce the contracts, and they really should.

Ad 2): Programming against an interface is a trade-off. As you point out interfaces encourages violation of LSP for all interfaces with a non-trivial contract.

I believe these are the answers to your questions, or at least my recognition that tese are unanswered questions that challenge the encouraged use of interfaces.

I use interfaces all the time (in C#) because I like doing TDD. I then just hope that my mocks and corresponding implementations don't violate LSP, because when they do my test suite is no longer sound (it claims something to work, but it doesn't).

Occasionally, I'll make an abstract base class instead of an interface. The abstract base class simply enforces the contract, and delegates to virtual protected methods that are supposed to define the actual implementation or being mocked during unit testing. This has proven to be useful in some applications, where errors in the unit tests themselves are discovered.

But then we run into the missing support for multiple inheritance in C#, and we are stuck with the interfaces anyway (or simply more classes, you can hide behind the SRP if you choose this approach)