Уточните открытый / закрытый принцип

Как я уже объяснил, принцип открытия / закрытия гласит, что однажды написанный код не должен изменяться (кроме исправлений ошибок). Но если мои бизнес-правила меняются, не должен ли я изменить код, реализующий эти изменения? Я подозреваю, что я не понимаю, как принцип, потому что это не имеет смысла для меня.

Это, наверное, самый сложный из твердых принципов, чтобы объяснить. Дай мне попробовать. Представьте, что вы написали класс Invoice, который отлично работает и не содержит ошибок. Это делает PDF счета-фактуры.

Затем кто-то говорит, что хочет получить HTML-счет со ссылками. Вы не изменяете какой-либо код в инвойсе для удовлетворения этого запроса. Вместо этого вы создаете другой класс, HTMLInvoice, который делает то, что они сейчас хотят. Вы используете наследование, чтобы вам не пришлось писать много повторяющегося кода в HTMLInvoice.

Старый код, который использовал старую Invoice, не поврежден и не затронут. Новый код может использовать HTMLInvoice. (Если вы также делаете лисковскую заменяемость , L твердого тела, вы можете передать экземпляры HTMLInvoice существующему коду, ожидающему экземпляры Invoice.) Все живут долго и счастливо.

Счет закрыт для модификации, открыт для расширения. И вы должны написать счет заранее, чтобы это работало, кстати.

Вы читали статью « Принцип открытых дверей» от приятелей дяди Боба в ObjectMentor? Я думаю, что это одно из лучших объяснений.

Есть много эвристик, связанных с объектно-ориентированным дизайном. Например, «все переменные-члены должны быть частными», или «следует избегать глобальных переменных», или «использование идентификации типа во время выполнения (RTTI) опасно»). Каков источник этой эвристики? Что делает их правдой? Они всегда правдивы? В этой колонке исследуется принцип проектирования, лежащий в основе этой эвристики - принцип открытого-закрытого типа.

Как сказал Ивар Якобсон: «Все системы меняются в течение своих жизненных циклов. Это необходимо учитывать при разработке систем, которые, как ожидается, будут работать дольше, чем первая версия ». Как мы можем создавать проекты, которые стабильны перед лицом изменений и будут работать дольше, чем первая версия? Бертран Мейер дал нам руководство еще в 1988 году, когда он придумал известный теперь принцип открытого-закрытого типа. Перефразируя его:

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ (КЛАССЫ, МОДУЛИ, ФУНКЦИИ, И Т.Д.) ДОЛЖНЫ БЫТЬ ОТКРЫТЫ ДЛЯ РАСШИРЕНИЯ, НО ЗАКРЫТЫ ДЛЯ МОДИФИКАЦИИ.

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

Описание

Модули, которые соответствуют принципу открытого-закрытого, имеют два основных атрибута.

1. Они «открыты для расширения».
   Это означает, что поведение модуля может быть расширено. То, что мы можем заставить модуль вести себя по-новому и по-разному при изменении требований приложения или для удовлетворения потребностей новых приложений.
2. Они «закрыты для модификации».
   Исходный код такого модуля нерушим. Никто не может вносить изменения в исходный код.

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

Абстракция - это ключ ...

Ответ Кейт Грегори очень хорошо, но рассмотрим другую ситуацию , когда новое требование может быть удовлетворено сравнительно небольшое изменение в существующем Invoiceклассе. Например, допустим, новое поле должно быть добавлено в PDF-файл счета. Согласно OCP, мы все равно должны создать новый подкласс, даже если новое поле можно добавить в существующую реализацию, изменив несколько строк кода.

В моем понимании, OCP отражает реальность 80-х и начала 90-х годов, когда в проектах часто даже не использовался контроль версий, тем более автоматизированные регрессионные тесты или преимущества сложных инструментов рефакторинга. OCP была попыткой избежать риска взлома кода, который был вручную протестирован и запущен в производство. Сегодня у нас есть более эффективные способы управления риском взлома работающего программного обеспечения (а именно, системы контроля версий, TDD и автоматизированное тестирование, а также инструменты рефакторинга).

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

Мне очень трудно осознать тот факт, что абстракция является ключевой. Что если абстракция изначально была неправильной? Что если бизнес-функция значительно изменилась?

Этот принцип по существу гарантирует, что ОРИГИНАЛЬНЫЕ намерения и поведение проекта никогда не должны изменяться. Это, вероятно, работает для тех, у кого есть общедоступные API, и у их клиентов возникают проблемы с тем, чтобы не отставать от новых выпусков и некоторых других крайних случаев. Однако, если компания владеет ВСЕМ кодом, я оспариваю этот принцип.

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

Сказав это, если нет никаких тестов, то этот принцип является здравым.