Liskov Substitution Principle::Журнал СА
www.samag.ru
Журнал «БИТ. Бизнес&Информационные технологии»      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Подписка
Архив номеров
Где купить
Наука и технологии
Авторам
Рекламодателям
Контакты
   

  Опросы
  Статьи

ИТ-инфраструктура  

Системы мониторинга ИТ-инфраструктуры-2025

Без мониторинга ИТ-инфраструктуры не обходится ни одна компания, хотя бы потому, что

 Читать далее...

Открытое ПО  

Безопасность Open Source: рискуем или контролируем?

Компания «Кросс технолоджис» изучила, как используется ПО с открытым кодом в компаниях

 Читать далее...

Работа с нейросетью  

Скажи, есть ли у тебя AI, и я скажу, кто ты

Недавно сервис по поиску работы SuperJob выяснил, что каждый второй россиянин уже

 Читать далее...

Работа с Debian  

О Linux с любовью или Debian: через знание к любви

Конечно, одним лишь перечислением замечательных качеств любовь к Linux не возникнет. Для

 Читать далее...

Опрос  

Защита личных и клиентских данных: как мошенники используют ИИ и как защититься?

По данным RED Security, общее число кибератак на российские компании в 2024

 Читать далее...

Опрос  

Облачные инструменты для разработчиков

Эксперты ИТ-отрасли отвечают на вопросы «Системного администратора» > Как с помощью облака сделать

 Читать далее...

Опрос  

Рынок мобильных приложений: что будет актуальным в 2025 году?

Эксперты ИТ-отрасли отвечают на вопросы «Системного администратора» > Ваши прогнозы: чего ожидать от

 Читать далее...

Рынок труда  

Как успешно пройти все этапы собеседования на ИТ-должность?

По оценкам государства, дефицит ИТ-специалистов составляет от 740 тысяч до 1 миллиона

 Читать далее...

Спецпроект «Базальт СПО». Развитие Open Source в России  

Алексей Смирнов: «Сейчас трудно найти программный продукт, в котором нет свободного кода»

Какое будущее ждет свободное ПО? Влияет ли свободная или несвободная разработка на

 Читать далее...

Спецпроект «Базальт СПО». Развитие Open Source в России  

Николай Костригин: «Мы создали Hantis, конвейер автоматизации. Проекты, исследуемые разными инструментами, переходят от одного исполнителя к другому, развиваются, возвращаются к автору, и так по кругу»

О том, как идет работа по повышению безопасности отечественного программного обеспечения, рассказывает

 Читать далее...

1001 и 1 книга  
19.03.2018г.
Просмотров: 7742
Комментарии: 0
Машинное обучение с использованием библиотеки Н2О

 Читать далее...

12.03.2018г.
Просмотров: 8005
Комментарии: 0
Особенности киберпреступлений в России: инструменты нападения и защита информации

 Читать далее...

12.03.2018г.
Просмотров: 5353
Комментарии: 0
Глубокое обучение с точки зрения практика

 Читать далее...

12.03.2018г.
Просмотров: 3413
Комментарии: 0
Изучаем pandas

 Читать далее...

12.03.2018г.
Просмотров: 4208
Комментарии: 0
Программирование на языке Rust (Цветное издание)

 Читать далее...

19.12.2017г.
Просмотров: 4215
Комментарии: 0
Глубокое обучение

 Читать далее...

19.12.2017г.
Просмотров: 6733
Комментарии: 0
Анализ социальных медиа на Python

 Читать далее...

19.12.2017г.
Просмотров: 3564
Комментарии: 0
Основы блокчейна

 Читать далее...

19.12.2017г.
Просмотров: 3831
Комментарии: 0
Java 9. Полный обзор нововведений

 Читать далее...

16.02.2017г.
Просмотров: 7727
Комментарии: 0
Опоздавших не бывает, или книга о стеке

 Читать далее...

17.05.2016г.
Просмотров: 11084
Комментарии: 0
Теория вычислений для программистов

 Читать далее...

30.03.2015г.
Просмотров: 12806
Комментарии: 0
От математики к обобщенному программированию

 Читать далее...

18.02.2014г.
Просмотров: 14581
Комментарии: 0
Рецензия на книгу «Читаем Тьюринга»

 Читать далее...

13.02.2014г.
Просмотров: 9518
Комментарии: 0
Читайте, размышляйте, действуйте

 Читать далее...

12.02.2014г.
Просмотров: 7486
Комментарии: 0
Рисуем наши мысли

 Читать далее...

10.02.2014г.
Просмотров: 5760
Комментарии: 4
Страна в цифрах

 Читать далее...

18.12.2013г.
Просмотров: 4965
Комментарии: 0
Большие данные меняют нашу жизнь

 Читать далее...

18.12.2013г.
Просмотров: 3822
Комментарии: 0
Компьютерные технологии – корень зла для точки роста

 Читать далее...

04.12.2013г.
Просмотров: 3498
Комментарии: 0
Паутина в облаках

 Читать далее...

03.12.2013г.
Просмотров: 3729
Комментарии: 1
Рецензия на книгу «MongoDB в действии»

 Читать далее...

Друзья сайта  

 Liskov Substitution Principle

Архив номеров / 2024 / Выпуск №3 (256) / Liskov Substitution Principle

Рубрика: Разработка /  Принципы проектирования

 ВИЗИТКА 



Ольга Федорова,
технический лидер «Альфа банка»

 

Liskov Substitution Principle

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

 

Продолжая цикла статей, посвященный SOLID, на этот раз мы рассмотрим Liskov Substitution Principle или «принцип подстановки Барбары Лисков». И прежде, чем перейти к конкретным примерам в коде, давайте немного поговорим об авторе, чье имя (единственное, между прочим) официально вошло в наименование принципа.

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

Интересно то, что формулировка принципа была разработана еще в 1987 году, но наибольшую известность она получила уже в последующей интерпретации Роберта Мартина и, в принципе, весьма понятно почему…

Итак, оригинал звучит примерно следующим образом: пусть q(x) является свойством верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

В поздней и более адаптированной версии, вошедшей в SOLID, принцип упрощен до «Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом».

Звучит уже лучше, но все еще не очень понятно, поэтому предлагаю упростить до «Есть класс A и его наследник B. Если мы заменим все вызовы класса A на B, ничего не должно измениться в работе программы». А теперь давайте рассмотрим, что все это значит на практике.

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

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

Можно внести ряд мелких изменений, например, сузить тип выбрасываемого исключения в Java. Условно был IoException, стал FileNotFoundException (который является его наследником). Насколько это соответствует исходному принципу? Так и так вы ожидаете, что в числе прочего может вылететь FileNotFoundException, поэтому все ок.

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

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

Итак, у нас есть класс Rectangle следующего вида:

public class Rectangle {
   protected int width;
   protected int height;

   public void changeWidth(int width) {
       this.width = width;
   }

   
public void changeHeight(int height) {
       this.height = height;
   }

   
public int area() {
       return this.width * this.height;
   }
}

и его наследник – Square:

class Square extends Rectangle {
   public void changeWidth(int width) {
       this.width = width;
       this.height = width;
   }

   public void changeHeight(int height) {
       this.width = height;
       this.height = height;
   }
}

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

public void areaNaive(Rectangle rectangle) {
   rectangle.changeWidth(2);
   rectangle.changeHeight(5);

   assert rectangle.area() == 10;
}

вы получите очень интересный результат. Да, на прямоугольнике все будет ок, но что будет на квадрате? Сначала его площадь 4, потом 25 и уж точно не 10. Можно разрулить ситуацию жесткой привязкой к типам, например так:

public void areaNaive(Rectangle rectangle) {
   rectangle.changeWidth(2);
   rectangle.changeHeight(5);

   if (rectangle.getClass().equals(Square.class)) {
       assert rectangle.area() == 25;
   } else {
       assert rectangle.area() == 10;
   }
}

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

К слову, в первой статье этой серии публикаций[1] мы говорили о дублированном поведении. Про его существование тоже стоит помнить прежде, чем строить иерархию наследования.

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

Пока что все укладывается примерно в такую картину:

public class Account {
   protected Long amount;

   public void addMoney(Long sum) {
      this.amount = this.amount + sum;
   }
   public void withdrawMoney(Long sum) {
       this.amount = this.amount - sum;
   }
}

public class
UsualAccount extends Account {
}

public class CashbackAccount extends Account {
   public void calculateCashback() {
       // ...
   }
}

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

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

public class SavingAccount extends Account {
   public void withdrawMoney(Long sum) {
       // do nothing
   }
   public void calculateInterestRate() {
       // ...
   }
}

Так? Вот собственно такое решение и приведет к нарушению принципа подстановки Барбары Лисков, и к всем тем возможным последствиям, о которых мы говорили выше.

Как правильно? Например, следующим образом:

public class Account {
   protected Long amount;

   public void addMoney(Long sum) {
      this.amount = this.amount + sum;
   }
}

Мы изменяем исходный класс и выделяем новый уровень абстракции.

public class AccountWithWithdraw extends Account {
   public void withdrawMoney(Long sum) {
       this.amount = this.amount - sum;
   }
}

public class AccountWithoutWithdraw extends Account{
}

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

public class UsualAccount extends AccountWithWithdraw {
}

public class
CashbackAccount extends AccountWithWithdraw {
   public void calculateCashback() {
       // ...
   }
}

В первую группу попадают наши исходные счета. А во вторую – как раз новый сберегательный продукт.

public class SavingAccount extends AccountWithoutWithdraw {
   public void calculateInterestRate() {
       // ...
   }
}

К чему можно придраться у такого решения?

Во-первых, кто-то скажет, что это нарушение open-closed, мы же меняем исходные, хорошо протестированные классы. В ответ напомню про фразу из нашей прошлой статьи[2]: OCP не запрещает нам менять содержимое классов, но призывает заранее думать о том, чтобы таких ситуаций было гораздо меньше, т.е. напрямую подталкивает к использованию абстракции.

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

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

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

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



Ключевые слова: SOLID, LSP, Liskov Substitution Principle, Роберт Мартин, Барбара Лисков

 

[1] Single Responsibility Principle («Системный администратор», №1-2 (254-255), 2024, стр.62.

[2] Open Closed Principle («Системный администратор», №1-2, 2024 (254-255), стр.64.


Подпишитесь на журнал

Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-45
E-mail: sa@samag.ru