Jak zweryfikować zasadę podstawienia Liskowa w hierarchii dziedziczenia?

Zainspirowany tą odpowiedzią:

Wymaga tego zasada substytucji Liskowa

• W podtypie nie można wzmocnić warunków wstępnych.
• Warunki podrzędne nie mogą zostać osłabione w podtypie.
• Niezmienniki nadtypu muszą być zachowane w podtypie.
• Ograniczenie historii („reguła historii”). Obiekty są uważane za modyfikowalne tylko za pomocą ich metod (enkapsulacji). Ponieważ podtypy mogą wprowadzać metody, które nie są obecne w nadtypu, wprowadzenie tych metod może pozwolić na zmiany stanu w podtypie, które nie są dopuszczalne w nadtypie. Ograniczenia historyczne tego zabraniają.

Miałem nadzieję, że ktoś opublikuje hierarchię klas, która narusza te 4 punkty i jak je odpowiednio rozwiązać.
Szukam szczegółowego wyjaśnienia do celów edukacyjnych, w jaki sposób zidentyfikować każdy z 4 punktów w hierarchii i jak najlepiej to naprawić.

Uwaga:
miałem nadzieję opublikować próbkę kodu dla osób, nad którymi będą pracować, ale samo pytanie dotyczy tego, jak zidentyfikować wadliwe hierarchie :)

Jest to o wiele prostsze niż ten cytat sprawia, że ​​brzmi on trafnie i dokładnie.

Kiedy spojrzysz na hierarchię dziedziczenia, wyobraź sobie metodę, która odbiera obiekt klasy podstawowej. Teraz zadaj sobie pytanie, czy są jakieś założenia, które mógłby dokonać ktoś edytujący tę metodę, które byłyby nieprawidłowe dla tej klasy.

Na przykład ( pierwotnie widoczny na stronie wuja Boba ):

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;
        }
    }
}

Wydaje się dość sprawiedliwe, prawda? Stworzyłem specjalistyczny rodzaj prostokąta o nazwie Kwadrat, który utrzymuje, że szerokość musi zawsze być równa wysokości. Kwadrat jest prostokątem, więc pasuje do zasad OO, prawda?

Ale poczekaj, co jeśli ktoś teraz napisze tę metodę:

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

Nie fajnie. Ale nie ma powodu, dla którego autor tej metody powinien był wiedzieć, że może istnieć potencjalny problem.

Za każdym razem, gdy wywodzisz jedną klasę od drugiej, pomyśl o klasie podstawowej i co ludzie mogą o niej sądzić (np. „Ma szerokość i wysokość i oboje byliby niezależni”). Pomyśl więc: „czy te założenia pozostają aktualne w mojej podklasie?” Jeśli nie, przemyśl swój projekt.