Принцип подстановки Барбары Лисков — The Liskov Substitution Principle или LSP — один из пяти основных принципов объектно-ориентированного программирования и проектирования SOLID, сформулированных Робертом Мартином.
Принцип в формулировке Роберта Мартина декларирует, что функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом. Оригинальное определение Барбары Лисков более формальное и заметно сложнее для восприятия: «В том случае, если q(x) — свойство, верное по отношению к объектам х некого типа T, то свойство q(y) тоже будет верным относительно ряда объектов y, которые относятся к типу S, при этом S — подтип некого типа T».
Следование принципу LSP заключается в том, что при построении иерархий наследования создаваемые наследники должны корректно реализовывать поведение базового типа. То есть если базовый тип реализует определённое поведение, то это поведение должно быть корректно реализовано и для всех его наследников.
LSP перекликается с контрактным программированием, определяя точные, формальные и верифицируемые описания интерфейсов. И интерфейсы, реализумые наследниками, должны соответствовать контракту интерфейсов базового класса.
Наследник класса дополняет, но не заменяет поведение базового класса. То есть в любом месте программы замена базового класса на класс‑наследник не должна вызывать проблем. Если по каким‑то причинам так не получается, то вероятнее всего имеет место либо некорректная реализация, либо неверно выбранная абстракция для наследования.
Соблюдение принципа подстановки Барбары Лисков позволяет гарантировать, что любой созданный нами подкласс будет без проблем использоваться ранее реализованными модулями, которые работали с надклассом. А это существенно упрощает расширение функциональных возможностей системы.
Но LSP, как и любой другой принцип, не является догмой. И иногда следование этому принципу при построении архитектуры может приводить к более ресурсоёмкой реализации, нежели работа с нарушением этого принципа. Но как и с любыми другими правилами — надо осознавать возможные последствия нарушения.
Тематические статьи
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться. YAGNI основан на идее, что большинство «гипотетических» возможностей, которые кажутся полезными на этапе проектирования, никогда не будут востребованы. Реализуя их заранее, разработчики тратят время, усложняют код и повышают риск ошибок.
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности. Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
SOLID это аббревиатура пяти основных принципов проектирования в объектно-ориентированном программировании, предложенных Робертом Мартином:
Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются. Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также значительно проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение. Если над проектом работает команда, а не один‑два разработчика, то обязательно должен быть стандарт оформления кода — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков.
TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов. При следовании этой методологии тесты пишутся до написания кода. TDD основывается на повторении коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест, а после этого проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов.
Наши услуги
ЦифровизацияФормализуем и автоматизируем бизнес‑процессы, осуществляем системную интеграцию, разрабатываем и внедряем цифровые решения, повышающие эффективность бизнеса.
РазработкаРазрабатываем сложные веб‑приложения и сайты. Создаём как отдельные инструменты для бизнеса, так и полноценные цифровые системы по индивидуальным требованиям.
Веб-сервисы и веб‑приложенияРазрабатываем веб‑приложения различной направленности и технически сложные веб‑сервисы.
Разработка корпоративных информационных системCоздаём как комплексные ERP‑системы для бизнеса, так и более специализированные информационные системы — CRM, WMS, BPMS, экспертные и аналитические системы, системы поддержки принятия решений, коммуникативные сервисы и многое другое.
Поддержка проектов и DevOpsОсуществляем комплексную поддержку ИТ‑проектов для обеспечения высокой работоспособности и улучшения продуктовых метрик.
ОтказоустойчивостьРазрабатываем и сопровождаем комплексные системы, устойчивые к отказу оборудования, отдельных сервисов и целых подсистем.
БыстродействиеРазрабатываем веб‑приложения, работающие по‑настоящему быстро: генерация страниц осуществляется за доли секунды, а загрузка сайта даже на медленных каналах занимает не более пары секунд.
Высокие нагрузкиМы создаём сайты и веб‑приложения, которые выдерживают десятки тысяч обращений в минуту без сбоев и без снижения скорости работы.