¿Cómo verificar el principio de sustitución de Liskov en una jerarquía de herencia?

Inspirado por esta respuesta:

El principio de sustitución de Liskov requiere que

• Las condiciones previas no pueden fortalecerse en un subtipo.
• Las condiciones posteriores no pueden debilitarse en un subtipo.
• Las invariantes del supertipo deben conservarse en un subtipo.
• Restricción del historial (la "regla del historial"). Los objetos se consideran modificables solo a través de sus métodos (encapsulación). Dado que los subtipos pueden introducir métodos que no están presentes en el supertipo, la introducción de estos métodos puede permitir cambios de estado en el subtipo que no están permitidos en el supertipo. La restricción de la historia lo prohíbe.

Esperaba que alguien publicara una jerarquía de clases que violara estos 4 puntos y cómo resolverlos en consecuencia.
Estoy buscando una explicación elaborada con fines educativos sobre cómo identificar cada uno de los 4 puntos en la jerarquía y la mejor manera de solucionarlo.

Nota:
esperaba publicar una muestra de código para que las personas trabajen, pero la pregunta en sí misma es sobre cómo identificar las jerarquías defectuosas :)

Es mucho más simple de lo que esa cita hace que suene, tan precisa como es.

Cuando observa una jerarquía de herencia, imagine un método que recibe un objeto de la clase base. Ahora pregúntese, ¿hay alguna suposición que alguien que edite este método pueda hacer que no sea válida para esa clase?

Por ejemplo ( visto originalmente en el sitio del tío Bob ):

public class Square : Rectangle
{
    public Square(double width) : base(width, width)
    {
    }

    public override double Width
    {
        set
        {
            base.Width = value;
            base.Height = value;
        }
        get
        {
            return base.Width;
        }
    }

    public override double Height
    {
        set
        {
            base.Width = value;
            base.Height = value;
        }
        get
        {
            return base.Height;
        }
    }
}

Parece bastante justo, ¿verdad? He creado un tipo de rectángulo especializado llamado Cuadrado, que sostiene que el Ancho debe ser igual a la Altura en todo momento. Un cuadrado es un rectángulo, por lo que encaja con los principios OO, ¿no?

Pero espera, ¿y si alguien ahora escribe este método?

public void Enlarge(Rectangle rect, double factor)
{
    rect.Width *= factor;
    rect.Height *= factor;
}

No es genial Pero no hay razón para que el autor de este método haya sabido que podría haber un problema potencial.

Cada vez que deriva una clase de otra, piense en la clase base y en lo que la gente podría asumir sobre ella (como "tiene un Ancho y una Altura y ambos serían independientes"). Entonces piense "¿esas suposiciones siguen siendo válidas en mi subclase?" Si no, reconsidere su diseño.