Принцип подстановки Барбары Лисков

@AlexMarkov · Регистрация: 10.09.2019

Студворк — интернет-сервис помощи студентам

Не понятен пример применения принципа ООП на python:

Главная идея, стоящая за Liskov Substitution Principle в том, что для любого класса клиент должен иметь возможность использовать любой подкласс базового класса, не замечая разницы между ними, и следовательно, без каких-либо изменений поведения программы при выполнении. Это означает, что клиент полностью изолирован и не подозревает об изменениях в иерархии классов.
Более формально: Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
Проще говоря, это значит, что подкласс, дочерний класс должны соответствовать их родительскому классу или супер классу.

Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
class User():
  def __init__(self, color, board):
    create_pieces()
    self.color = color
    self.board = board
  def move(self, piece:Piece, position:int):
      piece.move(position)
      chessmate_check()
  board = ChessBoard()
  user_white = User("white", board)
  user_black = User("black", board)
  pieces = user_white.pieces
  horse = helper.getHorse(user_white, 1)
  user.move(horse)

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

Рассказали бы своими словами, в чем фича данного примера?

@Catstail · 20.06.2021, 13:08

Мне кажется, для понимания желательно привести пример неправильной организации

@Viktorrus · 21.06.2021, 19:35

Arsegg, dondublon, Я понял свою ошибку. Нельзя вмешиваться в обсуждение того, с чем не знаком. Я не знаю , что такое Liskov Substitution Principle. Прошу извинить за не корректное поведение.

@AlexMarkov · 21.06.2021, 19:39 **[ТС]**

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

@Arsegg · 21.06.2021, 19:49

Не по теме:

Viktorrus, а за что извиняться? На то он и форум, чтобы обсуждать и узнавать что-то новое. Ошибкой было бы оставаться в неведении, имхо.

@AlexMarkov · 21.06.2021, 19:52 **[ТС]**

https://itnan.ru/post.php?c=1&p=505430 - статья в картинках для лучшего понимания начинающим данных принципов ООП. Да, инкапсуляция, наследование и полиморфизм - это фундаментальные принципы ООП, но не стоит забывать, что данные принципы применялись и использовались в 80-х годах прошлого столетия. Современные реалии требуют новых абстракций для реализации поставленных задач.

@Viktorrus · 21.06.2021, 20:42

AlexMarkov, Я все таки попробовал разобраться в Liskov Substitution Principle воспользовавшись предложенной ссылкой. Оказалось я интуитивно оказался прав, Liskov Substitution Principle не всегда работает и может приводить к ошибкам, для исправления которых нужен дополнительный код, вносящий исправление в Liskov Substitution Principle.
Из материала по ссылке в переводе:

Кликните здесь для просмотра всего текста

"Если S является подтипом T, то объекты типа T могут быть заменены объектами типа S без изменения корректности программы. Важно: В приведенном выше коде функция calculate всегда возвращает число (произведение a и b). Нарушить принцип подстановки Лискова

Каждый подкласс калькулятора должен реализовать функцию вычисления, которая возвращает число. Давайте нарушим этот принцип, создав функцию вычисления, которая также может вызвать ошибку. В этом примере добавляется класс DividerCalculator (наследуется от Calculator), где переопределенная функция calculate вызывает ошибку, когда Python пытается разделить на ноль. Нет никакого способа исправить этот код без:

Рефакторинг иерархии классов или
перенос каждого вызова вычисления в код try/except

Здесь мы узнаем, что класс DividerCalculator отличается от класса Calculator следующим образом:

Умножение двух чисел всегда приводит к числу
Деление двух чисел приводит к числу или ошибке

Это делает тип результата другим, а следовательно, и интерфейс другим. Умножение и деление-это не одно и то же, когда дело доходит до типа результата, и одно не должно вытекать из другого. Подозрительный код

Как вы можете обнаружить подозрительный код, который может нарушить принцип подстановки Лискова? Помимо приведенного выше кода, вот еще несколько плохих примеров: Решите проблему

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

Это может привести к большему количеству кода, и это нормально. Когда ваши товарищи по команде начнут жаловаться на это, теперь вы можете объяснить им, почему вы приняли такое решение. Написание правильного кода более важно, чем написание компактного кода. Вернитесь к старому коду и найдите унаследованные классы с переопределенными функциями, которые имеют сбивающие с толку возвращаемые значения, такие как -1, пустые строки, 9999 или функции, вызывающие исключения. Скорее всего, вы обнаружили нарушение принципа замены Лискова."

Добавлено через 2 минуты
Я дал перевод только текстов, без кодов, подтверждающих текст. Полностью смотрите в оригинале по ссылке.

https://www.pythonforeveryone.... ython.html

Добавлено через 14 минут
AlexMarkov, В чем тонкость понимания принципа.
"Если S является подтипом T, то объекты типа T могут быть заменены объектами типа S без изменения корректности программы."
Это работает только в том случае, когда объекты типа T имеют только те атрибуты, которые описаны в классе T. Но нужно понимать, что любой объект типа Т может иметь и другие, индивидуальные атрибуты, присущие только ему. И при замене такого объекта типа Т объектом типа S, эти индивидуальные атрибуты могут не работать для S. Пример этого дан по ссылке.
Вывод.
Принцип Liskov Substitution Principle можно применять, но только с умом, так как он не всегда может работать, и тогда придется применять дополнительный код, что бы избежать ошибки. О чем и говорится по ссылке.

Добавлено через 10 минут
AlexMarkov, Может я не верно описал причину ошибки, которая приведена в примере по ссылке. Но не суть важно. Важно понимать, что ошибки при применении этого принципа могут быть. И поэтому нужно это иметь ввиду и быть осторожным в его применении.

Добавлено через 11 минут
AlexMarkov, Я остаюсь при своем мнении. Лучший способ избежать ошибок при ООП, это моделировать человеческое мышление, которое отражает реальную действительность.
Если ваши рассуждения при решении задачи будут верными, то будет верным и код ООП моделирующий эти рассуждения.
При условии, что вы правильно смоделировали (правильно применили ООП).

Новые блоги и статьи Все статьи Все блоги /
Алиса нашла кучу ошибок компиляции и запуска в проекте, который без проблем компилировался и запускался))) anaschu 30.06.2026 Я пока посмеюся, но завтра проверю. А вообще интерсно. Дал алисе файл, в котором точно нет ошибок компиляции и запуска, и попросил их найти. Нашла кучу))) Критические ошибки, мешающие компиляции и. . .	сукцессия 16. Общий обзор, в основном что бы другие ии поняли anaschu 29.06.2026 # Передаточный документ: модель микоризной сукцессии (для нового чата) Этот документ предназначен для того, чтобы новый чат Claude мог продолжить работу без необходимости заново разбираться в. . .	сукцессия 15 неявная схема anaschu 29.06.2026 Алиса Калибровка параметров симбиотической модели: технический обзор Содержание: Введение Постановка проблемы Технические аспекты реализации Процесс внедрения изменений	сукцессия 14. Обновленная схема модели anaschu 28.06.2026 ГЛОБАЛЬНАЯ ОПИСАТЕЛЬНАЯ СПЕЦИФИКАЦИЯ ЭКОСИСТЕМНОЙ МОДЕЛИ «SOIL CHEMISTRY & MYCORRHIZA 2. 0» https:/ / ibb. co/ NnkGpfMd Представленная интегрированная схема описывает непрерывную нелинейную. . .
сукцессия 13. Питон модель трехзонного мицелия, пока что в основном арбускулярного anaschu 28.06.2026 ## Разработка агентной модели микоризной сукцессии: от выявления артефактов к созданию комплексной системы ### Аннотация Представлено исследование по разработке агентной модели микоризной. . .	сукцессия 12. краткий список проверок модели перед запуском. anaschu 27.06.2026 Скрытые отказы в моделях систем динамики (SD-models) экологических систем: два случая из практики Контекст Разбирался прототип модели систем динамики (SD-модели) микоризной сукцессии: пять. . .	Сукцессия 11. Проверка орудий перед войной: разработка через тестирование anaschu 27.06.2026 Как не дать модели соврать самой себе: проверки для симуляции микоризной сукцессии Введение Когда вы строите математическую модель живой системы — грибов, растений, почвы — главная опасность. . .	10 сукцессия. Питон код войны грибов и растений anaschu 27.06.2026 import numpy as np class PlantAgent: def __init__(self, name, strategy, initial_biomass): self. name = name self. strategy = strategy # "greedy" (широколиственные) или. . .

@Catstail Супер-модератор 38209 / 21142 / 4312 Регистрация: 12.02.2012 Сообщений: 34,755 Записей в блоге: 14
	20.06.2021, 13:08
	Мне кажется, для понимания желательно привести пример неправильной организации 1

@Viktorrus 1732 / 970 / 199 Регистрация: 22.02.2018 Сообщений: 2,693 Записей в блоге: 6
	21.06.2021, 19:35
	Arsegg, dondublon, Я понял свою ошибку. Нельзя вмешиваться в обсуждение того, с чем не знаком. Я не знаю , что такое Liskov Substitution Principle. Прошу извинить за не корректное поведение. 0

@AlexMarkov 99 / 86 / 20 Регистрация: 10.09.2019 Сообщений: 708
	21.06.2021, 19:39 [ТС]
	Viktorrus, несмотря на то, что данное сообщение адресовано не мне, как ТС скажу, что ваши вопросы позволили мне прийти к лучшему пониманию данного принципа. 0

@Arsegg
	21.06.2021, 19:49
	Не по теме: Viktorrus, а за что извиняться? На то он и форум, чтобы обсуждать и узнавать что-то новое. Ошибкой было бы оставаться в неведении, имхо. 0

@AlexMarkov 99 / 86 / 20 Регистрация: 10.09.2019 Сообщений: 708
	21.06.2021, 19:52 [ТС]
	https://itnan.ru/post.php?c=1&p=505430 - статья в картинках для лучшего понимания начинающим данных принципов ООП. Да, инкапсуляция, наследование и полиморфизм - это фундаментальные принципы ООП, но не стоит забывать, что данные принципы применялись и использовались в 80-х годах прошлого столетия. Современные реалии требуют новых абстракций для реализации поставленных задач. 0

@Viktorrus 1732 / 970 / 199 Регистрация: 22.02.2018 Сообщений: 2,693 Записей в блоге: 6
	21.06.2021, 20:42
	AlexMarkov, Я все таки попробовал разобраться в Liskov Substitution Principle воспользовавшись предложенной ссылкой. Оказалось я интуитивно оказался прав, Liskov Substitution Principle не всегда работает и может приводить к ошибкам, для исправления которых нужен дополнительный код, вносящий исправление в Liskov Substitution Principle. Из материала по ссылке в переводе: Кликните здесь для просмотра всего текста "Если S является подтипом T, то объекты типа T могут быть заменены объектами типа S без изменения корректности программы. Важно: В приведенном выше коде функция calculate всегда возвращает число (произведение a и b). Нарушить принцип подстановки Лискова Каждый подкласс калькулятора должен реализовать функцию вычисления, которая возвращает число. Давайте нарушим этот принцип, создав функцию вычисления, которая также может вызвать ошибку. В этом примере добавляется класс DividerCalculator (наследуется от Calculator), где переопределенная функция calculate вызывает ошибку, когда Python пытается разделить на ноль. Нет никакого способа исправить этот код без: Рефакторинг иерархии классов или перенос каждого вызова вычисления в код try/except Здесь мы узнаем, что класс DividerCalculator отличается от класса Calculator следующим образом: Умножение двух чисел всегда приводит к числу Деление двух чисел приводит к числу или ошибке Это делает тип результата другим, а следовательно, и интерфейс другим. Умножение и деление-это не одно и то же, когда дело доходит до типа результата, и одно не должно вытекать из другого. Подозрительный код Как вы можете обнаружить подозрительный код, который может нарушить принцип подстановки Лискова? Помимо приведенного выше кода, вот еще несколько плохих примеров: Решите проблему Проблема обычно вызвана наследованием класса S от класса T, где S и T кажутся связанными, но имеют одно или несколько фундаментальных различий в интерфейсе. Вы можете решить эту проблему с помощью таких хаков, как подозрительный код выше, или увеличить или уменьшить уровни абстракции в иерархии классов. Это может привести к большему количеству кода, и это нормально. Когда ваши товарищи по команде начнут жаловаться на это, теперь вы можете объяснить им, почему вы приняли такое решение. Написание правильного кода более важно, чем написание компактного кода. Вернитесь к старому коду и найдите унаследованные классы с переопределенными функциями, которые имеют сбивающие с толку возвращаемые значения, такие как -1, пустые строки, 9999 или функции, вызывающие исключения. Скорее всего, вы обнаружили нарушение принципа замены Лискова." Добавлено через 2 минуты Я дал перевод только текстов, без кодов, подтверждающих текст. Полностью смотрите в оригинале по ссылке. https://www.pythonforeveryone.... ython.html Добавлено через 14 минут AlexMarkov, В чем тонкость понимания принципа. "Если S является подтипом T, то объекты типа T могут быть заменены объектами типа S без изменения корректности программы." Это работает только в том случае, когда объекты типа T имеют только те атрибуты, которые описаны в классе T. Но нужно понимать, что любой объект типа Т может иметь и другие, индивидуальные атрибуты, присущие только ему. И при замене такого объекта типа Т объектом типа S, эти индивидуальные атрибуты могут не работать для S. Пример этого дан по ссылке. Вывод. Принцип Liskov Substitution Principle можно применять, но только с умом, так как он не всегда может работать, и тогда придется применять дополнительный код, что бы избежать ошибки. О чем и говорится по ссылке. Добавлено через 10 минут AlexMarkov, Может я не верно описал причину ошибки, которая приведена в примере по ссылке. Но не суть важно. Важно понимать, что ошибки при применении этого принципа могут быть. И поэтому нужно это иметь ввиду и быть осторожным в его применении. Добавлено через 11 минут AlexMarkov, Я остаюсь при своем мнении. Лучший способ избежать ошибок при ООП, это моделировать человеческое мышление, которое отражает реальную действительность. Если ваши рассуждения при решении задачи будут верными, то будет верным и код ООП моделирующий эти рассуждения. При условии, что вы правильно смоделировали (правильно применили ООП). 1