Принцип замещения Лискова (LSP) нарушен при проектировании по контракту (DBC)?

Я пишу фреймворк на PHP, и столкнулся с паттерном, который плохо пахнет. Похоже, что я выполняю контракт (q.v. Design By Contract), который нарушает принцип замены Лискова (LSP). Поскольку исходный пример сильно абстрагирован, я помещу его в контекст реального мира:

(н.б. Я не двигатель / транспортное средство / vroom-vroom человек, простите меня, если это нереально)

Предположим, у нас есть анемичный абстрактный класс для транспортных средств, и, кроме того, у нас есть два подтипа транспортных средств — те, которые можно заправлять, и те, которые не могут (например, pushbikes). Для этого примера мы сконцентрируемся только на заправляемом типе:

abstract class AbstractVehicle {}

abstract class AbstractFuelledVehicle extends AbstractVehicle
{
private $lastRefuelPrice;

final public function refuelVehicle(FuelInterface $fuel)
{
$this->checkFuelType($fuel);
$this->lastRefuelPrice = $fuel->getCostPerLitre;
}

abstract protected function checkFuelType(FuelInterface $fuel);
}

abstract class AbstractNonFuelledVehicle extends AbstractVehicle { /* ... */ }

Теперь давайте посмотрим на «топливные» классы:

abstract class AbstractFuel implements FuelInterface
{
private $costPerLitre;

final public function __construct($costPerLitre)
{
$this->costPerLitre = $costPerLitre;
}

final public function getCostPerLitre()
{
return $this->costPerLitre;
}
}

interface FuelInterface
{
public function getCostPerLitre();
}

Это все абстрактные классы, теперь давайте посмотрим на конкретные реализации. Во-первых, две конкретные реализации топлива, включая некоторые анемичные интерфейсы, чтобы мы могли правильно напечатать / намекнуть их:

interface MotorVehicleFuelInterface {}

interface AviationFuelInterface {}

final class UnleadedPetrol extends AbstractFuel implements MotorVehicleFuelInterface {}

final class AvGas extends AbstractFuel implements AviationFuelInterface {}

Теперь, наконец, у нас есть конкретные реализации транспортных средств, которые гарантируют, что правильный тип топлива (интерфейс) используется для заправки определенного класса транспортных средств, создав исключение, если оно несовместимо:

class Car extends AbstractFuelledVehicle
{
final protected function checkFuelType(FuelInterface $fuel)
{
if(!($fuel instanceof MotorVehicleFuelInterface))
{
throw new Exception('You can only refuel a car with motor vehicle fuel');
}
}
}

class Jet extends AbstractFuelledVehicle
{
final protected function checkFuelType(FuelInterface $fuel)
{
if(!($fuel instanceof AviationFuelInterface))
{
throw new Exception('You can only refuel a jet with aviation fuel');
}
}
}

Car и Jet являются подтипами AbstractFuelledVehicle, поэтому, согласно LSP, мы должны быть в состоянии заменить их.

В связи с тем, что checkFuelType () генерирует исключение, если указан неправильный подтип AbstractFuel, это означает, что если мы заменим подтип Car AbstractFuelledVehicle на Jet (или наоборот) не заменяя также соответствующий подтип топлива, мы вызовем исключение.

Это:

1. Определенное нарушение LSP, поскольку замещение не должно приводить к изменению поведения, которое приводит к выбрасыванию исключений
2. Совсем не нарушение, поскольку все интерфейсы и абстрактные функции реализованы правильно и могут вызываться без нарушений типов.
3. Немного серой области, ответ которой субъективен