Всем привет!

Раз уж я начал говорить про SOLID - рассмотрим еще одну букву - O.
Open-closed principe - принцип открытости-закрытости.

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

Второй уровень - как можно сделать Open, т.е. расширить функционал? Наследование. Да, наследование - это хорошо. Но я отлично помню монолит с огромными иерархиями наследования, уровней по 10+. Бегать по этой иерархии искать где и что используется и точно ли я ничего не сломаю в новом наследнике - такое себе удовольствие. Да и SonarQube ругается, и правильно делает).
Альтернативы:
1) композиция и агрегация - объект базового класса можно включить в себя как поле, и уже в новом классе реализовать нужные требования. https://metanit.com/sharp/patterns/1.2.php
2) частный случай предыдущего пункта - паттерны декоратор и прокси, когда мы реализуем тот же интерфейс, что и базовый класс. См. разницу https://t.me/javaKotlinDevOps/124
3) комбинация аннотации и аспекта, реализующего дополнительное поведение над определенным методом класса
4) аннотации и создание прокси класса через CGLib или аналогичную библиотеку

Третий уровень - как правильно сделать Close? Закрыли мы класс для изменений, поставили final. А там конструкция вида:
private final List<String> POSIBLE_STORAGES = List.of("Oracle", "EhCache");
и далее везде в коде сохранения выбор из этих двух вариантов...
При желании наверняка обойти можно, но это значит, что автор класса не подумал про принцип открытости-закрытости.
Нужно было выносить в отдельный метод, а еще лучше - в отдельный объект Storage.

#arch #solid #inteview_question