Без SOLID никуда или куда?

Дйствительно ли SOLID так нужен Java разработчику?

Итак –«S» или Single Responsible принцип единственной ответственности. По-простому один класс с одним методом. Вроде бы хороший принцип. Но как быть с родовым классом Object содержащего уйму методов изменения? Сам класс Object может быть и переопределён и наследован и серилиализован и десериализован. Как тогда быть с «S» принципом?

Или «О» принцип, тот которой Open Closed. Все бы хорошо, но дженирки и дженерики тут как то плохо вписываются. А ведь есть еще PECSпринцип для наших дженериков.

А «L» в честь мадам Лисковой. Разве не сам Г. Шилдт писал нам, что все что находится слева от знака равенства ( инициализация класса) обязательно должно быть интерфейсом? Это было задолго до SOLIDации.

Или принцип ”I”. Прекрасный принцип. Но большинство кода написанного разработчиками содержит инициализацию строк:

String str = “User”;

….

//Много строчек различного кода который может быть написан другим разработчиком

…

String string2=”User”;

И строк в приложении очччеееень много. Естественно, что для сокращения времени разработки нам проще создать еще одну переменную с уже существующим значением, потому что у нас нет единого файла – словаря, содержащего текстовые поля приложения (Хотя братва из Oracle рекомендует использовать файлы как хранилища строковых представлений).

Например, в одном из наших приложений было более 12 000 строк дублирующих слово –«Отчет». 12 000 объектов типа стринг – «сожрали» больше чем все другие объекты, ведь были еще ссылки на различные сервисы, которых всего не больше 50, но ссылок на них было больше 1500 и памяти соответственно для каждого объекта. И эту отожранную память бедолага сборщик мусора должен был постоянно проверять на наличие возможности удаления ссылок. Он, сборщик мусора, даже чуть не уволился.

«D» принцип, ну вообще странно звучит. Мол большое не должно зависеть от малого. Хорошо, когда один разработчик пишет все приложение сам, все документирует сам и сам все изменяет. В противном случае если кто-то другой будет использовать класс, созданный другим разработчиком (а учитывая, что в редкой организации ведется сопроводительная документация в полном и качественном объеме), то зависимость обязательно всплывет и обязательно всплывет в самый неподходящий момент

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