A call to a function with a parameter of type T (defined as fun f (x : T) : Integer) can be replaced by a call to a function g (defined as fun g (x : S) : Integer) if T ≤ S. In other words, if g cares less about the type of its parameter, then it can replace f anywhere, since both return an Integer. So, in a language accepting function arguments, g ≤ f and the type of the parameter to f is said to be contravariant.

abstract class Printer
{
    abstract void Print(Image image);
    abstract void Print(PostScript file);
}

class ColorLaserPrinter : Printer
{
    override void Print(Image image)
    {
        //...
    }

    override void Print(PostScript file);
    {
        //...
    }
}

class MatrixPrinter : Printer
{
    override void Print(Image image)
    {
        //...
    }

    override void Print(PostScript file);
    {
        //...
    }
}

class Environment
{
...
    Printer[] EnumAvailablePrinters() { ... }
...
}

class MyApp
{
    void main()
    {
        var image = new Image("/images/image.png");
        foreach (var printer in printers)
            printer.Print(image);
    }
}

void draw(Shape shape, Canvas canvas, Coordinate X, Coordinate Y);

void setPalette(Shape shape, Palette palette);
Palette getPalette(Shape shape);

class Shape {
void draw(Canvas canvas, Coordinate X, Coordinate Y);
void setPalette(Palette palette);
Palette getPalette();
}

class Shape {
  void setCanvas(Canvas canvas); // Выносим отдельно управление Canvas
  Canvas getCanvas(); // Должно выполняться условие: s.setCanvas(c); s.getCanvas() == c; Что положили, то и вытащили.

  void setBasePoint(Coordinate X, Coordinate Y);
  Coordinate getBasePointX();
  Coordinate getBasePointY();

  void draw(); // draw растерял все свои аргументы

  void setPalette(Palette palette);
  Palette getPalette();
}

class Canvas {
  void addShape(Shape);
  void drawAll(); // Рисуем всё, что накопилось
  
  void beginDraw();
  void endDraw();
  void putPixel(Color c, Coordinate X, Coordinate Y);
private:
  Shape m_allShapes[]; // Не суть важно, как именно выглядит этот массив. Главное - что это одномерный массив.
}

class Shape {
  ...
  // requires: Canvas.beginDraw / Canvas.endDraw call.
  void draw();
  ...
}

class BasicShape : public Shape {
  void setCanvas(Canvas canvas) { m_canvas = canvas; }
  Canvas getCanvas() { return m_canvas; }

  // Аналогично воплощаем здесь управление палитрой и базовыми точками.


  void draw() {
    m_canvas.beginDraw();
    drawPixels();
    m_canvas.endDraw();
  }

  void drawPixels(); // Этот метод предназначен для перекрытия классами-наследниками BasicShape,
                     // Canvas про него ничего не знает

protected:
  Canvas m_canvas;
}

class Bar : public BasicShape { ... };
class Circle : public BasicShape { ... };
class Triangle : public BasicShape { ... };
class Polygon : public BasicShape { ... };

class ShapeAdapter : public Shape { ... };

class SomethingSmart {
  Shape anchorShape() { return m_shapeAdapter; } // Можно и так сделать
protected:
  ShapeAdapter m_shapeAdapter; // Этот объект каким-то загадочным способом связывает интерфейс Shape и методы класса SomethingSmart
};

class Bar : public BasicShape { ... };

class CrazyShape : public Shape { // Наследование очень похоже на предыдущее...
  void draw() {
    m_canvas.putPixel(0, 1, 1); // ...но только внешне.
  }
}

// В Canvas придётся добавить такую фишку:
class Canvas {
  void drawAll() {
    ...
    if (typeOf(someShape) == CrazyShape) {
      // Для этого идиота придётся делать исключение
      beginDraw();
      someShape.draw();
      endDraw();
    } else {
      // Остальные - в норме
      someShape.draw();
    }
  }
}

class ShapeAdapter : public Shape { ... };

class SomethingSmart {
  Shape anchorShape() { return m_shapeAdapter; } // Можно и так сделать
protected:
  ShapeAdapter m_shapeAdapter; // Этот объект каким-то загадочным способом связывает интерфейс Shape и методы класса SomethingSmart
};

Shape createShape(string typeName) {
  if (typeName == "SomethingSmart") {
    SomethingSmart obj = new SomethingSmart(...);
    return obj.anchorShape();
  }
  ...
}

if (x.GetType() == typeof(SomeConcreteType))
{
  //...
}

Тимоти Бадд [27] приводит интересную классификацию форм наследования. Форма наследования определяет — для чего, с какой целью используется наследование. Бадд считает, что порождение дочернего класса может быть выполнено по следующим причинам:
 специализация. Класс-наследник является специализированной формой родительского класса — в наследнике просто переопределяются методы. Принцип подстановки выполняется. Очевидно, что такая форма наследования в С++ реализуется простым открытым наследованием.
Примером является наследование часы -> будильник;
 спецификация. Дочерний класс реализует поведение, описанное в родительском классе. Ясно, что в С++ эта форма реализуется простым открытым наследованием от абстрактного класса;
 конструирование. Класс-наследник использует методы базового класса, но не является его подтипом (принцип подстановки не выполняется). В С++ такую форму можно реализовать простым закрытым наследованием;
 расширение. В класс-потомок добавляют новые методы, расширяя поведение родительского класса; принцип подстановки в такой форме выполняется;
 обобщение. Дочерний класс обобщает поведение базового класса. Обычно такое наследование используется в тех случаях, когда мы не можем изменить поведение базового класса (например, базовый класс является библиотечным классом);
 ограничение. Класс-наследник ограничивает поведение родительского класса. Очевидно, что в С++ такой вид наследования реализуется простым закрытым наследованием (пример — TUniversalDeque -> TStack );
 варьирование. Базовый класс и класс-потомок являются вариациями на одну тему, однако связь «класс-подкласс» произвольна, например, «квадрат-прямоугольник» или «прямоугольник-квадрат». Эта форма фактически не отличается от «конструирования», так как класс-наследник, очевидно, «использует методы базового класса, но не является его подтипом»;
 комбинирование. Дочерний класс наследует черты нескольких классов — это множественное наследование.

class Shape {
public:
  virtual void draw() = 0;
  virtual void setCanvas(Canvas *) = 0;
};

class Circle : public Shape {
public:
  Circle(Point center, int radius);
  void draw();
  void setCanvas(Canvas *);
};

class Line : public Shape {
public:
  Line(Point begin, Point end);
  void draw();
  void setCanvas(Canvas *);
};

классы, которые дают возможность одинаково себя использовать, но требуют по-разному порождать

Z>if (x.GetType() == typeof(SomeConcreteType))
Z>{
Z>  //...
Z>}
Z>

class SomeBaseType
{...}

class SomeConcreteType: SomeBaseType
{...}

class SomeConcreteType2: SomeBaseType
{...}

void SomeFunc(SomeBaseType x)
{
  //...
  ((SomeConcreteType)x).SomeMethod();
  //...
}

1. Если считать это ожидаемым поведением функции SomeFunc, то нарушения LSP нет.
   
2. Если считать это ошибочным поведением, то контракт функции указан некорректно — ее параметр должен иметь тип SomeConcreteType. Просто проверка компилятором была подавлена.

class SomeConcreteType3: SomeBaseType
{...}

void SomeFunc(SomeBaseType x)
{
  //...
  if(x is SomeConcreteType)
  {
    ((SomeConcreteType)x).SomeMethod();
  }
  else
  {
    ((SomeConcreteType2)x).SomeMethodOfType2();
  }
  //...
}

interface ISort<T>
  where T: IComparable<T>
{
   T[] Sort(IEnumerable<T> items);
}

class BadSort: ISort<int>
{
  int[] Sort(IEnumerable<int> items) { return items.ToArray(); }
}

We are using the words "subtype" and "supertype" here to emphasize that now we are talking about
a semantic distinction. By contrast, "subclass" and "superclass" are simply linguistic concepts in
programming languages that allow programs to be built in a particular way. They can be used to
implement subtypes, but also, as mentioned above, in other ways.