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

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

Принцип подстановки Барбары Лисков (англ. Liskov Substitution Principle, LSP) в объектно-ориентированном программировании является специфичным определением подтипа, предложенным Барбарой Лисков в 1987 году на конференции в основном докладе под названием Абстракция данных и иерархия ^[1].

В последующей статье^[2] Лисков кратко сформулировала свой принцип следующим образом:

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

Роберт С. Мартин определил^[3] этот принцип так:

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

Таким образом, идея Лисков о «подтипе» даёт определение понятия замещения — если S является подтипом T, тогда объекты типа T в программе могут быть замещены объектами типа S без каких либо изменений желательных свойств этой программы (например, корректность).

Этот принцип является важнейшим критерием для оценки качества принимаемых решений при построении иерархий наследования. Сформулировать его можно в виде простого правила: тип S будет подтипом Т тогда и только тогда, когда каждому объекту oS типа S соответствует некий объект oT типа T таким образом, что для всех программ P, реализованных в терминах T, поведение P не будет меняться, если oT заменить на oS.

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

Саттер и Александреску в своём руководстве по использованию Си++ для выражения этого принципа также используют фразу «подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый класс». По мнению данных авторов, публичное наследование в Си++ можно употреблять только тогда, когда оно удовлетворяет принципу Лисков. Приватное наследование, по их же мнению, дозволено использовать для доступа к protected части базы и перекрытия виртуальных методов. В любом же ином случае, то есть для всего лишь повторного использования кода из базы, наследование применять нельзя.

Основания: использование публичного наследования для повторного использования кода приводит к тому, что внешний мир начинает считать класс Derived разновидностью класса Base, и возможно появление кода, явно использующего этот факт. Такое сильно сужает простор для манёвра архитектора в дальнейшем поддержании и рефакторинге класса Derived.

[править]Проектирование по контракту

Принцип подстановки (замещения) Лисков имеет близкое отношение к методологии проектирования по контракту, и ведет к некоторым ограничениям на то, как контракты могут взаимодействовать с наследованием:

• Предусловия не могут быть усилены в подклассе.

• Постусловия не могут быть ослаблены в подклассе.

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

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

В данном контексте принцип подстановки можно переформулировать следующим образом:

Функции, которые используют ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом.

Принцип Барбары Лисков заставляет задуматься о том, что такое «декларация типа» в терминах объектно-ориентированного языка программирования, который мы используем. Достаточно ли нам описать интерфейс объекта с помощью обычного абстрактного класса со списком методов, типами параметров и возвращаемого значения? Каким образом мы можем декларировать требования к значениям параметров метода и свойства, которыми будет обладать возвращаемое значение? Как нам описать исключения, которые может сгенерировать метод во время выполнения? Как нам описать изменение состояния объекта на разных этапах его жизненного цикла?

Задавая себе эти вопросы и находя ответы, можно спроектировать систему, которая действительно будет удовлетворять принципу подстановки Барбары Лисков.

Контрактное программирование

Материал из Википедии — свободной энциклопедии

Контрактное программирование (Design by Contract (DbC), или Programming by Contract) — это метод проектирования программного обеспечения. Он предполагает, что проектировщик должен определить формальные, точные и верифицируемые спецификации интерфейсов для компонентов системы. При этом, кроме обычного определенияабстрактных типов данных, также используются предусловия, постусловия и инварианты. Данные спецификации называются "контрактами" в соответствии с концептуальной метафорой условий и ответственностей в бизнес-контрактах.

[править]История

Термин предложил Бертран Мейер в связи с разработкой языка Eiffel. Контрактное программирование выросло из формальной верификации, формальной спецификации илогики Хоара. Контрактное программирование — это не только простая метафора, указывающая способ проектирования. Условия, облегчающие применение контрактного программирования:

• наличие наследования и возможность динамического связывания,

• способность обрабатывать исключения,

• возможность автоматической документации ПО.

[править]Описание

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

• конкретные обязательства, которые любой клиентский модуль должен выполнить перед вызовом метода — предусловия, которые дают преимущество для поставщика — он может не проверять выполнение предусловий;

• конкретные свойства, которые должны присутствовать после выполнения метода — постусловия, которые входят в обязательства поставщика;

• обязательства по выполнению конкретных свойств — инвариантов, которые должны выполняться при получении поставщиком сообщения, а также при выходе из метода.

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

В объектно-ориентированном программировании контракт метода обычно включает следующую информацию:

• возможные типы входных данных и их значение;

• типы возвращаемых данных и их значение;

• условия возникновения исключений, их типы и значения;

• присутствие побочного эффекта метода;

• предусловия, которые могут быть ослаблены (но не усилены) в подклассах;

• постусловия, которые могут быть усилены (но не ослаблены) в подклассах;

• инварианты, которые могут быть усилены (но не ослаблены) в подклассах;

• (иногда) гарантии производительности, например, временная сложность или сложность по памяти.

При использовании контрактов сам код не обязан проверять их выполнение. Обычно в таких случаях в коде делают жёсткое падение^{[уточнить]} («fail hard »), таким образом облегчая отладку выполнения контрактов. Во многих языках, таких как C, C++, Delphi, PHP, такое поведение реализуется оператором assert. В релизовом варианте кода это поведение может быть сохранено, либо проверки могут быть убраны чтобы повысить производительность.

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

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