Принципы SOLID: принцип подстановки Барбары Лисков
Принцип подстановки Барбары Лисков — The Liskov Substitution Principle или LSP — один из пяти основных принципов объектно-ориентированного программирования и проектирования SOLID, описанных Робертом Мартином.
Принцип в формулировке Роберта Мартина декларирует, что функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом. Оригинальное определение Барбары Лисков более формальное и заметно сложнее для восприятия: «В том случае, если q(x) — свойство, верное по отношению к объектам x некого типа T, то свойство q(y) тоже будет верным относительно всех объектов y, которые относятся к типу S, при этом S — подтип некого типа T.»
Следование принципу LSP заключается в том, что при построении иерархий наследования создаваемые наследники должны корректно реализовывать поведение базового типа. То есть если базовый тип реализует определённое поведение, то это поведение должно быть корректно реализовано и для всех его наследников.
LSP перекликается с контрактным программированием, которое определяет точные, формальные и верифицируемые описания интерфейсов. И интерфейсы, реализуемые наследниками, должны соответствовать контракту интерфейсов базового класса.
Наследник класса дополняет, но не заменяет поведение базового класса. То есть в любом месте программы замена базового класса на класс‑наследник не должна вызывать проблем. Если по каким‑то причинам так не получается, то вероятнее всего имеет место либо некорректная реализация, либо неверно выбранная абстракция для наследования.
Соблюдение принципа подстановки Барбары Лисков позволяет гарантировать, что любой созданный нами подкласс будет без проблем использоваться ранее реализованными модулями, которые работали с надклассом. А это существенно упрощает расширение функциональных возможностей системы.
Но LSP, как и любой другой принцип, не является догмой. И иногда следование этому принципу при построении архитектуры может приводить к более ресурсоёмкой реализации, нежели реализация с нарушением этого принципа. Но, как и с любыми другими правилами, надо осознавать возможные последствия нарушения.
- Принцип единственной ответственности
- Принцип открытости / закрытости
- Принцип подстановки Барбары Лисков
- Принцип разделения интерфейса
- Принцип инверсии зависимостей
Тематические статьи
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться. YAGNI основан на идее, что большинство «гипотетических» возможностей, которые кажутся полезными на этапе проектирования, никогда не будут востребованы. Реализуя их заранее, разработчики тратят время, усложняют код и повышают риск ошибок.
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности. Большая часть программных систем необоснованно перегружена практически ненужными функциями, что ухудшает удобство их использования конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
SOLID — это аббревиатура, введённая Майклом Физерсом для пяти основных принципов проектирования в объектно-ориентированном программировании:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются. Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение. Если над проектом работает команда, а не один‑два разработчика, то обязательно должен быть стандарт оформления кода — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков.
TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов. При следовании этой методологии тесты пишутся до написания кода. TDD основывается на повторении коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест, а после этого проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов.
Наши услуги
Давайте обсудим ваш проект
Заполните короткий бриф или свяжитесь с нами удобным вам способом
