#12 SOLID принципы в 2024: Полный разбор и прожарка / S0ER

Какие заключаются принципы SOLID, в чём правы (или нет) Барбара Лисков и Роберт Мартин и как солид влияет на архитектуру ПО? В этом видео дискутируем вместе с Евгением Сергеевым, автором канала S0ER и архитектором ПО, о специфичности SOLID для некоторых стеков программирования и о том, как скиллы программиста влияют на принятие решений.

✅ Подписывайтесь на канал «Организованное программирование» в Telegram
– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие)
– Смотреть в ВК Видео
– Вы узнаете об инверсии зависимостей (DIP), принципе открытости-закрытости (OCP), роли интерфейсов в командной работе, взаимосвязи SRP с другими принципами SOLID и многом другом. Особое внимание уделяется принципу Барбары Лисков, его влиянию на архитектуру программного обеспечения и тому, как эти принципы нарушаются в реальной практике. Мы обсудим, как квалификация программистов и бизнес-требования могут влиять на применение этих принципов, а также рассмотрим важность их понимания для успешного развития в программировании.

00:00 Введение и обзор в SOLID
09:38 Изменение значений и применения принципов Solid
12:32 Инверсия зависимости и работа с абстракциями
16:00 Применение DIP для упрощения изменений
19:57 Ограничения и сложности DIP в фронтенд-разработке
21:51 Принцип инверсии зависимостей (DIP) в больших командах и проектах
24:46 Инверсия управления (IOC) и решение проблемы инверсии зависимостей
28:55 Внедрение зависимостей (DI) и использование IOC-контейнера
34:15 Осмысленное применение принципов DIP и IOC
37:04 Прямая зависимость и использование интерфейсов
43:25 Гибкий и расширяемый код
45:28 Ограничения системы типов и зависимые типы
53:18 Влияние принципов SOLID на архитектуру
55:49 Типы как множество возможных значений
57:57 Факторы, влияющие на нарушение принципов
01:03:40 Идеальный код и принятие решений в сложных условиях
01:16:13 Введение в принципы DIP и OCP
01:22:37 Применение принципов DIP и OCP в разработке
01:31:46 Роль доменных событий в программировании
01:34:35 Масштабирование и распределенные системы в событийной модели
01:37:57 Понимание и применение принципов SOLID через общение с опытными разработчиками и изучение хороших примеров кода
01:41:02 Разные взгляды на Single Responsibility Principle
01:50:26 Иллюзия понимания и вдохновение от SRP
01:53:27 Влияние SRP на архитектуру программных систем
01:57:14 Распределение обязанностей и архитектура приложений
02:01:20 Связь SRP с другими принципами SOLID
02:04:30 Роль принципов SOLID в разработке программного обеспечения
02:06:49 SOLID как продукт, продаваемый Робертом Мартином

#программирование #it #solid

★ Support this podcast ★

Creators & Guests

Host

Кирилл Мокевнин

сооснователь Хекслета, ведущий подкаста «Организованное программирование»

Guest

Евгений Сергеев

автор канала S0ER, архитектор ПО, амбасадор здравого смысла

What is Организованное программирование?

Пишем код, за который не стыдно. Разбираем базу, даем рекомендации и встречаемся с умными людьми

(00:00.046)
Короче, тема Солида, она... Давай так, самый пик, наверное, мы можем сказать, что прошел, когда об этом говорили все на всех собесах, про это говорили, кричали. Сейчас этого гораздо меньше, но оно присутствует. Наверное, можно сказать, что она чуть более специфична для каких -то стэков. Каких -то вообще об этом не говорят, каких -то говорят об этом постоянно и так далее. Есть книжки, есть новички, есть опытные ребята. И даже несмотря на то, что об этом за последние там сколько -то лет, много десяток, ну десяток точно уж лет, да.

всё это тысячу раз переговорили, всё равно периодически вспыхивает, как только кто -то хоть один из этих элементов затрагивает. И сегодня, собственно, мы чё, пришли попробовать? Мы решили попробовать формат дебатов, когда я играю адвоката Дьявола, ну, конечно же, не настолько, чтобы прям совсем всё отрицать, да, потому что, понятное дело, мы про здравый смысл, но я скорее ближе к тому, что сомневаюсь, ты ближе к тому, что надо.

А дальше как получится? Кто его знает, может мы в конце концов и свищнемся местами, убедив друг друга в каких -то штуках. Отлично.

(01:17.006)
Знаешь, с чего начал? Вот этот набор, Solid. Как ты считаешь, глобально является ли это фундаментальным принципом того, проектировать программы, относящимся вообще ко всем? То есть, все программисты, всех мастей должны к этому прислушаться, потому что для них важно. Или все -таки это специфика каких -то стэков, языков, направлений и так далее? Слушай, я как бы тоже хотел обозначить небольшое такое...

дисклаймер, то есть у нас дебаты, но при этом нужно понимать, что однозначно сказать, что solid нужен или однозначно сказать, что solid не нужен, очень сложно. Почему? Потому что существует огромное количество задач и огромное количество ситуаций, поэтому неплохо понимать, что в solid хорошо, что в solid плохо, и в зависимости от этого искать баланс и те ситуации, когда он применим.

Поэтому, речь заходит, глобально это применимо к архитектуре любого программного обеспечения или нет, это всегда лукавство. что, ну начнем с того, что Solit появился в общем -то рука об руку с объектно -ориентированным программированием, и многие его принципы очень хорошо матчатся на объектно -ориентированное программирование. При этом, происходит некая подмена, же принцип Барбары Лисков, он от типов ушел классом, если можно сказать так.

Роберта Мартина, то он говорит о листках как о принципе наследования, как наследовать классы, то есть коварятное поведение классов для того, чтобы мы не упирались в различные неприятные ситуации, когда мы передаем вроде бы дочерний класс, а он нас не работает. Вот этот классический пример с квадратом и прямоугольником, который там в каждом учебнике хорошо разобран, кто говорит про солид, по крайней мере, про барбурлист, который очень часто встречается. Поэтому глобально

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

(03:44.846)
активно в моей жизни началась с 92 года, примерно тогда я начал что -то осознавать, что я хочу стать программистом, мы увидим, что отношение к разработке, регулярно менялось. Смотря на то, что и Барбара Лисков, и принцип открытости -закрытости, это в общем -то 80 -е, 90 -е, 70 -е годы, ну очень давно, я, честно, не смотрел вики когда, но это точно очень давно. Но при этом, что было, например, когда я начал программировать, это увлечение

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

И сейчас мало кто из всей массы программистов думает о том, что скомпилировался его исходный код, даже если он на компилируемом языке работает. Мало кто думает о byte, коде, java или C sharp. есть нам это стало неважно. И Егор Бугаенко недавно замечательную штуку сказал, что со временем мы поднимаемся на уровень все выше абстракции, и сейчас следующий вызов – это возможно ли генерировать какие -то коды с помощью искусственного интеллекта?

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

потому что у нас есть архитектура на уровне модулей. Это может быть набор классов, это может быть компонент, деление можно здесь немножко уточнять, модуль, содержимое которого нам не особо интересно, нам важно, чтобы этот модуль преследовал некую поставленную перед нами задачу, решал эту задачу. Поэтому для нас важно, как для программистов, чтобы этот модуль эффективно быстро создавался. И вот на самом деле, на мой взгляд, если почитать чистую архитектуру,

(06:08.078)
почитать Роберта Мартина, говорит как раз, что его принципы SOLID работают как раз на этом уровне чуть выше, код, на уровне, я бы сказал, программы. То есть мы смотрим, как компоновать наши классы, как компоновать наши модули, как устанавливать между ними взаимодействия, как предъявлять ним требования, как проводить границы. И тем самым, на мой взгляд, SOLID еще выстрелит, когда речь пойдет о том, что нам не нужно уметь по сути

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

дальнейшего повышения уровня абстракции в сторону архитектуры. Вот такое мое длинное мнение. Слушай, ну очень приятно слушать. И было много пунктов, которым хочется что -то сказать. Один из пунктов как раз про барбурлистков хочу тебе... Может быть, ты читал, может, не читал? Это было, может быть, год назад, когда у Роберта спросили, а как ты считаешь, спустя столько лет, Solit актуален или не актуален?

и он написал статью об этом у себя в блоге ты читал статью, что он там написал? я видел твое выступление, где ты на ссылался ну да, ну он там просто очень прикольно сказал, что типа я, как и многие другие там прям такими словами написано заблуждался в том, что такое принцип Барбары Лисков и во -первых, это просто забавно само по себе, да, что он реально от типов классом перешел, кстати, я когда этому учу, когда с людьми разговариваю, сразу, знаешь, бы кто -то говорит класс, я говорю, ага, понятно, тут есть, ну можно по -разному об этом говорить и

Главная, наверное, история, с которой я абсолютно согласен, и ее надо точно проговорить, о том, что большинство, для большинства Solid, мне кажется, это история, вот, когда непонятно, людям нужны простые шаги, простые действия и простые инструкции типа делай раз, делай два. Ну, так работает на массу, И Solid был всегда одним из таких вещей. Но любая такая штука, ты становишься ее заложником, если ты как бы не идешь дальше. Что я имею в виду? То, фактически споры вокруг Solida с...

(08:29.966)
скатываются к спору о терминах, что имел в виду конкретно автор, что конкретно там сказано. И это, знаешь, это примерно как эти грамма нации, когда ты начинаешь использовать язык и говорить какие -то слова не так, они такие вот, ты неправильно по русскому языку, так, не надо и все такое. Хотя на самом деле это работает ровно наоборот. Учебники подстраивают по то, как люди разговаривают. И здесь ровно то же самое, что все эти разговоры начинают сводиться к обсуждению терминов, что они обозначают, к чему они применяются и так далее. Хотя в реальности...

Даже вот сегодня, как я уже говорил, я потратил немножко с утра время на research, я читал еще немножко Reddit, думаю, ну что там поменялось -то. И там как раз об этом люди говорят, о том, что, что типа с тех 70 -х, примерно, когда все это появлялось, почти все это кардинально изменило свое значение и применение, Ну там, особенно некоторые принципы, да, например, open -close принцип, barber -lease -ков принцип, они на самом деле менялись.

и из -за этого получается, что у кучи людей в головах каша и, соответственно, бесконечные споры, срачи и все остальное ну и мы как бы тут тоже собрались в каком -то смысле то есть мы, конечно, можем сумным видом сказать, что да, все течет, меняется но, знаешь, без спора тоже как бы совсем нельзя вот такая примерно история, да если можно реплику, вот ты сказал, что SOLID помогает делать какое -то типизировать в некотором смысле свое поведение, принимать

какие -то решения, я считаю, что ты в этом прав. В каком смысле? В общем -то, работа разработчика, программиста и инженера – необходимость принятия решений в условиях недостаточной информации. есть, никогда не хватает полной информации для того, чтобы принять решение. Естественно, для того, чтобы принять решение, да еще так, в будущем можно было это решение, ну, как -то…

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

(10:37.134)
они помогают принимать решения. Это, знаешь, как в лабиринте жизни. Есть стратегия, всегда поворачивай направо, потому что там, если ты в лабиринте идешь, запутался, уперся в тупик, возвращаешься, всегда поворачивай налево, либо там хлебные крошки раскидывай. Ну самое неэффективное – это рандомно, ищи, пока не найдешь. Потому что если у тебя есть бесконечный запас времени, из любого лабиринта можно найти выход. Это факт, потому что ты количество вариантов конечным, все их переберешь рано или поздно.

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

поэтому здесь как повезет давай возьмем я бы знаешь начал не сначала я бы начал с конца вот мы потому что s такой самый немножко немножко такой принцип скажем просмысл и поэтому он чуть -чуть отличается от всех остальных я поэтому бы начал именно с d да с инверсии

давай сначала обозначим, о чем он на прикладном уровне. Вот прикладной разработчик, что для него обозначает? Здесь возникает некая зависимость как от языка программирования статистически и динамически компилируем и некомпилируем, потому что с одной стороны, классическое объяснение, насколько я его понимаю, заключается в том, что у нас есть поток управления программой

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

(12:53.486)
есть с минимальной зависимостью менять. То для меня инверсия зависимости заключается в том, что мы должны, ну по сути, высшая абстракция это интерфейс, то есть работать от интерфейса. Работа от интерфейса позволяет тебе максимально развивать себе руки с позиции последующего изменения компоновки программы, дистрибуции программы и развертывания. Вот как -то так, если бы на словах. Знаешь, я сейчас тоже скажу про эту штуку. Вот то, что ты рассказываешь, примерно

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

То есть эта штука, когда ты программируешь, например, на джаве, она очевидна, потому что ты просто с первой же секунды с этим сталкиваешься, у тебя действительно так построено очень многие вещи, понимаешь о чем я говорю. Поэтому это определение понятно только тем, кто понимает проблематику. Вот в чем прикол. Можно немножко возражу. В TypeScript 'е и TypeScript сегодня очень распространен, в том числе и React, и тоже есть секция импорта, и общем -то зависимость это то, что тебя находится в секции импорта.

это тоже достаточно легко объяснить да да да но я имею ввиду что это сильно упрощает понимание да то есть мы говорим о том что зависимость по сути это какие -то другие куски кода внешней библиотеки любой код который нам нужен да и я тогда попробую переформулировать мне кажется меня есть такое простое определение которое по крайней мере работает когда я учу этому людей о том что

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

(15:02.798)
проблема, которая на самом деле далеко не везде проблема, честно скажем, да, потому что если вы просто скрипт на питоне написали, вообще -то это не проблема. Вы дата -аналитика, вам надо просто из базы что -нибудь почитать. А если вы пишете какой -то серьезный софт, особенно, например, вы разрабатываете фреймворк, ну, мне кажется, это гораздо ближе к этим ребятам, вот когда прям совсем жестко, потому что во фронт -энде это часто об этом не парится, вы просто не можете так делать, потому что вы гвоздями прибиваетесь к такой реализации базы данных. Соответственно, вы не в тестах не можете ничего поменять, не...

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

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

От себя бы сказал, что есть такая штука – устойчивость классов, устойчивость интерфейсов. Это только количество зависимостей, которые к этому интерфейсу применяются. есть чем более устойчив интерфейс, тем больше от него зависит. Словно говоря, какой -нибудь интерфейс обращения к базе данных так много где используется, что любое внесение изменений в него будет требовать изменений во всех местах, где он используется. То есть мы название метода поменяли и тут же

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

(17:24.942)
ты максимально продумываешь их на этапе реализации, они становятся действительно устойчивыми, они тебя также везде используются, и тебе дорого становится менять только интерфейс, а не его реализацию. И вот для меня именно в этом пользу, что ты за счет инверсии зависимости можешь эффективно отвязаться от реализации и сильно упростить себе внесение изменений, подключить больше команд, разделить обязанности между людьми.

А когда ты напрямую, есть такой даже принцип, программируешь соответствующие с интерфейсами, а не реализацией, тоже довольно популярно. И это как бы дешевле вносить изменения. До тех пор, ты не меняешь интерфейс, тебе намного дешевле их вносить. Вот я бы так, если простым языком высказался. О, вот тут я вижу, что уже пошла разница. Можно об этом поговорить. Главное, слишком глубоко не утип. Я еще, знаешь, буду сейчас думать, пока мы разговариваем.

как нам разговаривать на таком уровне, чтобы у нас не уснула аудитория, потому что понятно, что можно очень глубоко уйти, и мы в это не нырнули. Что мне хочется сказать? Смотри, нас вообще в целом дип. То есть мы говорим, что чаще всего это приводит к тому, что мы начинаем инъектировать зависимости снаружи. И как правило, это в самых продвинутых системах делается через хитрую рефлексию.

dependency injection, мне кажется, это с DIP не так, чтобы сильно, прямо тесно связано. вот по моему представлению. Ну, точнее, связано, но они могут существовать. Это просто, да, да, да. Это имплементация, потому что есть разные языки и все такое. иногда нужно говорить о конкретике, чтобы мы тобой разобрали конкретные примеры, потому что я объясню, почему я об этом говорю. Вот, например, ты берешь frontend. Ну, то есть, короче, когда человек думает про DIP,

Все -таки если ты в спринге, ты очевидно будешь думать, что у тебя все понятно. Это правила игры, которым все привыкли. У тебя есть инверсия зависимости, ты завязываешься на интерфейсы. И в общем так из коробки работает. Поэтому для этих ребят это даже не вопрос обсуждения. Это просто так работает. Ты с молоком матери это впитал, как вообще чуть ли не часть языка. Так учат писать, если взять какие -то вузовские программы. Там всегда интерфейсы – это одна из составных частей обучения.

(19:44.238)
Ну, там суть не только в самих интерфейсах, а именно в том, что у тебя завязка на них, потому что через них все инъектируется, да. Потому что просто наличие интерфейсов же само по себе, честно говоря, не все значит. Ну, потому что можно прямую просто использовать. Здесь я соглашусь, но solid в принципе, полное исследование и правильное исследование солида, это еще не значит, что вас все будет хорошо. есть это остается очень много других проблем. И давай вот я про что скажу. Когда мы говорим про dip,

То есть глобально идея, если как это идея, то она понятна. Но в чем я вижу здесь проблему? Я вижу проблему, что она заявляет немножко опасную вещь. Что, типа, всегда надо оперировать абстракциями, не конкретными реализациями. Я считаю, это... Как бы это... То есть по -другому сказать, наверное, было нельзя. Потому что если ты начнешь сейчас говорить «но», то, естественно, никто тебя слушать не будет. Надо всегда говорить категорично, а потом, естественно, начинаем собирать.

Но при этом, вот сейчас я как раз хочу сказать о том, что проблема в том, что люди, которые следуют полностью этой штуке, пытаются смотреть, применять, они приходят в Angular, как ты помнишь, и создают там контейнер, на базе которого все работает. Соответственно, взлетает это идея или нет очень плохо. То есть люди, которые, короче, работают в Angular, например, я как пример покажу, потому что там это явно всего выражено, потому что я мог бы и на Backend, например, Rails .Jungle это рассказать, но с Frontend сейчас будет попроще.

есть, идея в чем? То есть, это делали джависты, они именно это пытались сделать, что типа, смотрите, нас мы не используем какой -то конкретный HTTP, например, объект для реквеста, у нас есть инверсия, мы даем стандартную реализацию, но вот интерфейсы, можете ее подменить и вообще Axios, там, все что угодно, ставить, а в конечном итоге оказалось это достаточно сложным и не так востребовано для фронтэнда, поэтому если ты посмотришь на view, ну, я просто не знаю, сколько ты пишешь на них, потому что в том числе фронтэндер, когда ты там это делаешь,

Я даже зная про это все и понимаю, где мне это нужно, я вижу, во -первых, никому это не нужно, никто это не использует. А знаешь, что самое смешное? Самое смешное, что когда у тебя есть открытые классы, открытые классы — это концепция, повторю, не повторюсь, но скажу для тех, кто не знает, это когда ты можешь класс заманки патчить в любом месте программы. Ну, обычно считают это под открытыми классами. У тебя есть прототипы, ты можешь пофиксить, ты можешь, как в Ruby, просто взять и переопределить любой класс в любом абсолютном месте. Это супер страшная техника.

(22:04.046)
но она позволяет делать такие чудеса, ну, например, у тебя во frontend приложении есть, ты тестируешь frontend, компонент, он делает запрос в опишку, любой Javis, любой человек с теми знаниями, которых мы сейчас тобой говорим, он такой в первую очередь думает, так, нужно инвертировать зависимости, мы можем подложить туда фейковую реализацию, да, и все будет хорошо. Что делает frontend? Опять же, не потому что это плохо, просто там так принято, он такой, ага.

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

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

Есть большие команды, есть большие проекты, которых интерфейс выступает в роли соглашения. есть соглашение, определяет, почему, например, JavaScript и TypeScript сейчас очень часто друг друга начинают заменять. есть TypeScript начинает вытеснять в некоторых задачах JavaScript, и тот же React на него переходит, потому что там появляются типы.

Angular TypeScript и View, думаю, тоже как -то эксплуатирует TypeScript. Почему? Потому что тип, кроме того, что он позволяет тебе делать автоматизированные проверки с помощью статического анализа, то есть он дополнительную информацию несет, он может выступать в роли такого контракта, который тебе подскажет, что у тебя происходит. И вот идея использования dip в том, что там, где это надо, понятно, что если ты будешь для

(24:17.774)
сущностей, которые представлены единичным интерфейсом. У нас есть стол, и он только один в нашей системе, никаких других столов у нас нет. И создавать для него интерфейс это не очень хорошо. И, кстати, у Роберта Мартина это тоже обсуждается, что можно сделать мягкие границы и не создавать лишние интерфейсы. Так вот, но когда у тебя становится очень много людей, то есть мы говорим сейчас не о команде, там из трех человек, а, например, десяти командах и в каждой по три человека, 30 человек.

Им нужно каким -то образом передавать между собой информацию о том, как проект работает, какие в нем соглашения, какие в нем ограничения. И вот monkey patching – это очень плохой способ передать информацию о том, как все работает, потому что единственный способ понять, как у тебя что -то работает, это первое – посмотреть тесты, если они есть, потому что, ну, когда тесты начинают выступать, в роли достаточно неплохой спецификации. Если нет, то посмотреть только полностью весь исходный код.

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

как этим можно пользоваться. Это уже достаточно хорошая подсказка. Поэтому, с одной стороны, в небольших командах, на небольших проектах, небольшая кодовая база для небольшого количества людей, которые и так между собой общаются, это все здорово. Работает. Но когда мы начинаем увеличивать количество людей, когда нам нужно разделять эту работу, нам нужно дополнительно внести издержки на их синхронизацию, чтобы они понимали задачу одинаково, чтобы они носились к ней одинаково. И вот здесь, на мой взгляд, интерфейсы начинают работать.

в полную силу. Не зря в Enterprise любят Java, потому что это очень нудный, но очень помогающий организоваться язык. На JavaScript писать очень сложно. бы на нем можно было писать большие вещи очень просто, вряд ли появился бы TypeScript. Поэтому вот здесь интерфейсы и сам принцип Deep позволяет организовывать и внедрять в команду больше порядка.

(26:39.694)
про manki -патчинг это именно так и есть поскольку там очень много либо небольших проектов, либо тебя все равно даже если они достаточно большие это не такой размер, как про Enterprise когда мы говорим, когда у тебя по -настоящему много и десятилетиями все это пишется но я знаю, что вижу, я вижу, что ты как бы говоришь про интерфейс в целом, но так как будто интерфейс и сами PC подразумевают использование DIP

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

но само по себе это не делает использоваться, то есть у тебя DIP сам по себе от этого не появляется, вот в чем прикол, поэтому то, что ты сейчас по сути рассказывал, ты сейчас по сути рассказывал, что классно, когда у тебя хорошая система типов, в ней есть возможность определять контракты, может быть, обязательно интерфейсами, потому что бывают же даты класса в husky или там всякие разные штуки, и в таком смысле второй, на point, которому я хочу перейти, если все -таки мы говорим про DIP, в чем я вижу его именно засаду?

я вижу его засаду в том, что он немножко толкает к тому, что абстракции всегда лучше конкретики именно не в том плане, что у тебя есть интерфейс, а в том плане, что ты все время... то есть люди, которые ему слепо следуют, они пытаются типа, давайте я напрямую никакой класс вообще не буду использовать только через передачу как параметр. К чему это приводит? Я считаю, что это приводит типа... люди почему -то думают, что гибкость и простота...

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

(28:55.502)
Я думаю, ты сам знаешь, что огромное количество переписок подобного рода можно найти на Reddit, на всяких местах, форумах старых, где об это обсуждалось, когда люди просто говорили, я вообще про их понять не могу, потому что тебя абстракция на абстракции абстракции погоняет.

это вот я вижу обратную сторону как бы не дали. Ну смотри, ты мне только что упрекнул в том, что ты... приравнял интерфейсы к наличию deep и тут же говоришь, что интерфейсы на интерфейсах интерфейсами погоняют, а мы только что определили, что интерфейсы Ну, я имею в через инверсию. Да, да, я имею в инверсию. У тебя интерфейсы, интерфейсы, интерфейсы, у тебя там...

инверсии может быть, поэтому здесь нужно говорить не о бессмысленном применении принципа, а о смысленном применении принципа и как любое осмысленное применение чего -либо это требует понимания самого принципа здесь естественно нужно проходить обучение, естественно нужно общаться с коллегами, здесь нужно сделать ревью почему? потому что оказывается, что соль всего этого в том, что дипа не должно быть много но это не значит, что его не должно быть вообще

Поэтому когда вы находите в своем программном обеспечении вот эти места, например, contach от много команд, где нужно проинвертировать зависимости для того, чтобы их разрезать, и вы применяете dip, вы получаете бонус в виде развязанных рук. Если вы говорите, что мне по телевизору кто -то сказал, что dip — это надо везде использовать интерфейс, везде нужно инвертировать зависимости, чтобы это было все хорошо, и начинает все это бездумно применять, то же самое, что вот закинуть

кашу, пачку соли, сказать, надо посолить, вот получится очень невкусно. Поэтому умение готовить оно как раз и на стороне программиста. Если бы можно было бы принципы применять бездумно, однозначно, меры, то наверное это делал бы ЧАД -ДжиПити, лучше чем человек. А человек как раз должен выработать в себя понимание, где это полезно, где бесполезно. Здесь нужны, конечно, примеры, их нужно разбирать, их нужно понимать.

(30:53.774)
и показывать с одной стороны, где это принесло пользу, с другой – где не принесло. У меня есть даже несколько конкретных кейсов. Наверное, скажем так, если у вас в экосистеме есть контейнер, вокруг которого все построено как в Springer, там, честно говоря, вопрос даже такой, наверное, особо не встает. Действительно, если посмотреть на код, в целом кажется, все делается достаточно разумно. Чаще проблемы есть в тех местах в обратную сторону, когда вообще нет контейнера и, как правило, люди, которые приходят... Ну, давай так.

Без контейнера инвертируют зависимости тоже, конечно же, но честно говоря, намного меньше. То есть это больше все -таки прерогатива людей, которые делают библиотеки и фреймворки. Они там это понимают, там по -другому нельзя. А вот те, которые делают прикладные штуки, вот сколько я видел, я не знаю, как у тебя опыт, если это особенно динамические языки, если это языки там без классов, особенно, там у тебя это ну, ну, прям скажем, мало. И да, начинают monkey patch и всякие такие штуки использовать. Так вот, в таких местах...

контейнер привнести можно, наверное, и нужно и местами. Ну, например, нас вот хехс это написано на Rails. Контейнера по дефолту там нет, но у нас есть довольно много вещей, которые мы хотим подменять, поэтому контейнер мы туда занесли сами. Но он используется только вот для тех вещей, когда мы четко понимаем. Ну, например, в тестах у нас есть места, мы там докером прямо из баши управляем, потому что нас там практика, да, все такое. Соответственно, в тестах нам явно это не надо, и оно там фейковыми штуками подменяется. Ну, это как пример. Но когда речь идет, например, про модели или там про базу данных, то...

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

И раньше, просто я помню, я этим учился, и там в пределе как все делали, типа ты берешь любую библиотечку, и ты не завязываешься на ее интерфейс, ты делаешь свой, и фактически дальше подмена происходит за счет адаптеров. Вот по моему опыту вот эта идея провалилась почти на 100%, потому что только в небольшом количестве языков пытаются унифицировать. Если вы берете, опять же, front -end, у вас там какая -нибудь конкретная либо с компонентами для, не знаю, горячих клавиш в реакте, они никогда в жизни все не будут...

(33:09.806)
обладать одним интерфейсом. Вы если ее меняете, вам придется переписать код в тех местах, вы это используете. Просто как правило, это не так широко распространено, ли. Если вы определяете горячие клавиши, они у вас не будут в каждом компоненте по 100 раз повторяться. Поэтому вот это абстрагирование любой библиотечки в свой интерфейс чаще всего, наверное, перебор, по моему опыту. Слушай, Кирилл, если честно, меня ощущение, что мы говорим сейчас не про DIP, а про DIA и про инверсию.

управление, не про инверсию зависимости. есть вот и op -container, это про di и все, это dependency injection. Ну, фактически он просто за тебя решает вопрос... Давай так, это просто способ сделать, автоматизировать подстановку этих зависимости, потому что в реальном коде, вот если мы берем с тобой, давай, типовой код, который у тебя есть. У нас есть инверсия зависимости и инверсия управления.

инверсия управления заключается в том, что когда мы берем какой -то класс, ну я извини, я буду в объектооритированный парадигмем, я ней больше всего работал, и в этом классе есть метод, мы можем в этот метод передать, условно говоря, callback, который будет выполняться, и таким образом, что этот callback будет делать, решаться вовне. Это инверсия управления, то есть мы отдаем, в библиотеках часто используется, передайте нам свой callback, и мы как бы...

соответствующий с ним, внедрим его в наш поток управления. И инверсия управления очень часто делается через iok -контейнер. Извиняюсь, может я неправильно произнёс с аббревиатуру. Это инверсия управления, когда извне можно решить, что делать внутри. А инверсия зависимости, это когда мы говорим, что мы зависим не от того, что у нас внутри, а от некого интерфейса. И все, кто реализует интерфейс,

они, соответственно, могут нам отдавать свои объекты то, что мы будем зависеть не от конкретного реализации объекта, который нам передадут, а от интерфейса а что уже передадут, будут решать люди, которые передадут ну, это, насколько я понимаю эти принципы ну, по сути, давай так это не параллельные вселенные смысл в том, что у тебя вот этот сам факт передачи

(35:30.702)
это и есть то, что, например, делают айоки. есть они, собственно, это передают. у тебя есть, скажем, два уровня. У тебя есть уровень конфигурации приложения, и тебя есть уровень прикладного кода. На прикладном коде это делать не айок, это делаешь ты. Но суть операции та же самая. То есть ты, например, создаешь объект сервиса, которому в конструктор нужно передать базу данных.

Но откуда, во -первых, ты базу данных возьмешь? Ну, например, в Java, вот у тебя есть сервис, ты его инстанцируешь для того, чтобы вызвать какой -то метод, и тебе на вход он принимает логгер или еще что -то. Ну, у тебя два варианта. Либо IOK тебе сам все это закрутит, в некоторых местах ты это просто делаешь сам. Грубо говоря, завязка на интерфейс, она же происходит не по причине того... То есть завязка на интерфейс, она ведь в первую очередь не в том, что ты от него экстендишься, потому что у тебя есть дактайпинг. Мы же можем сказать, что у тебя есть языки типа Python или Ruby.

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

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

Прямая зависимость – это когда мы используем конкретный тип подключения, с условным говоря, объект MySQL connection и там есть метод connect и мы можем только к MySQL подключиться. Это зависимость на реализацию, то есть мы завязались на конкретную MySQL. А интерфейс – это когда мы говорим, что у нас есть интерфейс подключения база данных, котором есть метод connect и в нем есть пароль host

(37:48.846)
имя пользователя, имя база данных и дальше мы можем отдельно реализовать класс, который будет для MySQL делать коннект отдельно класс для Postgres и интерфейс, который у нас есть никак не определяет то есть мы можем сделать сегодня для MySQL, а потом через год сделать для Postgres и передать его и наша программа никак не будет зависеть от конкретной реализации и инверсия зависимости это как раз инверсия

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

это уже определяется не мы, мы от этого не зависим. Вот в моем понимании именно это дает dip и вот именно это дает инверсия зависимости. То есть мы не знаем, но знаем, что это будет соответствовать нашему интерфейсу, и этот интерфейс является нашим контрактом для входных данных. А IOG это уже... ну можно посмотреть на это, что да, у IOG контейнера тоже есть интерфейс, и он определенным образом его можно использовать. Но это все -таки про управление, про то, что...

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

Да -да -да. И просто, видишь, это связано еще, как бы, я вот уверен, это культурная такая штука, потому что люди, которые в Java, мне просто повезло, что я как бы в этих мирах, в обоих, скажем, присутствую в большом количестве миров, и очень классно видно именно восприятие именно этого мира. То есть ты понимаешь, что это специфик исключительно языка и его экосистемы. У тебя в той же Java то, что ты рассказываешь, это норма, да, у тебя ты берешь там какую -то штуку, и у тебя почти всегда есть абстракция, абстракция, абстракция. Ты приходишь в React, ты приходишь в Nod.

(40:11.438)
у тебя просто нету, ну просто этого не существует, неважно есть у тебя TypeScript или нет но до TypeScript поддерживаюсь сейчас уже из коробки с последних каких -то там версий я объясню, что я имею в виду, ты приходи, давай я согласен, я просто ремарку маленькую сделаю да -да -да, я согласен да -да -да, мы берем PGConnector у него есть интерфейс классно -классно, тебе потом подается делать MySQL, что ты будешь делать, да ты просто выкинешь его нахер

и поставишь в MySQL. Почему? Да потому что не существует общего абстрактного уровня и никто его писать не будет. Я тебе честно скажу, я недавно писал курс как раз по... Ну, такой микрокурс по использованию SQL из ноды. Ты знаешь, я потратил несколько дней, пытаясь понять, какой из коннекторов по pg мне выбрать. Их пять штук. И они не то что там интерфейсы разные, они используют разные вообще подходы к тому, как в принципе делать запросы. То есть кардинально разные. Это просто как будто... То есть ты такой вообще...

не очень понимаешь, например, там есть такое понятие, templateLiterals, когда у тебя даже не метод вызывается, а templateString, если ты знаешь такие штуки, они выглядят просто как строка с подстановками, это даже вообще другой уровень, и ты понимаешь, что мне абстракцию вокруг этого делать? Ну, конечно нет, потому что... Если бы я верил в ORM, я бы сказал, тебе нужна ORM, и твои проблемы будут решены. Это шутка, про ORM это отдельный разговор.

Но, кстати, УРМки именно это делают. Поэтому я в начале и сказал, что именно в том идеальном варианте, который мы с тобой описали, мы же не говорим, что его надо везде использовать, это удел людей, делающих библиотеки и фреймворки. Поэтому я могу так сказать, что если я общаюсь с человеком, который занимается разработкой своего УРМ, я ожидаю от него, что он эксперт в этой штуке, он ее понимает максимально круто, и ему без этого просто нельзя. Я тогда не понимаю, как он будет работать.

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

(42:34.158)
Это в фреймворках, например, в Unity мне очень понравилась, там очень хорошая система наследования, и там эта идея хорошо работает. Там, в -первых, еще добавлена очень хорошая рефлексия того, что есть, то есть можно о классе получить кучу информации в интерфейсе самой Unity, но я бы сказал, что именно хорошо выстроенная система наследования.

все есть объекты и все пошло уже делиться на behavior, еще что -то. Я по Unity плохо помню, я когда просто смотрел, мне понравилась именно иерархия наследования, что она очень логичная и там действительно инверсия зависимости очень хорошо работает. Там действительно можно выделить интерфейсы и взять вот... но это я уже перехожу к барбаррелизкам, ладно, не будем сейчас барбаррелизкам все допишать, но именно хорошо выстроенное иерархия наследования облегчает использование DIP.

Если нет наследования, то это можно тоже минусовать очень много проектов, где это не надо делать. Слушай, мне кажется, хорошо разобрали. Ребят, напишите, что вы об этом думаете, не слишком ли мы закопались в детали, потому что у нас в контексте в голове картинка есть. Возможно, со стороны вы не успевали следить за последовательностью этих вещей. Вообще, хочу сразу сказать, что если этот выпуск зайдет и...

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

Да, по -русски как? Interface segregation? Ну, я бы сказал разделение интерфейсов, но обычно, если честно, самый бесполезный принцип, я его стороной обычно. Я поэтому хотел про него сказать, потому что он супер короткий. Ладно, давай про него скажем. Он понятный. Ну, в моем понимании разделение interface segregation...

(44:41.134)
принцип, то есть разделение интерфейсов говорит нам о том, если вы что -то не используете, то это должно быть в другом интерфейсе, если по -простому. есть ваш интерфейс должен быть максимально близок и покрывать ваши потребности, и если у вас есть какой -то супер универсальный класс, который используется много где, но по чуть -чуть.

то его нужно через интерфейс разделить на кусочки. В общем, если честно, принцип, на мой взгляд, как раз к уровню кода и языка программирования, потому что даже у Роберта Мартина сказано, что это про то, как собирать бандлы, как разделять и пересобирать куски кода. общем, идея в том, что вас интерфейс должен быть максимально близок к тому, что вы используете, не включать ничего лишнего. Она, мне кажется, излишняя, особенно в...

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

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

а у него интерфейс какой -нибудь не знаю, user collection, гипотетически. В таком случае, наверное, опять же, это такая мелочь, но она может примениться, что человек, который знает, скажет, ну есть же отдельный countable, логично его применить, потому что тогда мы сможем, например, функцию count вызывать и так далее. Но, наверное, главный вывод здесь такой, это очень локальный принцип, очень маленький, очень про кусочки кода, которые, честно говоря, вряд ли вообще повлияют сильно на вашу архитектуру программы.

(46:54.798)
я что улыбаюсь, хотел сказать, знаешь, Люк, должен был бороться со злому, примкну к нему сейчас мы поменяли сместа, по идее это ты должен был сказать, что принцип никому нафиг не нужен, это ерунда забейте на него, а я сказать, ну почему, мы можем же там выделить какие -то, ну ты, я так понимаю, ты видел множественное наследование интерфейсов, когда мы можем построить из кусочков интерфейсов какой -то более сложный интерфейс

Да -да -да, и как правило, просто по моему опыту эта штука... Понимаешь, просто ты уже сказал, я же тоже самое хотел сказать. Вот реально ты прочитал мои мысли, ну, блин, в SOLID такие собраны вещи, которые... Вот DIP — это серьезная вещь на самом деле, важная, там со всех сторон можно обсуждать. И вот эта вот штука — это такая мелочь по сравнению со всем остальным, как бы даже непонятно, что она здесь делает. даже широко не может быть применена, если... есть сильно зависит от языка, на котором ты пишешь, композиция...

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

Да, такое бывает. Я, кстати, давно такого кода не видел, но когда ты в один класс просто, знаешь, так постепенно понемножку начинают спихивать, спихивать, спихивать, и в итоге это просто тупо свалка. Ну вот, наверное, грубо вот к этому насвоится. Давай поговорим про барбур лисков. Давай. Как ты считаешь, да, то есть изначально...

нет, я по -другому скажу, мне очень понравилась, знаешь какая штука, очень понравилась штука, Саша Биндио один раз это у себя описал, если ты его знаешь или не знаешь, я просто очень давно, когда... знаю... Человек из .NET, он просто одно время был достаточно широко известен, да и сейчас в принципе, просто ближе к .NET, он много писал, на эти темы... помню, я что .NET мало занимался, может поэтому... Да -да -да -да, я просто не занимался .NET -ом...

(49:01.934)
Ну он был как бы из людей, которыми я смотрел, потом уже познакомились, всё такое, но он очень классно сформулировал у себя в блоге в 2008 году, если я не ошибаюсь. Он сформулировал у себя такую мысль про Барбу Релизко, которая мне очень помогла, что если ты читаешь определение и разговариваешь даже с людьми, которые солид знают, ну как правило, они, честно говоря, не могут вообще пояснить. И они очень часто сразу про классы говорят. говоришь, оригинально это вообще -то не про классы. И дальше он сформулировал так, что

нельзя сужать предусловия и нельзя расширять постусловия. Я слышал, это нельзя усилять предусловия. да. таком варианте слышал. Извини, это я просто перепутал. Это абсолютно верно. Это прямо абсолютно верно. Это можно тоже красиво нарисовать на множествах. То есть, по сути, да, это вот про что Барбара Лискова и говорила.

Ну, то есть можно еще здесь, конечно, очень много говорить про ковариантность и контравариантность уже есть определенные проблемы, потому что, ну, Барбара Лисков это глобально про глобальную ковариантность, не контр, а ковариантность Вот, а контравариантность, уже в вот, этой парадигме, она ее, ну, не ляжет, там можно всякие делать в рапперы, да, которые внутри что -то содержат, и мы можем содержимым делать какие -то, ну, предполагать что -то внутри, ну, в общем, отдельная тема, не буду сейчас

Но вот именно это не усиляйте предусловия, не ослабляйте постусловия, она абсолютно... А с этим я абсолютно согласен. И даже вот ты правильно сказал, я в твоем докладе ты ссылался на Роберта Мартина, он в книжке этого себя пишет, что это про классы, да, это про наследование. И вот потом он, я так понимаю, тоже признал, что это на самом деле идея гораздо -гораздо шире. Вот. И в этом смысле очень сложный принцип. Я, если честно, думаю...

Этот принцип, на мой взгляд, из серии корректности программного обеспечения. есть этот принцип не про то, как написать работающую программу. Это принцип про то, чтобы мы обеспечили непрерывно заданные функции. Что бы мы не подали в рамках заданных условий класс, sub, подclass, tip, podtip. Наша программа его бы обработала и выдала корректный результат. Потому что предусловия очень сильно к этому подталкивают. Их можно делать как явно, так не явно.

(51:26.03)
но это очень супер сложная тема я в шоке от того, насколько у нас тобой по этому принципу одно и то же вообще восприятие может быть чуть разными словами, но я ни с кем, по -моему, никогда не разговаривал, так не сходился я даже скажу другими словами то, что сейчас сказал я абсолютно согласен, что это история именно про фактический систему типов и про ее как бы слабость то есть системы типа в языках программирования в основном недостаточно мощные

для того, чтобы выразить ограничения, которые бы нельзя было нарушить. есть это как, знаешь, правило monad. То есть у тебя есть определенный правило, который помимо системы типов ты должен соблюдать для того, чтобы тебя была программа корректная и не падала с ошибками там, не надо. И вообще по идее эта проблема и задача, которую мы тобой обсуждаем, решается такой штукой, как зависимые типы во всяких сумасшедших языках типа... Agda, Да, да, да. Вот. Но это слишком сложно, мы на этом не пишем, но действительно для тех, кто нас слушает, то есть грубо говоря...

интерфейс, проблема интерфейсов во всех языках, то есть как бы и счастье, и проблема, ими достаточно просто пользоваться, но проблема в том, что они не могут гарантировать диапазоны, например, то есть когда вы говорите, что вы не просто числа на вход принимаете, а числа определенного диапазона, это более сложный тип, который в теории можно было бы выразить, но если бы система типов его выражала, получился бы язык, которым просто невозможно работать, это слишком сложно, вот, и поэтому

Фактически это ограничение оставлено на уровень программиста. есть в идеальном мире, короче, он об этом думать не должен, по принципу Барбар и Лисков. В идеальном мире у него должен компилятор сказать, что не получится. Но мир не идеальный, особенно там, где, кстати, exception тоже никак не проверяются, те же самые, которые могут возникать, то получается, что вы должны об этом думать. Почему? Потому что вы просто получите ошибку в runtime. Теперь, наверное, такой вопрос, влияет ли принцип Барбары и Лисков хоть как -то на архитектуру?

Честно говоря, вообще никак. Этот принцип, с моей точки зрения, он вообще ничего не меняет в вашем коде, кроме того, что вы чуть более аккуратно строите иерархии типов или классов. Ну, под типом мы интерфейсы понимаем. Я бы сказал, что он сильно влияет на те ограничения, которые вы разрабатываете. В любом случае, система типов, которая разрабатывается, это как раз к системе типов больше относится, чем непосредственно к написанию кода.

(53:43.63)
потому что, как ты правильно сказал, язык программирования не сможет проверить тебя, нарушаешь ты собственное соглашение или нет, то есть большая часть языка, там лямбда, куб можем вспомнить, вот именно там есть зависимые типы, вот там да, мы сможем, но это уже там и доказательства теоремы и целая история для взрыва мозгов, вот. А язык не может проконтролировать, поэтому систему типов ты должен разработать, контролируя себя сам.

то есть ты понимаешь семантику, ты должен себя сам проконтролировать и в этом смысле это часть архитектуры потому что это не кодируешь ты это сначала, ну или даже можешь параллельно делать когда ты продумываешь систему типов даже если ты сразу пишешь код, ты все равно думаешь, а этот тип, это меня под тип, значит если я сюда передам, значит они должны разноусловно говоря себя вести и мне еще хотелось добавить, когда я там у husk в husk или категории типов husk

когда я начал про типы, категории читать и когда я прочитал определение, что тип это можно представить его как множество всех значений, которые можно представить этим типом то есть, допустим, множество integer это множество всех натуральных чисел от 0 до 65535 и когда я начал воспринимать типы как множество возможных значений, всех возможных значений, которые могут они принять

и когда ты смотришь на категорию типов, там отражаться может сам себя, либо другой тип, всякие функторы нас возникают, вот это всё сложное и возникает довольно объемная теория, в общем, мне идея представлять типы в виде множества очень понравилась условно говоря, я беру множество всех натуральных значений и я могу

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

(56:02.35)
это значит, что множество может быть расширено возможных значений, но не может быть сужено, то есть если ты сказал, что ты можешь принимать значения в оригинальном классе, ты можешь принимать значения от 0 до 10, то в подклассе ты можешь принимать значения от 0 до 10 и больше, например, до 12 и в подклассе они могут обрабатываться, но там, где ожидается суперкласс, тебе никогда не передадут больше десятки и раз ты можешь до десятки всё

а можешь и 11 и 12, то соответственно ты можешь его свободно поставить. Расширение предусловия – это возможность расширить класс в подтипах, в смысле, класса множества. А сужение – это наоборот, когда ты сужаешь это множество. В общем, когда я это себе рисую, прямо очень намного понятнее становится, в чем смысл.

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

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

такие вещи, например, принцип... Ну, то есть немало вещей внутри него, на самом деле, гораздо более специфичные, чем принято считать. Вот что я имею в Вот принцип Barbara Liskow понятный, нужный и так далее. Но, честно говоря, это не то, что делает нашу программу, нашу архитектуру тем, чем она является. И здесь я хотел сказать примеры нарушения. Знаешь какая самая классика? Самая классика — это типа, переопределяем метод и бросаем исключения. У тебя тут сразу нарушение как бы интерфейса.

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

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

Честно скажу, -таки реальный код, промышленный код, бывает разный, совершенно существуют разные ситуации, и я видел примеры немало, где многие принципы, с которых мы разобрали, не выполнялись, и это было очень разумное решение в данном случае, вплоть до нарушения принципа Барбар Лисков. Это тоже связано с legacy, это связано с там... Ну, короче, есть причины, которых такое бывает. Классическая причина, почему нарушаются принципы, это time -to -market. То есть нарушение принципов порой очень сильно ускоряет...

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

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

(01:00:36.11)
использовать принципы, он хочет сделать правильно, но это требует осмысления, обдумывания, проектирования, опыта применения, это выливается в x2 срок. Бизнес, понимает риски, он понимает, что если он выкатит эту фичу, он получит уже сейчас долю рынка, займет ее и так далее.

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

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

надо было с одной стороны быстро, а с другой стороны у человека нет конкретного понимания, знания, применения. Потому что, как правило, то, что ты говоришь, все -таки речь идет скорее про какие -то комплексные вещи. То когда тебя речь не про применение принципа, а когда у тебя есть некая цепочка событий, используя какие -то системы, тебе надо вот прям здесь что -то сделать. Например, у тебя не было кэша, и ты понял, что прямо сейчас тебе нужно внедрить кэширование. А для этого тебе нужно Redis, а там это надо согласовать.

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

(01:02:53.71)
человек начинает, например, 50 флагов вводить, потом ты этот код просто не понять, не разобрать не можешь, и ты понимаешь, что он просто, если бы он делал правильно, он бы сделал это быстрее. Флаговое программирование это вообще сразу не очень хороший признак. Это как раз показывает то, о чем я говорю, что человек выбрал неправильный Да, я согласен, есть квалификация, есть осознанное принятие решения. Осознанное принятие.

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

все делают плохо, что хотят сделать плохо, и не всегда делают хорошо, потому что хотят. Нет, наверное, хорошо делают всегда, потому что хотят. Ну, общем, смысл в том, что жизнь бывает очень разная, и вот принятие решений в сложных условиях – это тоже искусство. Да, для меня… Знаешь, что для меня идеальная ситуация? Я вообще абсолютно… То есть для меня идеальный код – это код, который соответствует… Понимаешь, тоже прикол, да? Многие как считают, что есть некие абсолютные понятия идеального кода, вот типа идеальный, правильный, а значит много времени и так далее.

Не знаю, может быть, бизнес меня так поменял. Для меня как раз идеальный код. Знаешь, как идеальное инженерное решение. Это решение, принято, есть максимум, который мог выжать из ресурсов, которые у тебя были. Вот что такое для меня идеальное решение. Поэтому если я вижу говнокод и я понимаю, что это было лучшее, что можно было написать на тот момент, и самое главное, разработчик, который это писал, он понимает альтернативы, понимает, почему так было написано.

для меня это вот просто это эталон топ и так и должно быть вот что такое для меня отдельное решение да ну это типа как операция в полевых условиях тоже вариант когда других вариантов нет ну то есть здесь я тобой абсолютно согласен но вот как раз мой это поинт я так более радикально настроен я считаю что лишь предъявляя более жесткие требования к квалификации человека есть шанс что он эту квалификацию приобретет если всегда исходить из того что вот у него

(01:05:07.406)
какие -то жизненные условия, обстоятельства ему мешают сделать что -то подумать и опять же это к разговору о соли да то есть соли это в том числе те самые принципы решения которые неплохо бы освоить прежде чем отвергать потому что ведь многие могут воспринять идею том что соли то имеет недостатки да как то что можно вы и не проверять и не разбираться с ним и не смотреть вот если барбара листков очень какой -то сложный принцип зачем вообще с ним разбираться все у меня на практике то есть

Здесь есть некая такой посыл, что если это сложно и это никому не нужно, зачем я этим буду заниматься? В моем понимании, что наоборот, ты должен сначала залезть на гору, а потом уже решить, бы надо тебе сюда было или не надо. То есть ты должен уметь и автоматизировать именно в своей практике сложные решения применять или несложно элегантные, знать несколько вариантов. И тогда как бы квалификация тебе позволяет находить более простые элегантные решения.

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

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

И при этом, как правило, наверное, такое восприятие, что это говорят те, кто их не знают. Честно говоря, на практике я вижу другое. Я вижу часто, что отрицальщики каких -то штук являются люди, которые в этом разбираются, и которые дошли... Ну, я имею в именно те, кто аргументирует, да? Это именно те люди, которые разбираются. И ты каждый раз об этом думаешь, что... Ну, а как бы иначе ты это понял? И, наверное, это действительно влияет на тебя, как бы на принятие решений, которые ты делаешь. То есть все -таки...

(01:07:24.942)
в моей практике, если просто слушаться всех тех, кто дошел до уровня, там, все это не надо, оно, как правило, приводит к тому, что человек действительно остается там где -то внизу, и он каких -то вещей просто никогда не увидит, пока сбоку кто его там не тыкнет в это, поэтому подходы серии, что все -таки есть вещи, которых для того, чтобы их отрицать, нужно сначала с ними разобраться, а потом отрицай. Ну, не в идеальном, не до самого топа, конечно, но хоть насколько -то разобраться. Как примеры паттерны. Паттерны то же самое.

солид и паттерны это я считаю относится к этим вещам ну хотя бы немножко надо понимать о чем я речь но это видишь у тебя все равно есть ты пешем есть люди у которых в результате освоения новых знаний вырабатывается эндорфин ну то есть я не знаю как у тебя я когда вот что -то я люблю вот у меня кубик рубика лежит у меня там вот шахматы сверху лежат я когда я причем не как бы не за то чтобы там быть профессиональным игросмесьем

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

у людей по -разному, кто -то от музыки тащится, кто -то от спорта тащится. Говорят же, что люди, которые регулярно занимаются спортом, у них начинает вырабатываться к этому тяга и тело уже потом требует. Тут меня тоже самое происходит с изучением новым. Для меня это вполне себе ощутимый кайф от того, что ты что -то новое узнал. И я знаю, что таких людей много, я знаю, что они такие люди будут. Поэтому, скорее всего, того, что я слышу у тебя, мне...

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

(01:09:33.518)
через такие разговоры я надеюсь больше достучаться до тех, кому это интересно, чем для тех, кому не интересно, потому что многие люди, которые послушают, что вот это не надо, то не надо, алгоритмы не нужны, они могут потратить время на то, что... поверят в это и потратят время не на то, что им надо, самом деле, а как бы... для них очень важно не потерять это время, потому что я в время, когда начинал изучать программирование, меня была проблема, что не было информации, очень мало информации.

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

и не хочу говорить, что Solid нужно всем всем применять. Мы уже сошлись по определенным позициям, там, Барбар Лисков, по сегрегации интерфейсов, и уже становится понятно, что есть определенное разумное восприятие этих принципов, которые вполне себе неплохо освоить. И дальше это не приведет к краху вашей жизни, если вы их не будете применять, а может привести к довольно приятным последствиям в виде того, что вы осознаете что -то новое для себя, поймете, что это ваше, и будете это использовать.

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

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

(01:11:51.502)
Бывают люди, которые при таком прыжке остаются слишком далеко в какой -то части, любой. Мы говорим не только о п функционале, да, в любой. И они застревают, это, плохо. Но то, что вы все проходите через эти этапы, это абсолютно нормально, это да. Главное просто вовремя оттуда выскочить. Что если вы увлеклись солидом, я такой, лакну свою бумажку, что через пять лет у вас должно, ну вы уже должны на это смотреть так, что типа да, было время, сейчас я уже спокойно это смотрю.

Это говорит о том, что, возможно, вы застряли в какой -то парадигме, которая не является такой. Давай поговорим про принцип Open -Closed -Принцип. Сразу честно скажу, этот принцип самый из всех является, практически, с Single Responsibility еще понятнее для людей, но он является одним из самых покрытых мраком с точки зрения того, что любые его объяснения являются довольно абстрактными. И опять же, я специально сегодня именно по нему пошел смотреть Reddit.

Ну как ты думаешь, срач на сраче. То есть один говорит одно, второй говорит, ты его понимаешь неправильно, третий еще. А это, между прочим, англоязычные ребята, которые все -таки читают первоисточники, и они как -то ближе к этому. И да, есть какая -то картинка, но все равно она такая, очень... Для меня всегда была, кстати, вот неясная. Ну, например, знаешь, я сразу скажу, это OpenClosed. Если вот буквально его понимать, я бы сказал, но это система плагинов, в какой -нибудь фреймворке.

но честно говоря, не это имеется в виду. Так то уж. Ну, если честно, я с системы плагинов все -таки я бы сказал, что имеют к открытости и закрытости отношения. Вообще, насколько я помню, этот принцип сформулировал Меер. У него есть замечательная книга по объектно -ориентированному программированию. Очень старый этот принцип, он не помню, 70 -80 год, как раз один из самых первых.

И я, кстати, давно его не проверял, интересно, что ты сказал, что сейчас есть какое -то пересмысление этого принципа. Если взять Мейера, то так же, как и Мартин, он его связывал с объектно -ориентированным подходом и говорил о том, опять же, это минимизация количества изменений, которые нужно сделать для внедрения или изменения поведения программы.

(01:14:13.262)
То есть идеально, когда мы внедряем новую фичу, не трогаем старый код, а пишем что -то новое, и это работает. И в этом смысле, на мой взгляд, плагинная система соответствует такому подходу, потому что мы действительно создавая новый код, не меняя старый, получаем новую функциональность и можем соответственно развиваться. В чистой архитектуре приводится идея того, что у нас есть компоненты.

эти компоненты соответственно могут друг друга зависеть, знать друг от друга и там речь идет о том, если мы формируем наш компонент таким образом, опять же, там все идет через интерфейсы, то есть у Роберта Мартина очень большое значение придается интерфейсу как абстракции, которая развязывает тебе руки. И там речь идет о том, что мы можем выставить из компонента интерфейс

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

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

потому что по факту все что ты сказал ты абсолютно то же самое говорил когда мы говорили про завязку на интерфейсы они коррелируют, да они просто коррелируют о Роберта Мартина в книжке именно через интерфейсы зависимости это все объясняется то есть и в DIP и в вOMPKLOK в принципе очень похожие картинки потому что

(01:16:32.494)
он фокусирован был по крайней мере в чистой архитектуре в том периоде, который у меня есть, был фокусирован именно на на изоляции и уменьшение влияния за счет интерфейсов и соответственно расширения функциональности перед изменением старых классов я скажу

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

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

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

дописать в каждом методе, если у нас, особенно в динамических языках, если у нас будет вот так, то ты должен метод по -другому функционировать, и это уже будет размывать сфокусированность метода на решение какой -то конкретной задачи. То есть есть плохие паттерны, которых люди начинают... как бы писать новый класс это долго? Его нужно написать, его нужно... Возможно, там будет проблема с осмыслением этого класса.

(01:18:44.206)
а взять уже готовый метод и добавить туда в конце один if и флажок в начале и в конструктор добавить еще один флажок, который будет активировать какую -то часть поведения нашей программы, это очень просто. И в этом смысле это будет прямое нарушение OpenClose принципа, потому что мы изменили старый код, мы изменили поведение уже существующих функций, добавили новый флажок, который это поведение активирует. Это будет...

среди новичков очень частая идея не писать что -то новое, а добавить флажок, который просто активирует новое поведение уже в существующем коде конкретно данный пример, о, это, наверное, единственное место, дебатный формат получается честно скажу, данный пример не сработает по одной простой причине фактически ты говоришь про использование паттерна state и то, что мы делаем несколько имплементаций под разные стейты и дальше, соответственно, там

меняем в зависимости от языка этот стейт. И у тебя получается более простая цикломатическая сложность, и к каждому классе свои методы делают только то, что надо. А там общее, кстати, поведение можно вынести. Во -первых, действительно, далеко не всегда нужно, потому что это довольно тяжеловесный паттерн, и он требует, когда у тебя, знаешь, момент, ты понимаешь, что блин, стейты начинают уже мне создавать проблемы. Это очень частная история с отчетами, например. У нас есть несколько вариантов отчетов, которые нужно...

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

просто я считаю, так не работает. Типа, если ты его прочитал, и ты из этого сделаешь вывод. Вот для меня, что здесь работает, честно говоря, я, знаешь, как обычно, когда мы говорим про паттерны, я вот учу, рассказываю людям вот все эти вещи, я рассказываю, что смотрите, ребята, большинство паттернов на самом деле, это вам рассказывают просто конкретные кейсы, как subtyping применять. Polymorphism по типу, то что адаптеры, стратегии, proxies и так далее, медиа... ой, эти... ну, знаешь, да, все они. Там типа...

(01:20:55.406)
просто подавляющее большинство это по факту полиморфное поведение, что ты оборачиваешь что -то, ты подменяешь что -то и так далее. И в данном случае вот это гораздо более, если объяснить человеку, гораздо более понятно, когда он этот вывод сможет сделать, что у тебя -то похоже на стратегию, что -то по смыслу, не по имплементации, а по смыслу. Ну я понимаю, да. Просто, короче, смысл в том, что в данном случае, несмотря на то, что... То есть мне кажется, что ты немножко натягиваешь сову на глобус, то есть типа можно так сказать...

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

в таком случае тебе все надо разносить, а значит ты поменяешь старый класс и большинство объяснений, которые были на Reddit, они реально странные типа из серии ну вот тебя был новый класс, есть новое поведение, которое надо куда -то добавить понимаешь, не типа новый формат отчета, а именно новое поведение в смысле внутри и ты такой думаешь, так ребят, ну а если бы я начал как бы делать бизнес вот код писать именно с этой точки в этой точке у меня бы даже мысль этого класса была бы другая то есть естественно я пошел бы его править

Короче, идея не менять класс, когда, например, ты понимаешь, очевидно надо менять, мне кажется странной. То есть я вижу этот принцип максимально неформальным и скорее открытым к дебатам, чем руководство к действию и понимание, что надо делать в такой ситуации. Смотри, здесь я возразил бы следующим образом. У нас есть назначение кода несколько разное. Что я имею в виду? У нас есть код, который предназначен для повторного использования этой библиотеки.

у нас есть код, чистый ядро бизнес -логики, который вообще для повторного использования никак не пригоден, у нас есть инфраструктурный код, который в общем -то реализован на уровне фреймворка, ну это по сути компоновка библиотек с некой конфигурацией. И вот когда мы говорим о принципе открытости -закрытости на уровне бизнес -логики, которая часто меняется,

(01:23:13.134)
и которая очень часто меняется настолько, что нам приходится переделывать очень много всего, естественно, ты его никогда здесь не выдержишь, потому что нельзя защититься от того, что тебе изменили существенным образом условия. Ты не можешь настолько продумать свою архитектуру так, раз, и тебе любое вот, я сегодня хочу шапки, чтобы твоя функция считала, а завтра, чтобы она их вязала, да, то есть ты этого не защитишься. Вот, поэтому когда мы говорим о...

принципе открытости и закрытости мы первое что должны понимать это все -таки архитектурный принцип и архитектурный принцип он означает то что мои примеры на самом деле вот про условия там if 'ы, какие -то там прямо уровни классов они несколько натянуты потому что архитектурный принцип говорит нам о том что мы должны провести границы и выделить интерфейсы то что другие не могу не сказать вот и тем самым мы

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

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

мог расширяться без сильного изменения, потому что мы можем потянуть такие зависимости, которые нарушат обратную совместимость, а нам этого делать не хочется. Поэтому там, где мы говорим о переиспользуемом коде, библиотеке, фреймворке, что -то еще, мы должны больше сосредоточиться на том, чтобы код расширялся, но не изменялся. Кстати, вот и OQ -контейнеры, и вообще DI это тоже про расширение функциональности без изменения старого кода. Это тоже по сути OpenClose принцип реализуется.

(01:25:27.694)
И естественно, что в каких -то частях, часто мы переиспользуем и распространяем код, продумать это имеет смысл и понять, как этот принцип реализуется, потому что принцип не предлагает решения, на самом деле определяет, грубо говоря, каких идей придерживаться, но не определяет, как конкретно это сделать, мы можем реализацию придумать свою. Поэтому для повторно используемого распространяемого кода

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

долго играть, есть стратегически будет ли нам выгода от того, что мы сможем носить какие -то изменения и стабилизировать эти изменения, не переписывать по кодовой базе каждый раз? Я тогда специфицирую. Давай, наверное, это не все, что ты бы хотел заложить, но та часть, которую я на 100 % согласен и где вот этот принцип достаточно четкий. Если мы пишем какую -то абстракцию, которая является переиспользуемой, и это, как правило, является отдельной

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

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

(01:27:42.286)
то есть например это системы хуков, потом если это UI -киты то есть это возможность например навешивать конкретное действие, то есть ты создаешь не штуку которая делает там по кнопке выход делает выход, а штука которая по кнопке выход принимает команду, а команду ты можешь там любую уже повесить, да, если соответственно, маркерная модель события и все такое, вот да и получается что таким но тут засада вот в чем, то есть концептуально это правильно об этом думать надо понимать, но развитие продуктов всегда идет по принципу что сначала ты прибиваешь все

прибиваешь все, потому что, честно говоря, этот принцип бесплатно не дается. То есть это уже конкретное усложнение архитектуры. И более того, ты заранее не знаешь, поэтому мы точно можем сказать, что все продукты абсолютно развиваются... Если вы, конечно, это не десятый продукт уже у вас в вашей жизни, вы просто заранее знаете все проблемы и делаете все правильно, Оно гарантированно будет развиваться по принципу «все прибито гвоздями», а потом вы как нормальный... если вы как продукт выступаете в своем продукте, а не просто как разработчик...

вы понимаете, что к вам приходят люди, они делают свои запросы, вы понимаете, все хотят менять знаешь, меня какой был классный пример? я когда работал с видеостримингом, там был такой на джаве написанный стриминговый сервер, я забыл его название и там был прикол, что у него была конфигурация XML -ная, да, и там я помню, что мне когда надо было менять всякие форматы, типа куда это все стримить и так далее я просто сидел, как бы у меня список классов, имплементации, я просто эту XML -ку менял и у меня как бы полностью менялось поведение моего

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

то тогда да, там это вот прямо, но самое то, мне это тогда очень понравилось, я тогда помню, так наконфигурировал, думаю, блин, вот инверсия зависимости прям сработала, понятно, что там внутри IOK, внутри там скорее всего все это используется, да, но это более, видишь, это более узкая штука, обычно это шире к своему коду применяют, а ты сам сказал бизнес -логика там бесполезно, честно говоря, это Ну, бизнес -логика это совсем другая история, вот как бы, на мой взгляд... Ну, это не очевидно, видишь? Да. Название не очевидно.

(01:30:04.59)
Так это название не... Хотя опять же, если взять чистая архитектура, на самом деле чистая архитектура это вроде как про то, писать бизнес -логику. Потому что если мы возьмем саму концепцию архитектуры чистой, там у нас есть сущности, есть user story, это ядро этой архитектуры. Причем я вот с Мартином никогда не могу понять, он считает, что это наиболее стабильная часть программы, хотя в моем понимании это наоборот наименее стабильно. То фреймвор гораздо стабильнее себя ведет, он гораздо устойчивее.

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

в объектно -ориентированной парадигме мы знаем, что есть какой -нибудь smoke -толк, который объектно -ориентированный, но он обменивается объектами событиями, сообщениями. есть обмен сообщениями больше соответствует принципу открытости -закрытости, чем прямой вызов методов. Потому что, опять же, отправив сообщение, ты не завязан на его получателя, и само сообщение проще преодолевает границы, соответственно меньше завязывает...

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

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

(01:32:13.262)
какие -то вариации обсервера у тебя в разном виде есть в разных местах и соответственно есть шина, ты даже можешь так на сервисы разносить и так далее. Ну мы сейчас можем прийти к DDD. Да -да Ну я по сути продаменные события когда сказал, просто я недавно на Ларавелле писал код и там как раз мы именно так это имплементировали. Тут правда палка о двух концах. С одной стороны это реально очень важная крутая концепция, это надо понимать и знать, но честно у меня вот именно когда речь идет про прикладной такой код на фреймворке, когда ты пишешь конкретную бизнес логику.

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

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

но понять, что там произойдет, тебе занимает слишком много времени. Ну, отладка очень сильно усложняется в событийных всех системах, отладка, это нужно рамках фейковых событий посылать. И самое сложное, если у тебя есть последовательность вызовов, по стеку вызовов пройтись гораздо проще, про тому же... Ну, есть, в конечном итоге, тоже есть стек вызовов, потому что событие на самом деле, оно как бы не в вакууме существует, но тоже существует.

механизмовой передачи, но это дополнительные прослойки, которые нужно понимать как работают. А там же еще передача данных с разных уровней транзакционности. Короче, есть места, в которых я видел много усложнений и понимал, что лучше модифицировать, чем, честно говоря, делать события. Так что бывает по -разному. Да, ну понятно дело, что событийная... Ну опять же, посмотри, в чем прелесть событийная? Когда мы события можем серилизовать в какой -то понятный текстовый или бинарный формат.

(01:34:24.366)
мы можем развязать руки в плане распределенных систем, мы можем уже существовать не в каком -то одном адресном пространстве, где у нас событие является объектом или просто кусочком памяти по сути мы можем уже рассылать его и получить настоящий параллелизм мы можем получить настоящее распределение нагрузки и так далее и это событийная модель, она позволяет уйти мы ее можем легко масштабировать но это уже как бы не к солиду относится

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

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

Понятно дело, что вот больное место всех архитекторов, если бы можно было ничего не реализовывать, не надо было бы ничего реализовывать, то абстракции были бы идеальным способом объяснить всё, угодно. Можно нарисовать там красивую схему очень просто. Не то что просто, схемы не ломаются. Они работают и объясняют вещи магическим образом. И как раз...

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

(01:36:47.822)
каким принципами, идеями руководствоваться, чтобы не испытывать боль при ее сопровождении, изменении и при движении вперед. Вот про это солид, а не про то, что он поможет, как красиво написать функцию. Хотя про то, красиво написать функцию есть и замечательные авторы, которые это рассказывают. Тогда я бы сформулировал, чтобы закрыть тему с Open -Closed -Принцип. Мы сейчас поняли, когда вот это обсудили,

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

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

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

И очень часто даже не замечаем и не можем понять, что те принципы, которые не нужны, они реализованы в этих фреймворках и библиотеках. Когда мы работаем с библиотекой и передаем туда какой -нибудь callback или каким -то образом инжекцию зависимости, хотя это DI и ксолиду не имеет отношения, условно говоря, работаем с интерфейсом библиотеки, мы даже не думаем, что это реализация принципа D, инверсии зависимости.

(01:39:04.078)
когда мы видим, как скомпанован фреймворк и что у него есть четкие границы, у него все -таки есть там MVC pattern, который в принципе тоже можно рассматривать через Prisma Solid и понять, что там есть и разделение интерфейсов, там есть и открытие -закрытие, извиняюсь, уже поздно заговариваюсь. То есть мы используем инструменты, которые спроектированы с учетом этих принципов.

И даже тут есть такой момент, что многие люди, настолько эти принципы во многом прямо rocket science, люди просто читают чужой код или работают в проектах, где есть хорошие инженеры, они перенимают их, что называется, неявно. То есть они даже не осознают, что это принципы solid, они просто смотрят, как пишут их профессиональные коллеги.

принимают их стиль написания кода и может быть потом спустя время они такие о я же вот писал по solid потому что когда я вот здесь делал интерфейс это был deep когда я вот здесь вот делал событийную модель я использовал открытость закрытость когда я делал иерархию наследования хотя мы уже выяснили что это как бы не самые важные применения барбары листов в принципе косвенно это имеет к этому отношение вот и

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

и так далее. Здесь тоже самое, когда мы понимаем, что мы уже это используем, не явно, потому что учились на хороших примерах. И есть другой пример, когда ты попадаешь в плохой коллектив, ничего не надо, где все написано плохо, и ты там страдаешь, и даже не понимаешь, что ты страдаешь как раз потому, что там все сделано, как получится. Это все подставлено костыли, дублирование очень много, хотя, опять же, соли ты дублирования, тут можно подискутировать. Смысл в том, что мы

(01:41:20.398)
иногда не можем определить реально вот этот код, какие принципы он реализует, потому что это все как -то вот намешано, есть готовый код, есть не готовый код, но это не значит, что мы не должны на эту тему думать, мы как бы все -таки, я надеюсь, большинстве своем хотим делать работу профессионально, а не просто...

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

спагетикод строк на 700 и потом я понял, что указывается разбиение на функции и дублирование это избавление от дублирования, очень эффективные инструменты и также с солидом, когда ты начинаешь анализировать то, что тебя есть в набивании шишек и ты смотришь, о, а солид объясняет, почему мне было больно с этим кодом

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

да, при этом вот пока ты говорил, я подумал о том, что дайте пример приведу, framework разрабатывают ребята, опять же они это делают скорее всего не потому что они такие вот соль и там написано open -close они знают, что у тебя должна быть система плагинов например для внедрения новых функций, новой функциональности, еще чего -нибудь ну там на разных уровнях они ее реализуют, они ее делают, все хорошо у них хорошая получилась система, все дела при этом человек, который это использует

(01:43:35.598)
может творить такую дичь, да, то есть типа у тебя никакой фреймворк, никакая хорошая архитектура не приводит никакому добру. И поэтому я такой задумался, что по сути получается, что эта штука говорит о разных способах имплементации, которые можно типа пойти таким путем и таким, но при этом она совершенно не гарантирует, что выбрав какой -то один из этих способов, ты в целом получишь лучший результат, потому что очень дальше уже все зависит от того, как конкретно ты с этим работаешь. Вот что я сейчас понял, пока мы говорили.

Лучший способ научиться писать код, это писать код. есть много писать разного кода. это будет... Ещё раз, вот я хотел бы всё -таки вернуться. Когда я говорю про писать код, я не имею в виду солид. На самом деле, когда я связываю непосредственно кодирование и написание функций, разработка алгоритма, каких -то принципов, у меня это как -то неправильно совершенно. Эта связь есть? Ещё раз.

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

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

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

(01:45:48.59)
принципам открытости и закрытости, то есть мы можем в одну комнату что -то добавлять, а в другие ничего не менять, какую -то такую построить шкодную конструкцию, но понял, что это будет сильно как бы натянута. Потому что все -таки программная архитектура, она как бы отдельно стоит, и сегодня она очень сильно связана именно с кодированием. Хотя вот я, чем больше занимаюсь архитектурой, чем больше читаю книги по архитектуре, в головах архитекторов это вообще уже архитектура и кота.

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

У меня все расписано, меня все, у меня как бы нет места, где я принимаю решение. Мое решение заключается только в том, чтобы написать if или там две функции или одну функцию. Вот мой уровень принятия решений. И в таком смысле, конечно, теряется смысл солида, потому что ты никаких решений не принимаешь и тебе это как бы не очень нужно.

Окей, понятно, что тут все можно обсуждать. Давай оставим это для других видео. Это бесконечная тема, действительно. Вот давай перейдем к single responsibility. И я знаешь, чего начну с того, вот с твоего примера, ты говоришь, я бы там квартиры сказал, что мы квартиры делаем по solid. Одна из самых главных вещей, которую я вижу в solid, которую мне, особенно с single responsibility, ну знаешь так, меня скептитизм очень большой, потому что

скорее идет обратнотягивание. есть, к какой -нибудь человек приводит пример и говорит, вот это соответствует сингл -распенсабилити. Ну и принципе, и остальных принципов частично касается, когда фактически остальные, все, кто наблюдают со стороны, сначала, ну то есть, они понимают, что к этому ведется речь, они видят это, и они очень часто такие, ну да, наверное так, потому что именно

(01:48:02.286)
такой взгляд на компоненты, хотя, кстати, взгляд может быть разный, потому что понимаем, что тебя иерархия классов, всегда... Ну вообще любые иерархии – это какой -то конкретный взгляд. Можно перпендикулярно посмотреть, и тебя все станет по -другому. И это всегда подтверждается очень легко. У меня как -то был тоже с кем -то спор на тему single responsibility. Я показывал людям... Ну, статьи такие, говорил, вот смотрите, всегда в комментариях начинается срач, потому что вас гарантирована половина людей, будь не согласна с тем, как произошло разделение. То есть, несмотря на...

здравомыслие всего, что здесь есть, именно конкретно к single responsibility, опять же, если мы open -closed с тобой вот как мы разобрали, он как бы теперь, какой -то него смысл появился, то есть теперь стало понятней, хотя, честно говоря, оно, короче, периодически забывается, то есть ты типа, если долго это не говоришь, он забывается, то вот single responsibility, я считаю, что эта штука создает иллюзию понимания, она настолько неформальна, она настолько как бы абстрактна, и каждый воспринимает по -своему.

что вот именно когда человек, который говорит, я реализовал по single responsibility, во -первых, у меня всегда есть вопросы, а во -вторых, я вижу, что у комментаторов всегда есть вопросы, люди бы сделали по -другому. И согласие во многом идет только потому, что им это сказали, и они этот код видели. И если бы они его не видели, я почти наверняка имею в виду, что они бы сделали по -другому. Но я говорю на коде, потому что все -таки, если мы solid рассматриваем с точки зрения архитектуры, это немножко другой взгляд. А нас смотрят ребята, которые применяют это типа, ну вот solid код, я джавист, меня взяли на работу, спрашивают solid.

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

нужно смотреть не на то, как люди это интерпретируют. Вообще, бы, идеале, если принципы работают, они работают независимо от того, что думают вокруг люди. То есть, если они для тебя работают, то ты для себя... Первое, что поймешь, что используя эти принципи, тебе легче писать код, легче принимать решения. А ты для себя объясняешь какие -то вещи и находишь закономерности. И ты лучший свой в этом смысле контролер, если это тебе помогает делать архитектуру.

(01:50:26.318)
здорово, если не помогает, правильно ты сказал, попробовал, да, вот как сказать, нравится ли тебе кататься на велосипеде или нет, можно понять одним способом, покататься и понять, нравится или нет, вот здесь то же самое, нравится тебе принцип или нет, можно просто них немножко узнать, а если говорить о том, что люди по -разному воспринимают этот принцип, это здорово, потому что ну как бы это на самом деле говорит немножко о том, что он не конкретный, это понятно, да, но здорово в том плане, что

Если не будет разных взглядов на какую -то вещь, то эта вещь не будет источником вдохновения. А так, СРП, она очень сильно людей подталкивает к размышлению. Любые конфликты, особенно я это замечаю по себе, любой спор всегда выявляет какие -то твои недостатки, твои позиции, твои знания, чего -то еще. СРП в этом плане это идеальная тема, потому что ты наверняка узнаешь много -много всего нового.

просто поспорив с другими людьми в сети, что такое SRP. И никто не сойдется, но при этом каждый найдет для себя много полезной информации. Он там погуглит, подумает и так далее. Поэтому в этом плане, как я его понимаю, для меня это просто способ, опять же, уменьшать количество, мягко говоря, комбинаторную сложность своего решения. Чем меньше у у Роберта Мартина, как сказано, это по сути не то, что у нас

один класс отвечает за какую -то одну фичу, одну функцию. А то, что у нас есть только один источник, который определяет, что класс должен быть изменен. то есть, условно говоря, почему я привел квартиру вплачь в качестве SRP? Потому что в моем понимании, у меня сосед, у него своя квартира, у меня своя квартира, и только я принимаю решение, как мне здесь все обустроить. И это соответствует в моем понимании SRP. есть, единственное... или там...

моя семья единственные люди, которые принимают решение, как у меня здесь все должно быть. И в моем понимании и как бы то, что я читал у Роберта Мартин, это как раз та идея, что есть только один источник изменений, а так как ты единственный источник изменений, и ты только их вносил, то есть другие люди не вносили этих изменений, то ты лучше всего знаешь, изменения происходили. Хуже всего, когда там у семьи нянек дитя без глаз, потому что каждый что -то делает, а в итоге ты смотришь и не понимаешь почему.

(01:52:43.31)
если ты единственный человек или очень небольшая группа людей работала над кодом, над его архитектурой, то ты знаешь как в нем все работает и вот в этом для меня с пользой единственной ответственности это звучит но это звучит просто как владение кодом я тебе могу про квартиры сказать значит я живу в штатах в condominium несмотря на то что это моя квартира и владею я не имею права делать все здесь как хочу вот у тебя нарушается SRP

потому что тебя получается, с одной стороны живёшь ты и имеешь влияние определённо, а с другой если ещё какие -то ограничители и получается, что у тебя сложнее, то есть у тебя владельцев несколько, акторов, которые могут влиять на состояние твоих квартир и несколько, и нарушается СССРП и всё становится сложнее. А давайте я расскажу, как это становится, например, когда ты смотришь, ну один из примеров, примеров там может быть много, я тебе один из примеров приведу, если ты смотришь на фасад зданий, например,

потому что там просто таких законов нет. Это может быть где -то в локальном ЖК принято, но в целом глобального закона нет. То у тебя фасад любого здания, жилого, выглядит довольно удручающе в том плане, что кто влез, кто под рову, у кого -то там снаружи бутылки пива висят, ну в старых домах. Но в целом, понимаешь, у тебя там шторы, все разное. Если ты как бы гуляешь, например, здесь вот по Майами, и ты смотришь на фасады всех зданий, они выглядят абсолютно идентично в каком плане. У тебя, например, не бывает красных штор.

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

Это связано с тем, что старый дом, и здесь просто трубы не выдержат и так далее. И понимаешь, что если кто -то это сделает, а если бы него была такая свобода, он бы сделал, тогда он просто бы испортил жизнь всем остальным. И в этом смысле получается ровно наоборот. У нас гораздо более универсальное решение, единообразное, у тебя красота, и ты гораздо меньше паришься о том, что происходит, потому что, как знаешь, в русских домах, в русскоязычных часто бывает, в смысле в России, когда тебе надо... У тебя соседи шумят, еще что -то, ты как бы один на один с ними.

(01:55:00.846)
то есть тебе сложно короче решать проблемы а здесь у тебя система которая за тебя решает проблему максимум если тебе что -то не нравится ты пошел сказал это менеджеру который порешал вопрос и ты всегда знаешь что у тебя все примерно на хорошем уровне даже кстати двери входные у нас обязаны быть покрашены определенным образом а не определенного формата вот такие дела видишь это я даже не знаю какому принципу соответствует

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

но это на самом деле с точки зрения понимания почти никогда не работает поэтому вот все аналогии соли да с реальным миром чем -то в моей картине мира они не работают я никогда не видел чтобы это как -то потом влияло на то что человек вдруг нормальный код начинает писать вот ну здесь видишь то есть как бы можно дойти до безумия вообще если мы сейчас начнем это обсуждать понимаешь сам да можно да да но тогда это аналогия не сработала

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

в некоторых политиках кода ограничивает количество публичных методов словно говоря, больше семи публичных методов в интерфейсах ограничивает потому что чем больше у тебя публичных методов, чем больше у тебя разных вариантов использования это создает соответственность, что каждый вариант использования должен сочетаться с другими вариантами использования ну и простая комбинаторика говорит о том, что тебя количество вариантов использования растет невероятно быстро

(01:57:09.902)
И здесь то же самое, когда ты можешь так и так, то там малое количество, у тебя все выглядит однообразно, тебе меньше вариантов надо проверить, тебе проще, потому что ты видишь, что тебя невозможно много вариантов на выходе получить. Чем более свободна тебя твоя система ограничений, чем более свободно тебе можно делать решение о твоей программе, тем соответственно она становится разнообразнее, становится прострой, один делает так, другой так.

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

И в моем понимании СРП как раз про это, что у нас не должно быть много всего, у нас должно быть все более -менее собрано в одних руках, эти одни руки должны решать, что вот эти изменения мы внедряем, эти не внедряем, и они используют. У другой части, у другой команды своя зона ответственности. Это в моем понимании, как бы все -таки с одной стороны про зону ответственности, а за другой про то, чтобы не было большого количества вот...

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

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

(01:59:35.278)
мы вот про SRP проговорили, что вы об этом думаете уже в смысле, да, потому что, есть насколько стало вам понятно, потому что вот в моем ощущении пока это, честно говоря, выглядит немножко абстрактно и да, можно послушать, типа я вроде понял, но как это применить и где я это у себя прямо сейчас увижу и такой, а, вот, как будто бы этого нет и теперь пример я знаешь, какой люблю пример очень такой простейший, классический, да это, например, когда у тебя есть что -то, что выполняет некие действия и еще и сохраняет,

файловую систему, ну потому чаще всего говорят какой -то репортер, отчеты и так далее, да, ты там с помощью какого -то объекта это сгенерил и типа save, например, же самое касается active record и active record, очень часто приводят как антипаттерн, именно говоря о том, что смотрите, active record это вот самое, что ни на есть, это изменение, несмотря на то, что да, это две, можно сказать две ответственности, на самом деле там ответственности гораздо больше, то есть их вообще -то не две, честно говоря, если уж так копать, там не только базы, не только это, там еще можно всякого разного понапихать,

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

Да, но видишь, это скорее вопрос риторический, потому что речь идет исключительно о том, с какой стороны ты на это смотришь. Потому что если у тебя в одном классе будет все приложение твое бэкендовое, ты тоже можешь сказать, чем от NISRP, а я там напрямую с базой работаю. Ну и вообще просто тупо все в одном классе. Скорее всего, уже скажет, не -не -не, это уже нарушение. То есть для меня это вот на прикладном уровне всегда скатывается в картину мира конкретного человека, где у него проходит перпендикулярно и, понимаешь, горизонтально.

И когда он это накладывает, понимаешь, что это твой конкретный взгляд. Я не помню, базируясь только на определении SRP и только говоря про него, человек бы принял какое -то решение, которое такое типа, а, ну понятно, как это влияет на архитектуру и на все остальное. Вот, наверное, главное... Опять же, для меня это не звучит, в смысле, что это плохой принцип. Для меня это звучит скорее как «хорошо делай, хорошо будет».

(02:01:53.422)
но это отличается опять же от того, что ты сказал, потому что ты сказал очень конкретную вещь, но она не соответствует тому, как обычно рассуждают про SRP. Я бы сюда еще добавил закон конвейер, который говорит о том, что архитектура программной системы приобретает архитектуру организационной структуры предприятия. В этом смысле она очень неплохо начинает мачиться. есть что получается, у тебя есть отдел бэкэнда, отдел фронтэнда, они еще на что -то могут быть.

допустим, департамент backend и департамент frontend, они еще что -то бьются, каждый за них отвечает за какую -то часть, потому что руководитель тоже понимает, что у него есть срок, то есть нужно выполнить определенный набор фич в зависимости от размера предприятия, команды все, он начинает распределять обязанности. Распределение обязанностей это уже в некотором смысле определяет твою архитектуру приложений, потому что если она будет...

по -другому распределяться, то тебе придется двум разным отделом взаимодействовать друг с другом, чтобы менять один кусочек кода. И вот в моем понимании, когда ты распределяешь соответственно все по департаментам, отделам, командам, ты одновременно с этим создаешь архитектуру, где каждая команда в силу SRP создает свой кусок. И вот этот кусок, уже внутри, они организуют, определяется уже не SRP, что они там бьют, а вот уже начинается открытость, закрытость, deep

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

быстро внедрять новые фичи, хочешь меньше зависеть от изменений, хочешь чтобы тебе по ночам спать, не решать баги и так далее. И это все вместе создает такой некий баланс, который и является целью solida, в моем понимании. Видишь, как мы тобой с RP легко и быстро пробежали, потому что я думал, вот мы сейчас такие прокейсы разберем. Вообще можно, но тогда ладно. Мы тогда это пропускаем, я тогда такой тебе вопрос задам. Вот есть некий набор принципов, которые там Мартин собрал.

(02:04:16.814)
и честно говоря, как и любая популярная штука, сам же знаешь, это это не история, что они объективно лучшие, правильные и самые главные, именно их надо было собрать вместе, если бы не было, ну типа, знаешь, задумайся, вот если бы не было Мартина, собрал ли бы кто -то именно вот такой, вот они именно в таком порядке, и все бы потом 10 лет, 15 лет считали, что это самый главный принцип, и я уверен, что нет. наверняка что -то другое. Был бы другое, Есть же, Крек Ларман со своим Гресп, да, то есть у него же тоже это набор

шаблонам, как он их называет. там тоже есть вещи, которые перекликаются. Опять же, про Галет можно поговорить в отдельном топике, я просто сейчас не готов. Получается, что как минимум мы имеем несколько систем, как минимум две, я вторую могу сходу назвать, которые работают примерно в одном ключе. А там можно вспоминать про всякие, не разговаривая с незнакомцами, закон Диметры, можно всякие ягни, что там у нас еще, кисы и так далее. Дон Трипит?

Да, ну то есть, да и так далее. есть принципы они, ну просто их никто не собрал вот в одну аббревиатуру, хотя они тоже на слуху. Поэтому принципы они может быть не возникли бы вместе, они возникли по отдельности, но так или иначе какие -то принципы возникли бы, потому что ну человеческий мозг так устроен, что ему нужно упорядочить каким -то образом свою жизнь, чтобы, как я уже в начале сказал, чтобы принимать решение. Solid позволяет легче принимать решения, он позволяет тебе объяснить свой выбор.

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

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

(02:06:32.462)
то, что именно оно взлетело, Мартин же сам этого не ожидал, это, знаешь, всегда как бы с течения каких -то обстоятельств, что написал книжку где -то в 11 -1 месте в нужное время. Да, потому что ты говоришь, не собрали, да, конечно, все собрали, есть миллиард, я еще по пути, ну, ты тоже видел, по пути миллиард всяких слов, принципов, смешных аббревиатур каких угодно, но, к сожалению, уже поезд ушел, вот так вот... занято. Да, стрельнуть сложновато, вот. Именно поэтому у меня, наверное, такое, знаешь, одна из вещей связана с тем, что...

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

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

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

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

(02:08:49.454)
И таким образом у тебя очень четкое правило с гораздо более четкими границами, с гораздо меньшим количеством споров всего остального Да, он более прикладной Не, на самом деле его тоже можно высоко брать, сам знаешь, да, это тоже высокая штука Ну, в общем, я вижу, что можно смотреть на это по -другому и добиваться тех же самых результатов И при этом это будет гораздо меньше привязано к классам, потому что тот принцип, который я сказал, он абсолютно одинаково заходит и функциональщикам, и ООП -шникам

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

понятным прикладным, чем то, что получилось. Наверное, так я бы сказал. Идеи те же самые. Идеи очень похожи.

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

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

(02:10:48.878)
иной продукт от иного вендера, который поможет внести ясность в работу и в оценку архитектуры программных систем, здорово. Но пока это самое такое распиаренное, самое лучшее, что можно найти. Остальное нужно собирать, и это очень сложно собрать. Поэтому выбирая из потенциально более хорошего и лучшего и из реально существующего, пока solid, наверное...

выбрать и проще и будет хоть какая -то польза. А мечтать что -то можно придумать. Да, и поэтому мы нем сегодня, собственно, и говорим, как о первой, так сказать, ступеньке в этой истории. Большое спасибо, что пришел. Мне кажется, хорошо поговорили. Все, спасибо, что позвал. Все разобрали. Ребят, обязательно напишите, что вы об этом думаете. Это очень холиварная тема. Я подозреваю, что не все с нами согласны. Ставьте дизлайки, если не согласны. Пишите злобные комментарии.

Ну и добрые тоже не забывайте писать. Мы посмотрим и на все ответим. Всем спасибо, пока!