 |
|
|
|
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 { и его наследник – Square: class Square extends Rectangle { Примерно на этом месте стоит задуматься, насколько хорошая идея наследовать квадрат от прямоугольника и как они вообще связаны. Логика, что площадь у них считается в принципе одинаково: сторону умножить на сторону, сталкивается с жестокой реальностью состояния объекта. При попытке вызвать функцию вроде этой: public void areaNaive(Rectangle rectangle) { вы получите очень интересный результат. Да, на прямоугольнике все будет ок, но что будет на квадрате? Сначала его площадь 4, потом 25 и уж точно не 10. Можно разрулить ситуацию жесткой привязкой к типам, например так: public void areaNaive(Rectangle rectangle) { Но это точно не самая лучшая реализация. Здесь стоило бы с самого начала задуматься о том, будет ли такое наследование действительно удачным и не строить его только на факте, что площадь фигур одинаково считается. К слову, в первой статье этой серии публикаций[1] мы говорили о дублированном поведении. Про его существование тоже стоит помнить прежде, чем строить иерархию наследования. Пример выше довольно-таки упрощенный, давайте посмотрим на что-то более приближенное к реальной жизни. Скажем, на банковские счета. Допустим, исходно у нас есть только два варианта счета: один пополнение/снятие и другой счет с такими же функциями + кэшбэк. Пока что все укладывается примерно в такую картину: public class Account { Все хорошо, наследники не меняют исходные методы класса, только один лишь расширяет логику функционалом, связанным с кэшбэком. Принцип соблюден. И вот банк растет, запускает новые продукты, и приходит момент, когда должен появиться сберегательный счет, для которого доступно только пополнение. Как его вписать в исходную схему? public class SavingAccount extends Account { Так? Вот собственно такое решение и приведет к нарушению принципа подстановки Барбары Лисков, и к всем тем возможным последствиям, о которых мы говорили выше. Как правильно? Например, следующим образом: public class Account { Мы изменяем исходный класс и выделяем новый уровень абстракции. public class AccountWithWithdraw extends Account { Теперь у нас есть группы счетов: те, для которых снятие доступно, и те, для которых такой возможности нет. public class UsualAccount extends AccountWithWithdraw { В первую группу попадают наши исходные счета. А во вторую – как раз новый сберегательный продукт. public class SavingAccount extends AccountWithoutWithdraw { К чему можно придраться у такого решения? Во-первых, кто-то скажет, что это нарушение 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. Подпишитесь на журнал |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
