Как я уже объяснил, принцип открытия / закрытия гласит, что однажды написанный код не должен изменяться (кроме исправлений ошибок). Но если мои бизнес-правила меняются, не должен ли я изменить код, реализующий эти изменения? Я подозреваю, что я не понимаю, как принцип, потому что это не имеет смысла для меня.
Ответы:
Это, наверное, самый сложный из твердых принципов, чтобы объяснить. Дай мне попробовать. Представьте, что вы написали класс Invoice, который отлично работает и не содержит ошибок. Это делает PDF счета-фактуры.
Затем кто-то говорит, что хочет получить HTML-счет со ссылками. Вы не изменяете какой-либо код в инвойсе для удовлетворения этого запроса. Вместо этого вы создаете другой класс, HTMLInvoice, который делает то, что они сейчас хотят. Вы используете наследование, чтобы вам не пришлось писать много повторяющегося кода в HTMLInvoice.
Старый код, который использовал старую Invoice, не поврежден и не затронут. Новый код может использовать HTMLInvoice. (Если вы также делаете лисковскую заменяемость , L твердого тела, вы можете передать экземпляры HTMLInvoice существующему коду, ожидающему экземпляры Invoice.) Все живут долго и счастливо.
Счет закрыт для модификации, открыт для расширения. И вы должны написать счет заранее, чтобы это работало, кстати.
Вы читали статью « Принцип открытых дверей» от приятелей дяди Боба в ObjectMentor? Я думаю, что это одно из лучших объяснений.
Есть много эвристик, связанных с объектно-ориентированным дизайном. Например, «все переменные-члены должны быть частными», или «следует избегать глобальных переменных», или «использование идентификации типа во время выполнения (RTTI) опасно»). Каков источник этой эвристики? Что делает их правдой? Они всегда правдивы? В этой колонке исследуется принцип проектирования, лежащий в основе этой эвристики - принцип открытого-закрытого типа.
Как сказал Ивар Якобсон: «Все системы меняются в течение своих жизненных циклов. Это необходимо учитывать при разработке систем, которые, как ожидается, будут работать дольше, чем первая версия ». Как мы можем создавать проекты, которые стабильны перед лицом изменений и будут работать дольше, чем первая версия? Бертран Мейер дал нам руководство еще в 1988 году, когда он придумал известный теперь принцип открытого-закрытого типа. Перефразируя его:
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ (КЛАССЫ, МОДУЛИ, ФУНКЦИИ, И Т.Д.) ДОЛЖНЫ БЫТЬ ОТКРЫТЫ ДЛЯ РАСШИРЕНИЯ, НО ЗАКРЫТЫ ДЛЯ МОДИФИКАЦИИ.
Когда одно изменение в программе приводит к каскаду изменений в зависимых модулях, эта программа демонстрирует нежелательные атрибуты, которые мы привыкли ассоциировать с «плохим» дизайном. Программа становится хрупкой, жесткой, непредсказуемой и не подлежащей повторному использованию. Принцип «открыто-закрыто» атакует это очень простым способом. Это говорит о том, что вы должны разрабатывать модули, которые никогда не меняются . Когда требования меняются, вы расширяете поведение таких модулей, добавляя новый код, а не изменяя старый код, который уже работает.
Описание
Модули, которые соответствуют принципу открытого-закрытого, имеют два основных атрибута.
- Они «открыты для расширения».
Это означает, что поведение модуля может быть расширено. То, что мы можем заставить модуль вести себя по-новому и по-разному при изменении требований приложения или для удовлетворения потребностей новых приложений.- Они «закрыты для модификации».
Исходный код такого модуля нерушим. Никто не может вносить изменения в исходный код.Казалось бы, эти два атрибута расходятся друг с другом. Обычный способ расширить поведение модуля - внести изменения в этот модуль. Обычно считается, что модуль, который нельзя изменить, имеет фиксированное поведение. Как можно разрешить эти два противоположных атрибута?
Абстракция - это ключ ...
Ответ Кейт Грегори очень хорошо, но рассмотрим другую ситуацию , когда новое требование может быть удовлетворено сравнительно небольшое изменение в существующем Invoiceклассе. Например, допустим, новое поле должно быть добавлено в PDF-файл счета. Согласно OCP, мы все равно должны создать новый подкласс, даже если новое поле можно добавить в существующую реализацию, изменив несколько строк кода.
В моем понимании, OCP отражает реальность 80-х и начала 90-х годов, когда в проектах часто даже не использовался контроль версий, тем более автоматизированные регрессионные тесты или преимущества сложных инструментов рефакторинга. OCP была попыткой избежать риска взлома кода, который был вручную протестирован и запущен в производство. Сегодня у нас есть более эффективные способы управления риском взлома работающего программного обеспечения (а именно, системы контроля версий, TDD и автоматизированное тестирование, а также инструменты рефакторинга).
Лично я думаю, что этот принцип должен быть взят с щепоткой соли. Кодекс органичен, предприятия меняются и код меняется в зависимости от потребностей бизнеса с течением времени.
Мне очень трудно осознать тот факт, что абстракция является ключевой. Что если абстракция изначально была неправильной? Что если бизнес-функция значительно изменилась?
Этот принцип по существу гарантирует, что ОРИГИНАЛЬНЫЕ намерения и поведение проекта никогда не должны изменяться. Это, вероятно, работает для тех, у кого есть общедоступные API, и у их клиентов возникают проблемы с тем, чтобы не отставать от новых выпусков и некоторых других крайних случаев. Однако, если компания владеет ВСЕМ кодом, я оспариваю этот принцип.
Наличие хорошего тестового покрытия вашего кода должно сделать рефакторинг вашей кодовой базы легким. Это означает, что можно ошибиться - ваши тесты помогут вам улучшить дизайн.
Сказав это, если нет никаких тестов, то этот принцип является здравым.