Принцип открытости/закрытости

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

При́нцип откры́тости/закры́тости (англ. The Open Closed Principle, OCP) — принцип ООП, устанавливающий следующее положение: «программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения»;[1]

« Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
Bertrand Meyer
»

Описание[править | править код]

Принцип открытости/закрытости означает, что программные сущности должны быть:

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

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

Термин «принцип открытости/закрытости» имеет два значения:

  • Принцип открытости/закрытости Мейера
  • Полиморфный принцип открытости/закрытости

Оба значения используют наследование для решения дилеммы, но цели, способы и результаты — различны.

Принцип открытости/закрытости Мейера[править | править код]

Бертран Мейер в основном известен как основоположник термина Принцип открытости/закрытости[1], который появился в 1988 году в его книге Object-Oriented Software Construction, , отвечая на вопрос:

"Как можно разработать проект, устойчивый к изменениям, срок жизни которых превышает срок существования первой версии проекта?".

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

Определение Мейера поддерживает идею наследования реализации. Реализация может быть переиспользована через наследование, но спецификации интерфейса могут измениться. Существующая реализация должна быть закрыта для изменений, но новые реализации не обязаны использовать существующий интерфейс.

Полиморфный принцип открытости/закрытости[править | править код]

В течение 1990-х принцип открытости/закрытости стал де-факто переопределён для применения с абстрактными интерфейсами, реализации которых могут быть изменены, и могут быть созданы множественные реализации и полиморфно замещены одна на другую.

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

Статья Роберта С. Мартина «The Open-Closed Principle»[2] в 1996 была одной из плодотворных статей для популяризации такого подхода. В 2001 году Крэйг Ларман отнёс термин Принцип открытости/закрытости к шаблону Алистэра Кокбёрна (Alistair Cockburn), названного Protected Variations, и к обсуждению с Дэвидом Парнасом (David Parnas) о скрытии информации[3].

См. также[править | править код]

  • SOLID — буква «O» является аббревиатурой, которая образована сокращением от английского названия Принцип открытости/закрытости (англ. The Open Closed Principle)
  • Нарушение "Принципа открытости/закрытости" также затрагивает нарушение "Принципа единственной ответственности"

Ссылки[править | править код]

  1. 1 2 Meyer Bertrand. Object-Oriented Software Construction. — Prentice Hall, 1988. — ISBN 0136290493.
  2. Мартин, Роберт «The Open-Closed Principle», C++ Report, January 1996
  3. «Protected Variation: The Importance of Being Closed», IEEE Software May/June 2001, pp. 89-91 [1]

Гиперссылки[править | править код]