Как стать автором
Обновить

Комментарии 9

Абревиатуру SOLID выбрал один американец как красивое словосочетание, после того как тасуя первые буквы разных полезных принципов и идей наткнулся на красивое с точки зрения маркетинга слово. А теперь авторы разных статей и блогов разжёвывают именно эти 5 принципов и так и этак, объясняя нубам великое искусство "чистого кода" :)) Это очень забавно. Такое впечатление, что программирование из инженерной дисциплины превратилось в религию, со скрижалями с заповедями, проповедниками и паствой :))

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

И не важно, начнете ли вы читать «Совершенный код» Макконелла, «Рефакторинг» Фаулера, «Чистую архитектуру» дяди Боба или «Паттерны» от Банды четырех — все это передача ими эмпирического опыта в предметной области. Это не доказанные истины, не математически стройные и выверенные подходы. По большей части это укладывается в формулу: "я писал много-много лет, даже десятилетий, и кое-что понял, а то, что понял, хочу передать вам".

SOLID, YAGNI, DRY, KISS, DDD, TDD и так далее и тому подобное — все это инструменты, получившие широкую известность в профессии. Инструменты, которые стоит изучить, переняв опыт тех, кто это все собрал вместе и записал в красивые и запоминающиеся аббревиатуры.

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

Собственно, об этом сказано в заключительном слове в статье. Сектантство всегда плохо, догматизм того хуже. Ведь "только ситхи все возводят в абсолют". 😉

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

Robert Martin, автор SOLID и Clean Code, инженер? какой софт он написал, поищите в интернете. Товарищ уже 30+ лет зарабатывает на курсах, треннингах и книжках. Я посмотрел пример рефакторинга из его книжки, и там нормальные совершенно методы в классе разбиваются на какие то микро-методы по 3 строки, и куча локальных переменных выносится на уровень полей класса -- большего говно-кода сложно представить, и этот человек чему то будем учить настоящих инженеров? Чтобы учить каким то хорошим принципам, нужно понимать где они применяются, а где нет, т к любую хорошую идею можно довести до абсурда. Такие как Robert Martin, которые занимаются курсами, а не разработкой, не понимают где хорошие идеи превращаются во вредные, поэтому у них чем больше тем лучше, и те кто начинают слепо следовать их проповедям зачастую не знают где остановиться, просто потому что их кумир сам это не знает и этому не учит.

Не читал Clean Code, но в Clean Architecture всё достаточно банально и логично. Что же касается любых книжек с примерами чего угодно - синтетические примеры не обязаны отражать реальность, они должны быть пригодны для использования в нужном аспекте. К сожалению, я очень много сталкивался с критикой вида "Х дурак, потому что в примере Y он сделал плохо Z", в том время как в примере Y вообще не надо обращать внимание на Z, он про дргуие аспекты. Я так же слышал много критики вида "если везде применять Y, описанный в книге, получится плохо" - это тоже не вполне корректная вещь, есть методы которые приенимы везде, есть методы которые применимы в ограниченном числе случаев. Уметь отличать их - тоже часть профессии и я не думаю, что 100% формализация применимости всегда возможна

D в solid это Dependency inversión, а не injection. Принципиально разные вещи.

Да, именно так. В статье это как раз в таком виде и отражено - Принцип инверсии зависимостей (Dependency Inversion Principle). О чём именно речь?

Мы захотели сделать наш код открытым для изменений и закрытым для расширения в соответствии с SOLID → мы применили паттерн «Стратегия» → паттерн «Стратегия» буквально основывается на принципе инверсии зависимостей из SOLID → а сама инверсия

скорее всего вы имели ввиду закрытым для изменения и открытым для расширения

Да, именно так, спасибо. Поправил в тексте.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий