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

Лисков-что??

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

Все статьи серии

SOLID принципы на примере Laravel

Лисков-замещение-это-не-теория
– Быстрее, малыш! Какое самое большое простое число может быть выражено как сумма двух простых чисел?”

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

Это правило просто говорит, что код, работающий с родительскими классами (или интерфейсами), не должен ломаться, когда эти классы заменяются дочерними классами (или классами, реализующими интерфейс). Пример, который мы закончили непосредственно в предыдущей статье Принцип открытости/закрытости: SOLID принципы на примере Laravel, является отличной иллюстрацией: если я заменю универсальный тип PDFGenerator в аргументе метода конкретным экземпляром MilkyWayPDFGenerator, ожидаете ли вы, что код сломается или продолжит работать?

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

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

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

Автор: Анкуш Тхакур 9 ноября 2020 года

Рейтинг
( 7 оценок, среднее 5 из 5 )
Максим Гречушников/ автор статьи
Мне 40 лет, и больше половины жизни я занимаюсь разработкой. За это время я работал с корпоративными системами, highload-проектами, интеграциями, платежными решениями, внутренними платформами и legacy-кодом, который пережил не одного разработчика. Некоторые системы, кажется, переживут и нас. Моя специализация — PHP, Laravel, backend-архитектура, DDD, тестирование, рефакторинг и техническое лидерство. Мне интересны задачи, где нужно соединить код, бизнес, данные, процессы и здравый смысл. Последние годы я много работаю с LLM и AI-инструментами: использую их для проектирования, анализа кода, документации, тестов, ревью, работы с legacy и построения инженерных процессов. Для меня LLM — это не замена разработчику, а усилитель для тех, кто умеет думать системно. В блоге я пишу о Laravel, PHP, архитектуре, тестировании, инженерной практике, управлении разработкой и реальном применении AI в работе программиста.
Понравилась статья? Поделиться с друзьями: