Open-Closed Principle
принцип открытости/закрытости
принцип открытости/закрытости
Программные сущности должны быть открыты для расширения и закрыты для изменения. Сделать систему легко расширяемой и обезопасить её от влияния изменений
— разделение объявлений функциональности и её реализаций для старых модулей.
— добавление новых реализаций использует интерфейсы, которые принадлежат старым модулям (старый код)
Открытость
— Класс можно назвать открытым, если он доступен для
расширения.
Например
у вас есть возможность расширить набор его операций или добавить к нему новые поля, создав собственный подкласс.
Закрытость
— класс можно назвать закрытым (законченным), если он готов для использования другими классами
— интерфейс класса уже окончательно определён и не будет изменяться в будущем
— Если класс уже был написан, одобрен, протестирован,
возможно, внесён в библиотеку и включён в проект, после
этого пытаться модифицировать его содержимое не
желательно. Вместо этого, вы можете создать подкласс и
расширить в нём базовое поведение, не изменяя код
родительского класса напрямую.
— Но не стоит следовать этому принципу буквально для
каждого изменения. Если вам нужно исправить ошибку в
исходном классе, просто возьмите и сделайте это. Нет
смысла решать проблему родителя в дочернем классе.
— разделение объявлений функциональности и её реализаций для старых модулей.
— добавление новых реализаций использует интерфейсы, которые принадлежат старым модулям (старый код)
Открытость
— Класс можно назвать открытым, если он доступен для
расширения.
Например
у вас есть возможность расширить набор его операций или добавить к нему новые поля, создав собственный подкласс.
Закрытость
— класс можно назвать закрытым (законченным), если он готов для использования другими классами
— интерфейс класса уже окончательно определён и не будет изменяться в будущем
— Если класс уже был написан, одобрен, протестирован,
возможно, внесён в библиотеку и включён в проект, после
этого пытаться модифицировать его содержимое не
желательно. Вместо этого, вы можете создать подкласс и
расширить в нём базовое поведение, не изменяя код
родительского класса напрямую.
— Но не стоит следовать этому принципу буквально для
каждого изменения. Если вам нужно исправить ошибку в
исходном классе, просто возьмите и сделайте это. Нет
смысла решать проблему родителя в дочернем классе.