Вопрос

Принцип открытости/закрытости гласит, что программные объекты (классы, модули и т. д.) должны быть открыты для расширения, но закрыты для модификации.Что это значит и почему это важный принцип хорошего объектно-ориентированного проектирования?

Это было полезно?

Решение

В частности, речь идет о «Святом Граале» проектирования в ООП, заключающемся в том, чтобы сделать объект достаточно расширяемым (за счет его индивидуального проектирования или участия в архитектуре), чтобы поддерживать будущие непредвиденные изменения без переписывания его кода (а иногда даже без перекомпиляции). **).

Некоторые способы сделать это включают полиморфизм/наследование, композицию, инверсию управления (т.н.DIP), аспектно-ориентированное программирование, такие шаблоны, как стратегия, посетитель, метод шаблона, и многие другие принципы, шаблоны и методы OOAD.

** См. 6 «принципов упаковки», РЭП, КПК, CRP, АДП, СДП, SAP

Другие советы

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

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

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

Более конкретно, чем DaveK, это обычно означает, что если вы хотите добавить дополнительную функциональность или изменить функциональность класса, создайте подкласс вместо изменения оригинала.Таким образом, любому, кто использует родительский класс, не придется беспокоиться о его изменении в дальнейшем.По сути, все дело в обратной совместимости.

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

Программные объекты должны быть открыты для расширения, но закрыты для модификации.

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

Плохой пример в Javascript

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

Теперь, если вы хотите добавить Другой тип Juice, вам придется отредактировать сам модуль. Таким образом, мы ломаем OCP.

Хороший пример в Javascript

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

Теперь вы можете добавлять новые типы соков вне модуля, не редактируя сам модуль.

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

Часто полиморфизм, например, с использованием интерфейсов, является хорошим инструментом для достижения этой цели.

Дополнительное практическое правило соответствия OCP — сделать базовые классы абстрактными по отношению к функциональности, предоставляемой производными классами.Или, как говорит Скотт Мейерс: «Сделайте нелистовые классы абстрактными».

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

Я просто хочу подчеркнуть, что «Открытый/Закрытый», хотя и очевидно полезен в объектно-ориентированном программировании, является здоровым методом, который можно использовать во всех аспектах разработки.Например, по моему собственному опыту, использование «Открыто/Закрыто» как можно чаще при работе с простым C — отличное обезболивающее.

/Роберт

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

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

Мне нравится думать о разделении открытого/закрытого режима на две тесно связанные части:

  • Код, который Открыть Чтобы измениться, можно либо изменить свое поведение для правильной обработки входных данных, либо потребовать минимальной модификации для обеспечения новых сценариев использования.
  • Код, который Закрыто для модификации не требуется большого вмешательства человека для обработки новых сценариев использования.Необходимости просто нет.

Таким образом, код, который демонстрирует поведение открытости/закрытости (или, если хотите, соответствует принципу открытости/закрытости), требует минимальных изменений или вообще не требует изменений в ответ на сценарии использования, выходящие за рамки тех, для которых он был изначально создан.

Что касается реализации?Я нахожу, что общепризнанная интерпретация «Open/закрыто относится к полиморфному коду!» быть в лучшем случае неполным утверждением.Полиморфизм в коде — один из инструментов достижения такого поведения;Наследование, реализация... на самом деле, каждый принцип объектно-ориентированного проектирования необходим для написания кода, который является устойчивым в том смысле, в котором это подразумевается этим принципом.

В принципе конструкции SOLID – буква «O» в слове «SOLID» обозначает принцип открытия/закрытия.

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

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

Преимущество принципа открытой закрытой конструкции:

  1. Приложение будет более надежным, поскольку мы не меняем уже протестированный класс.
  2. Гибкость, потому что мы можем легко удовлетворить новые требования.
  3. Легко тестируется и менее подвержен ошибкам.

Моя запись в блоге об этом:

http://javaexplorer03.blogspot.in/2016/12/open-closed-design-principle.html

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top