Як перевірити принцип заміщення Ліскова в ієрархії спадкування?

Натхненний цією відповіддю:

Принцип заміщення Ліскова вимагає цього

• Передумови не можна посилити в підтипі.
• Послідовності не можуть бути ослаблені в підтипі.
• Інваріанти супертипу повинні зберігатися в підтипі.
• Обмеження історії ("правило історії"). Об'єкти вважаються модифікованими лише завдяки їх методам (інкапсуляція). Оскільки підтипи можуть вводити методи, відсутні в супертипі, то введення цих методів може дозволити зміни стану підтипу, які неприпустимі в супертипі. Обмеження історії забороняє це.

Я сподівався, що хтось опублікує ієрархію класів, яка порушує ці 4 пункти, і як їх вирішити відповідно.
Я шукаю детальне пояснення для навчальних цілей щодо того, як визначити кожен із 4-х пунктів в ієрархії та найкращий спосіб його виправити.

Примітка.
Я сподівався опублікувати зразок коду для роботи людей, але саме питання полягає в тому, як визначити несправні ієрархії :)

Це набагато простіше, ніж ця цитата робить її звуковою, точною, як є.

Дивлячись на ієрархію спадкування, уявіть метод, який отримує об'єкт базового класу. Тепер запитайте себе, чи існують припущення, що хтось, хто редагує цей метод, може зробити це недійсним для цього класу.

Наприклад ( спочатку його бачили на сайті дядька Боба ):

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

Здається, досить справедливо, правда? Я створив спеціальний вид Прямокутник під назвою Квадрат, який стверджує, що Ширина повинна дорівнювати Висоті в усі часи. Квадрат - це прямокутник, тому він відповідає принципам ОО, чи не так?

Але зачекайте, що робити, якщо хтось зараз пише цей метод:

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

Не круто. Але немає причин, щоб автор цього методу мав знати, що може виникнути потенційна проблема.

Кожен раз, коли ви отримуєте один клас з іншого, подумайте про базовий клас та про те, що люди можуть припустити про нього (наприклад, "він має ширину та висоту, і обидва вони будуть незалежними"). Тоді подумайте, "чи залишаються ці припущення в моєму підкласі?" Якщо ні, переосмислити дизайн.