Comments 24
Да хватит уже пинать бедный SOLID.
Как будто это серебряная пуля и гарантия от того, что в коде не будет неподдерживаемого говна.
Искусство разработчика и определяется пониманием где можно прибить гвоздями, а где необходимо оставить гибкость.
Черт с ним даже то, что это очередная из немыслимого числа статей о SOLID (за ~20 то лет...), хуже то что абсолютно непонятно для чего (какую задачу решает, какую информацию дает в общем какой в ней смысл) эта статья...
Все эти запахи кода и эвристические правила…
Только недавно озадачивался как перевести code smell в итальянской документации по стат анализу проекта в SonarQube. https://ru.wikipedia.org/wiki/Код_с_запашком
Хороший, обстоятельный материал. Вообще, вдумчивость и следование принципам - это похвально. Но мне кажется, этого мало. Лично я вижу за любыми принципами универсальные интуиции (идеалы), приходящие с опытом естественным образом, из практики. Более того, решающее значение имеет не столько само следование принципу, сколько мера (разумная достаточность). Вы видели вещи, доводимые до абсурда в состоянии, например, опьянения перфекционизмом? Я - да. И сам грешил! И как легко в этом случае прикрыться принципом, обманывая себя и других (банальная рационализация) необходимостью такой работы. Поэтому, смысла в их декламировании я большого не вижу. Уж сколько раз сталкивался с прекрасно заученными концепциями, которые почему-то упускаются или применяются "через край" (здрасте, микросервисы), как только начинается реальная работа, а не досужие разговоры.
И вот тут я процитирую один комментарий с сайта Роберта Мартина:
А почему вы не цитируете ответ Мартина?:)
You begin by talking about OOD and by the end of the first paragraph
have made the most critical of errors: equating OOD with OOP. OOA/D is
about THINKING. OOP is about DOING. The two are separate.
* It took me over half a decade to realize that this wasn't true. OOP and OOD are inseparable. OOA is undefined. - UB
Но вообще я с вами согласен ООП != ООД.
Блин, а я думал в статье будут конкретные примеры, очень интересно как эти принципы будут реализованы в процедурном стиле. В идеале - по мотивам https://github.com/torvalds/linux, который как раз представляет собой гигантский проект с приемлемым качеством и реализованный в полностью процедурном стиле. Это было бы гораздо убедительнее.
Проблема в том, что понятие "Абстракция" применяется только к ООП. Хотя, если подумать, это более общее, чем ООП.
Собственно ООП это одна из абстракций, так же как ФП, базы данных и прочее.
А SOLID это просто список критериев хорошей абстракции. Но SOLID сформулирован в терминах ООП.
В базах данных уже есть принципы нормализации №1...№6 обязательные для всех нормальных dba. А в программировании нет никаких принципов.
На каждый говнокод должен быть какой-нибудь стандартный совет: "это нарушает принцип ххх...", но их нет, все принципы слишком абстрактные, чтоб можно было на них опираться в споре.
То же относится и к коду — он должен писаться осознанно и с пониманием того, как принимаемые решения соотносятся со стоящими задачами. Если кто-то пишет код по методичке — то это не программист, а кодер.
Бесстыжий плаг
С одной стороны я с вами согласен - многие принципы, включая солид, действительно слишком абстрактные.
С другой стороны есть вполне конкретные - принцип ацикличных зависимостей, например.
Согласованный набор таких принципов я пытаюсь собрать в Эргономичном подходе: https://azhidkov.pro/posts/22/04/220409-ergo-approach-v10m1/
Знаете, если вы скажете, что код, написанный кем-либо нарушает какой-то из принципов SOLID, то так же получите вопрос: "И чо" и гугл ответ не даст. Для того, чтобы ответить, требуется опыт. Требуется на конкретном коде показать к чему это может привести.
Есть ещё нюанс: на любое правило можно найти 10 нарушений в стандартной библиотеке мейнстримного языка.
Согласен, недостаточно сказать какой принцип нарушается. Нужно уметь объяснить "и чо". Даже опыт не помогает объяснить - опыт вырабатывает неформализованные ощущения плохого кода. Для того чтобы объяснить - требуется отдельная практика, отдельные усилия.
Молодость и наивность - всегда сквозит из всех статей о "чистом коде", "лучших практиках" и "чистой архитектуре". Главные проблемы взрослых продуктов родом с управленческих этажей. Там свои тараканы, бюджеты, КПИ и интриги вокруг важных ресурсов. Масштабируемость фирмы и процессов в ней - это основные факторы, которые ведут к говнокоду. В нормальной компании юниору никто не даст нагадить в архитектуру, дурака никто не наймет, а на зеленых лужайках пасутся единорожки ;)
Я был немного удивлён и решил уточнить этот вопрос в чате, где обитают backend разработчики. Оказалось, что каждый седьмой из них придерживался такой точки зрения: “SOLID это только про ООП”
Ответ на поверхности: если вы введёте в google слово SOLID, то самая верхняя ссылка будет, конечно, на википедию, где страница прямо так и озаглавлена: “SOLID (объектно-ориентированное программирование)”. Все следующие за ней ссылки также вторят — “объектно ориентированное программирование”, но уже не в заголовке, а в основном тексте. Чтобы развеять это заблуждение, я обращаюсь к истокам.
SOLID как и вся книжка Мартина - это про императивный стиль программирования. Поскольку ООП, стало в некотором роде, для многих, лучшей практикой императивного программирования, SOLID приравнивают к ООП.
SOLID-а не существует и не может существовать в функциональной парадигме. По той причине, что проблемы которые разрешает SOLID не существует в ФП. Строго говоря, SOLID это попытка превратить махровую императивщину в нечто похожее на ФП. Потому, что по сути, покажите любому программисту ФП принципы SOLID и он Вам скажет - ээээ так это же описание того же лямбда исчисления только стоя на голове и в противогазе.
примерно такое же время на одном замечательном функциональном языке flow9.
flow9 это не функциональный язык. Да он позволяет писать в функциональном стиле (как например и С), но он Вас никогда не ударит по рукам за то, что Вы стали делать что-то по другому. По этой причине, я рискну предположить, что Вы не написали ни одной программы в функциональном стиле. Потому как, было бы иначе, Вы бы не "натягивали" SOLID на все вокруг. Опять же по той причине, что внутри FP нет проблем которые решает SOLID, как и вся книжка Мартина.
Принцип программирования иной. Иными словами FP программист уже пишет так, как это мог бы сделать программист императивного стиля следуя SOLID. Только в случае FP это естественное следствие парадигмы, там нельзя иначе. А в случае императивной парадигмы - это необходимость бить по руками за то, что позволяет делать сама императивная парадигма.
А почему вы решили, что flow9 не функциональный язык? По каким маркерам можно определить функциональный язык по вашему?
Если язык, допускает любые лексические конструкции, которые невозможны при FP, то это не функциональный язык. Возможно мультипарадигменный, то есть допускающий существование кода в форме отличающейся от функциональной.
Например JavaScript называется мультипарадигменным языком потому, что на нем можно писать в функциональном стиле, однако, он с легкостью Вам позволит создавать массу сайд эффектов и не ударит за это по рукам, в отличии от функционального языка, который просто не будет иметь самих возможностей осуществить подобные манипуляции.
Это крайне важно для компилятора любого функционального языка, поскольку следствия тех, или иных, особенностей FP, являются необходимой базой для эффективной компиляции и/или интерпретации кода.
По этой причине, JS это не функциональный язык, хотя он более чем позволяет писать код в функциональном стиле. Как и Flow9.
Семь раз отмерь, а SOLID все равно не про ООП. Монолог об архитектуре