LSP - это правило о контракте классов: если базовый класс удовлетворяет контракту, то производные классы LSP также должны удовлетворять этому контракту.

В псевдо-питоне

class Base:
   def Foo(self, arg): 
       # *... do stuff*

class Derived(Base):
   def Foo(self, arg):
       # *... do stuff*

удовлетворяет LSP, если каждый раз, когда вы вызываете Foo для производного объекта, он дает точно такие же результаты, как и вызов Foo для базового объекта, если arg остается таким же.

Я предполагаю, что все как бы понимали, что такое LSP технически: вы в основном хотите иметь возможность абстрагироваться от деталей подтипа и безопасно использовать супертипы.

Итак, у Лискова есть 3 основных правила:

1. Правило подписи: синтаксически должна существовать допустимая реализация каждой операции супертипа в подтипе. Что-то компилятор сможет проверить за вас. Есть небольшое правило о том, чтобы генерировать меньше исключений и быть по крайней мере таким же доступным, как методы супертипа.

2. Правило методов: реализация этих операций семантически корректна.

   • Weaker Preconditions : The subtype functions should take at least what the supertype took as input, if not more.
   • Более строгие постусловия: они должны производить подмножество вывода, созданного методами супертипа.

3. Правило свойств: это выходит за рамки отдельных вызовов функций.

   • Invariants : Things that are always true must remain true. Eg. a Set's size is never negative.
   • Эволюционные свойства: обычно что-то связано с неизменяемостью или типом состояний, в которых может находиться объект. Или, может быть, объект только растет и никогда не сжимается, поэтому методы подтипа не должны этого делать.

Все эти свойства необходимо сохранить, а дополнительные функции подтипа не должны нарушать свойства супертипа.

Если позаботиться об этих трех вещах, вы абстрагировались от лежащих в основе вещей и пишете слабо связанный код.

Источник: Разработка программ на Java - Барбара Лисков.

Проиллюстрируем на Java:

class TrasportationDevice
{
   String name;
   String getName() { ... }
   void setName(String n) { ... }

   double speed;
   double getSpeed() { ... }
   void setSpeed(double d) { ... }

   Engine engine;
   Engine getEngine() { ... }
   void setEngine(Engine e) { ... }

   void startEngine() { ... }
}

class Car extends TransportationDevice
{
   @Override
   void startEngine() { ... }
}

Здесь нет проблем, правда? Автомобиль определенно является транспортным средством, и здесь мы видим, что он переопределяет метод startEngine () своего суперкласса.

Добавим еще одно транспортное средство:

class Bicycle extends TransportationDevice
{
   @Override
   void startEngine() /*problem!*/
}

Сейчас все идет не так, как планировалось! Да, велосипед - это транспортное средство, но у него нет двигателя и, следовательно, метод startEngine () не может быть реализован.

Это те проблемы, к которым приводит нарушение принципа замещения Лискова, и обычно их можно распознать с помощью метода, который ничего не делает или даже не может быть реализован.

Решением этих проблем является правильная иерархия наследования, и в нашем случае мы бы решили проблему, разграничив классы транспортных средств с двигателями и без них. Хотя велосипед является транспортным средством, у него нет двигателя. В этом примере наше определение транспортного средства неверно. У него не должно быть двигателя.

Мы можем реорганизовать наш класс TransportationDevice следующим образом:

class TrasportationDevice
{
   String name;
   String getName() { ... }
   void setName(String n) { ... }

   double speed;
   double getSpeed() { ... }
   void setSpeed(double d) { ... }
}

Теперь мы можем расширить TransportationDevice для немоторизованных устройств.

class DevicesWithoutEngines extends TransportationDevice
{  
   void startMoving() { ... }
}

И расширите TransportationDevice для моторизованных устройств. Здесь более уместно добавить объект Engine.

class DevicesWithEngines extends TransportationDevice
{  
   Engine engine;
   Engine getEngine() { ... }
   void setEngine(Engine e) { ... }

   void startEngine() { ... }
}

Таким образом, наш класс Car становится более специализированным, при этом соблюдая принцип замещения Лискова.

class Car extends DevicesWithEngines
{
   @Override
   void startEngine() { ... }
}

И наш класс велосипедов также соответствует принципу замены Лискова.

class Bicycle extends DevicesWithoutEngines
{
   @Override
   void startMoving() { ... }
}

Функции, использующие указатели или ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом.

Когда я впервые прочитал о LSP, я предположил, что это имелось в виду в очень строгом смысле, по существу приравнивая его к реализации интерфейса и типобезопасному приведению типов. Это означало бы, что LSP либо обеспечивается самим языком, либо нет. Например, в этом строгом смысле ThreeDBoard, безусловно, может быть заменен на Board в том, что касается компилятора.

Прочитав больше о концепции, я обнаружил, что LSP обычно интерпретируется шире.

Короче говоря, то, что означает для клиентского кода «знать», что объект, стоящий за указателем, имеет производный тип, а не тип указателя, не ограничивается типобезопасностью. Соблюдение LSP также можно проверить, исследуя фактическое поведение объектов. То есть изучение влияния состояния объекта и аргументов метода на результаты вызовов методов или типы исключений, создаваемых объектом.

Возвращаясь снова к примеру, теоретически методы Board можно заставить нормально работать на ThreeDBoard. Однако на практике будет очень сложно предотвратить различия в поведении, которые клиент может неправильно обработать, не ограничивая функциональные возможности, которые должен добавить ThreeDBoard.

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

Важным примером использования LSP является тестирование программного обеспечения.

Если у меня есть класс A, который является LSP-совместимым подклассом B, то я могу повторно использовать набор тестов B для тестирования A.

Чтобы полностью протестировать подкласс A, мне, вероятно, нужно добавить еще несколько тестовых примеров, но как минимум я могу повторно использовать все тестовые примеры суперкласса B.

Один из способов реализовать это - построить то, что МакГрегор называет «параллельной иерархией для тестирования»: мой ATest класс унаследует от BTest. Затем потребуется некоторая форма внедрения, чтобы убедиться, что тестовый пример работает с объектами типа A, а не типа B (подойдет простой шаблон метода).

Обратите внимание, что повторное использование набора супертестов для всех реализаций подкласса на самом деле является способом проверить, что эти реализации подкласса совместимы с LSP. Таким образом, можно также утверждать, что каждый должен запускать набор тестов суперкласса в контексте любого подкласса.

См. Также ответ на вопрос Stackoverflow «Могу ли я реализовать серию многоразовых тестов для проверки реализации интерфейса?»

В очень простом предложении мы можем сказать:

Дочерний класс не должен нарушать характеристики своего базового класса. Он должен уметь с этим справляться. Можно сказать, что это то же самое, что и подтипирование.

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

• Переопределенный метод не должен оставаться пустым.
• Переопределенный метод не должен вызывать ошибку
• Поведение базового класса или интерфейса не должно подвергаться модификации (переработке) из-за поведения производного класса.

Эта формулировка LSP слишком сильна:

Если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в терминах T, поведение P не меняется при замене o1 на o2, тогда S является подтипом T.

По сути, это означает, что S - это еще одна, полностью инкапсулированная реализация того же самого, что и T. И я мог бы быть смелым и решить, что производительность является частью поведения P ...

Таким образом, любое использование позднего связывания нарушает LSP. Весь смысл объектно-ориентированного подхода - получить другое поведение, когда мы заменяем объект одного вида одним другим!

Формулировка, процитированная в wikipedia, лучше, поскольку свойство зависит от контекста и не обязательно включает весь поведение программы.

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

Все время мы проектируем программный модуль и создаем какие-то иерархии классов. Затем мы расширяем некоторые классы, создавая производные классы.

Мы должны убедиться, что новые производные классы просто расширяются, не заменяя функциональность старых классов. В противном случае новые классы могут вызвать нежелательные эффекты при использовании в существующих программных модулях.

Принцип замены Лискова гласит, что если программный модуль использует базовый класс, то ссылка на базовый класс может быть заменена на производный класс, не влияя на функциональность программного модуля.

Пример:

Ниже приведен классический пример нарушения принципа замещения Лискова. В примере используются 2 класса: прямоугольник и квадрат. Предположим, что объект Rectangle используется где-то в приложении. Расширяем приложение и добавляем класс Square. Класс Square возвращается фабричным шаблоном на основе некоторых условий, и мы не знаем, какой именно тип объекта будет возвращен. Но мы знаем, что это прямоугольник. Мы получаем прямоугольник, устанавливаем ширину 5 и высоту 10 и получаем площадь. Для прямоугольника шириной 5 и высотой 10 площадь должна быть 50. Вместо этого результат будет 100.

    // Violation of Likov's Substitution Principle
class Rectangle {
    protected int m_width;
    protected int m_height;

    public void setWidth(int width) {
        m_width = width;
    }

    public void setHeight(int height) {
        m_height = height;
    }

    public int getWidth() {
        return m_width;
    }

    public int getHeight() {
        return m_height;
    }

    public int getArea() {
        return m_width * m_height;
    }
}

class Square extends Rectangle {
    public void setWidth(int width) {
        m_width = width;
        m_height = width;
    }

    public void setHeight(int height) {
        m_width = height;
        m_height = height;
    }

}

class LspTest {
    private static Rectangle getNewRectangle() {
        // it can be an object returned by some factory ...
        return new Square();
    }

    public static void main(String args[]) {
        Rectangle r = LspTest.getNewRectangle();

        r.setWidth(5);
        r.setHeight(10);
        // user knows that r it's a rectangle.
        // It assumes that he's able to set the width and height as for the base
        // class

        System.out.println(r.getArea());
        // now he's surprised to see that the area is 100 instead of 50.
    }
}

Вывод:

Этот принцип является просто расширением принципа открытого и закрытого типа, и это означает, что мы должны убедиться, что новые производные классы расширяют базовые классы без изменения их поведения.

См. Также: Принцип открытого закрытия

Некоторые похожие концепции для лучшей структуры: Соглашение важнее конфигурации

Простыми словами, LSP утверждает, что объекты одного и того же суперклассы должны иметь возможность обмениваться друг с другом, ничего не нарушая.

Например, если у нас есть классы Cat и Dog, производные от класса Animal, любые функции, использующие класс Animal, должны иметь возможность использовать Cat или Dog и вести себя нормально.

Этот принцип был введен Барбарой Лисков в 1987 году и расширяет принцип открытости-закрытости, фокусируясь на поведении суперкласса и его подтипов.

Его важность становится очевидной, если мы рассмотрим последствия его нарушения. Рассмотрим приложение, в котором используется следующий класс.

public class Rectangle 
{ 
  private double width;

  private double height; 

  public double Width 
  { 
    get 
    { 
      return width; 
    } 
    set 
    { 
      width = value; 
    }
  } 

  public double Height 
  { 
    get 
    { 
      return height; 
    } 
    set 
    { 
      height = value; 
    } 
  } 
}

Представьте, что однажды клиенту потребуется умение манипулировать квадратами в дополнение к прямоугольникам. Поскольку квадрат является прямоугольником, класс Square должен быть производным от класса Rectangle.

public class Square : Rectangle
{
} 

Однако при этом мы столкнемся с двумя проблемами:

Квадрату не нужны переменные высоты и ширины, унаследованные от прямоугольника, и это может привести к значительным потерям памяти, если нам придется создавать сотни тысяч квадратных объектов. Свойства установщика ширины и высоты, унаследованные от прямоугольника, не подходят для квадрата, поскольку ширина и высота квадрата идентичны. Чтобы установить одинаковое значение для высоты и ширины, мы можем создать два новых свойства следующим образом:

public class Square : Rectangle
{
  public double SetWidth 
  { 
    set 
    { 
      base.Width = value; 
      base.Height = value; 
    } 
  } 

  public double SetHeight 
  { 
    set 
    { 
      base.Height = value; 
      base.Width = value; 
    } 
  } 
}

Теперь, когда кто-то будет устанавливать ширину квадратного объекта, его высота соответственно изменится и наоборот.

Square s = new Square(); 
s.SetWidth(1); // Sets width and height to 1. 
s.SetHeight(2); // sets width and height to 2. 

Давайте продвинемся вперед и рассмотрим еще одну функцию:

public void A(Rectangle r) 
{ 
  r.SetWidth(32); // calls Rectangle.SetWidth 
} 

Если мы передадим в эту функцию ссылку на квадратный объект, мы нарушим LSP, потому что функция не работает для производных от своих аргументов. Свойства width и height не являются полиморфными, потому что они не объявлены виртуальными в прямоугольнике (квадратный объект будет поврежден, потому что высота не будет изменена).

Однако, объявив свойства установщика виртуальными, мы столкнемся с другим нарушением - OCP. Фактически, создание квадрата производного класса вызывает изменения в прямоугольнике базового класса.

Некоторое дополнение:
Интересно, почему никто не написал об инварианте, предварительных условиях и условиях публикации базового класса, которым должны подчиняться производные классы. Чтобы производный класс D был полностью совместим с базовым классом B, класс D должен подчиняться определенным условиям:

• In-варианты базового класса должны быть сохранены производным классом
• Предварительные условия базового класса не должны усиливаться производным классом.
• Пост-условия базового класса не должны ослабляться производным классом.

Таким образом, производные должны знать о трех вышеуказанных условиях, налагаемых базовым классом. Следовательно, правила выделения подтипов определены заранее. Это означает, что отношение «IS A» должно соблюдаться только тогда, когда подтип соблюдает определенные правила. Эти правила в форме инвариантов, предварительных условий и постусловий должны быть определены в формальном 'контракте на проектирование '.

Дальнейшее обсуждение этого доступно в моем блоге: Принцип замены Лискова < / а>

Квадрат - это прямоугольник, ширина которого равна высоте. Если квадрат устанавливает два разных размера для ширины и высоты, он нарушает инвариант квадрата. Это обходится путем введения побочных эффектов. Но если у прямоугольника есть setSize (высота, ширина) с предварительным условием 0 ‹высоты и 0‹ ширины. Для метода производного подтипа требуется высота == ширина; более сильное предусловие (нарушающее lsp). Это показывает, что, хотя квадрат и является прямоугольником, он не является допустимым подтипом, поскольку предусловие усилено. Обход (в общем, плохая вещь) вызывает побочный эффект, и это ослабляет условие публикации (что нарушает lsp). setWidth на базе имеет условие поста 0 ‹ширину. Производное ослабляет его с высотой == шириной.

Следовательно, квадрат изменяемого размера не является прямоугольником изменяемого размера.

Будет ли такая полезная реализация ThreeDBoard в виде массива Board?

Возможно, вы захотите рассматривать срезы ThreeDBoard в различных плоскостях как доску. В этом случае вы можете абстрагироваться от интерфейса (или абстрактного класса) для Board, чтобы можно было реализовать несколько реализаций.

Что касается внешнего интерфейса, вы можете выделить интерфейс Board как для TwoDBoard, так и для ThreeDBoard (хотя ни один из вышеперечисленных методов не подходит).

Самым ясным объяснением LSP, которое я нашел до сих пор, было: «Принцип замены Лискова гласит, что объект производного класса должен иметь возможность заменять объект базового класса без каких-либо ошибок в системе или изменения поведения базового класса. "from здесь. В статье приводится пример кода нарушения LSP и его исправления.

Допустим, мы используем прямоугольник в нашем коде

r = new Rectangle();
// ...
r.setDimensions(1,2);
r.fill(colors.red());
canvas.draw(r);

В нашем классе геометрии мы узнали, что квадрат - это особый тип прямоугольника, потому что его ширина равна его высоте. Давайте также создадим класс Square на основе этой информации:

class Square extends Rectangle {
    setDimensions(width, height){
        assert(width == height);
        super.setDimensions(width, height);
    }
} 

Если мы заменим Rectangle на Square в нашем первом коде, он сломается:

r = new Square();
// ...
r.setDimensions(1,2); // assertion width == height failed
r.fill(colors.red());
canvas.draw(r);

Это потому, что Square имеет новое предварительное условие, которого не было в классе Rectangle: width == height. Согласно LSP, Rectangle экземпляров должны быть заменены Rectangle экземплярами подкласса. Это связано с тем, что эти экземпляры проходят проверку типа для экземпляров Rectangle, и поэтому они вызовут непредвиденные ошибки в вашем коде.

Это был пример части "предварительные условия не могут быть усилены в подтипе" в вики-статья. Таким образом, нарушение LSP, вероятно, в какой-то момент вызовет ошибки в вашем коде.

LSP говорит, что «объекты должны заменяться их подтипами». С другой стороны, этот принцип указывает на

Дочерние классы никогда не должны нарушать определения типов родительского класса.

и следующий пример помогает лучше понять LSP.

Без LSP:

public interface CustomerLayout{

    public void render();
}


public FreeCustomer implements CustomerLayout {
     ...
    @Override
    public void render(){
        //code
    }
}


public PremiumCustomer implements CustomerLayout{
    ...
    @Override
    public void render(){
        if(!hasSeenAd)
            return; //it isn`t rendered in this case
        //code
    }
}

public void renderView(CustomerLayout layout){
    layout.render();
}

Фиксация LSP:

public interface CustomerLayout{
    public void render();
}


public FreeCustomer implements CustomerLayout {
     ...
    @Override
    public void render(){
        //code
    }
}


public PremiumCustomer implements CustomerLayout{
    ...
    @Override
    public void render(){
        if(!hasSeenAd)
            showAd();//it has a specific behavior based on its requirement
        //code
    }
}

public void renderView(CustomerLayout layout){
    layout.render();
}

Я рекомендую вам прочитать статью: Нарушение принципа замены Лискова (LSP).

Вы можете найти там объяснение, что такое принцип замещения Лискова, общие подсказки, которые помогут вам угадать, нарушили ли вы его, и пример подхода, который поможет вам сделать вашу иерархию классов более безопасной.

ПРИНЦИП ЗАМЕНЫ ЛИСКОВА (из книги Марка Земанна) утверждает, что мы должны иметь возможность заменить одну реализацию интерфейса другой, не нарушая ни клиента, ни реализации. Именно этот принцип позволяет удовлетворить требования, которые возникнут в будущем, даже если мы сможем » Я предвижу их сегодня.

Если мы отключим компьютер от сети (реализация), ни розетка (интерфейс), ни компьютер (клиент) не выйдут из строя (на самом деле, если это портативный компьютер, он может даже работать от батарей в течение определенного периода времени) . Однако в случае программного обеспечения клиент часто ожидает, что услуга будет доступна. Если сервис был удален, мы получаем исключение NullReferenceException. Чтобы справиться с ситуацией такого типа, мы можем создать реализацию интерфейса, которая «ничего не делает». Это шаблон проектирования, известный как «Нулевой объект» [4], и примерно соответствует отключению компьютера от стены. Поскольку мы используем слабую связь, мы можем заменить реальную реализацию чем-то, что ничего не делает, не вызывая проблем.

Принцип замены Ликова гласит, что , если программный модуль использует базовый класс, тогда ссылка на базовый класс может быть заменена на производный класс, не влияя на функциональность программного модуля.

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

Пример - Ковариантные возвращаемые типы в java.

Вот отрывок из этого сообщения, в котором хорошо проясняет ситуацию:

[..] Чтобы понять некоторые принципы, важно понимать, когда они были нарушены. Вот чем я сейчас займусь.

Что означает нарушение этого принципа? Это означает, что объект не выполняет контракт, налагаемый абстракцией, выраженной с помощью интерфейса. Другими словами, это означает, что вы неправильно определили свои абстракции.

Рассмотрим следующий пример:

interface Account
{
    /**
     * Withdraw $money amount from this account.
     *
     * @param Money $money
     * @return mixed
     */
    public function withdraw(Money $money);
}
class DefaultAccount implements Account
{
    private $balance;
    public function withdraw(Money $money)
    {
        if (!$this->enoughMoney($money)) {
            return;
        }
        $this->balance->subtract($money);
    }
}

Это нарушение LSP? да. Это связано с тем, что контракт на учетную запись сообщает нам, что учетная запись будет снята, но это не всегда так. Итак, что мне делать, чтобы это исправить? Я просто изменяю договор:

interface Account
{
    /**
     * Withdraw $money amount from this account if its balance is enough.
     * Otherwise do nothing.
     *
     * @param Money $money
     * @return mixed
     */
    public function withdraw(Money $money);
}

Вуаля, теперь договор выполнен.

Это незаметное нарушение часто заставляет клиента различать конкретные используемые объекты. Например, с учетом контракта с первым Аккаунтом он может выглядеть следующим образом:

class Client
{
    public function go(Account $account, Money $money)
    {
        if ($account instanceof DefaultAccount && !$account->hasEnoughMoney($money)) {
            return;
        }
        $account->withdraw($money);
    }
}

И это автоматически нарушает принцип открытого-закрытого [то есть требования о снятии денег. Потому что никогда не знаешь, что произойдет, если у объекта, нарушающего договор, не хватит денег. Возможно, он просто ничего не вернет, возможно, будет выброшено исключение. Поэтому вам нужно проверить hasEnoughMoney(), не является ли он частью интерфейса. Таким образом, эта принудительная проверка, зависящая от конкретного класса, является нарушением OCP].

Этот пункт также устраняет заблуждение, с которым я довольно часто сталкиваюсь, о нарушении LSP. В нем говорится, что «если поведение родителей изменилось в ребенке, значит, это нарушит LSP». Однако это не так - до тех пор, пока ребенок не нарушает договор со своим родителем.

В нем говорится, что если C является подтипом E, то E можно заменить объектами типа C без изменения или нарушения поведения программы. Проще говоря, производные классы должны заменять свои родительские классы. Например, если сын фермера - фермер, то он может работать вместо своего отца, но если сын фермера играет в крикет, он не может работать вместо своего отца. отец.

Пример нарушения:

public class Plane{

  public void startEngine(){}      

}        
public class FighterJet extends Plane{}
    
public class PaperPlane extends Plane{}

В данном примере классы FighterPlane и PaperPlane расширяют класс Plane, который содержит метод startEngine(). Итак, ясно, что FighterPlane может запустить двигатель, но PaperPlane не может, поэтому он ломается LSP.

PaperPlane класс, хотя и является расширением класса Plane и должен быть заменяемым вместо него, но не является подходящей сущностью, которой можно было бы заменить экземпляр Plane, потому что бумажный самолетик не может запустить двигатель, поскольку у него его нет. Итак, хороший пример:

Уважаемый пример:

public class Plane{ 
} 
public class RealPlane{

  public void startEngine(){} 

}
public class FighterJet extends RealPlane{} 
public class PaperPlane extends Plane{}

[SOLID]

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

В подтипе нельзя усилить предусловия.
Постусловия нельзя ослабить в подтипе.
Инварианты супертипа должны сохраняться в подтипе.

* Предусловие и постусловие: function (method) types ^{[Тип функции Swift. Функция Swift и метод]}

//C1 <- C2 <- C3

class C1 {}
class C2: C1 {}
class C3: C2 {}

• Предварительные условия (например, функция parameter type) могут быть такими же или более слабыми. (стремится к - ›C1)

• Постусловия (например, функция returned type) могут быть такими же или более сильными (стремится к - ›C3)

• Инвариантная переменная супертипа ^[About] должна оставаться неизменной.

Быстрый

class A {
    func foo(a: C2) -> C2 {
        return C2()
    }
}

class B: A {
    override func foo(a: C1) -> C3 {
        return C3()
    }
}

Джава

class A {
    public C2 foo(C2 a) {
        return new C2();
    }
}

class B extends A {

    @Override
    public C3 foo(C2 a) { //You are available pass only C2 as parameter
        return new C3();
    }
}

Подтип

• Sybtype не должен требовать от вызывающего больше, чем супертип
• Sybtype не должен открывать для вызывающего абонента меньше супертипа

Контравариантность типов аргументов и ковариация возвращаемого типа.

1. Контравариантность аргументов метода в подтипе.
2. Ковариация возвращаемых типов в подтипе.
3. Никакие новые исключения не должны генерироваться методами подтипа, за исключением случаев, когда эти исключения сами являются подтипами исключений, генерируемых методами супертипа.

[Дисперсия, ковариация, контравариантность]

Попробую, рассмотрим интерфейс:

interface Planet{
}

Это реализовано классом:

class Earth implements Planet {
    public $radius;
    public function construct($radius) {
        $this->radius = $radius;
    }
}

Вы будете использовать Землю как:

$planet = new Earth(6371);
$calc = new SurfaceAreaCalculator($planet);
$calc->output();

Теперь рассмотрим еще один класс, расширяющий Землю:

class LiveablePlanet extends Earth{
   public function color(){
   }
}

Теперь, согласно LSP, вы должны иметь возможность использовать LiveablePlanet вместо Земли, и это не должно нарушать вашу систему. Нравиться:

$planet = new LiveablePlanet(6371);  // Earlier we were using Earth here
$calc = new SurfaceAreaCalculator($planet);
$calc->output();

Примеры взяты здесь