мы когда нанимаем я говорю что какая-то архитекрута у нас есть ) про солид не спрашиваем, спрашиваем как отредактировать коммит который запушил и не получить люлей )
Да часто любят эту херню спрашивать, а вот что замечал, когда спрашивает очень опытый специалист, ему вообще плевать, т.к. в коммерческой разработке нет времени, т.к. вот надо срочняк и самая жопа еще в том, что нет четкого понимания, а что будет дальше, поэтому особого смысла нет писать все красиво )
Евгений хорошо подметил, что одна из проблем кода - это "есть еще другие заинтересованные люди". Мне кажется это хорошо описывает ментальное состояние большинства ярых фанатов. Я назвал бы это принцип "инверсия понимания окружающего мира". То есть не мир ставит реальные задачи, а программист их автоматизирует, а программист строит свои замки идеальных абстракций, но иногда приходится загрязнять эти замки плохими хотелками злых дяденек и тетенек, которым что-то там надо. В добавок получается странные парадокс. Чистый код нужен (так же) чтобы можно было быстра вносить изменения, но когда надо быстро вносить изменения то приходится использовать другие подходы так как с чистым кодом быстро вносить изменения не получается. В целом дискуссия получилась интересная и я с удовольствием послушал обоих "спикеров".
Как по мне абсолютно неверно объяснен принцип DIP. Ключевое слово - это инверсия. Нужно для отделения высокоуровневых слоев от низкоуровневых (onion architerture, DDD и т.д.). Это возможно только через интерфейсы и только с помощью DI (в рантайме магия пропадает конечно). А зависимость от абстракций, а не от реализации - это только частично про DIP. И этот принцип далеко не всегда и везде нужен (в средних или небольших приложениях смысла нет в этом - используем интерфейсы в контексте полиморфизма и всё). А SRP - это вообще сакральная тема. Акторы, про которых упоминает Мартин, можно идендифицировать правильно только с опытом, когда ты видишь не только вертикальное разделение ответственности (домен - приложение - инфраструктура), но и вертикальное, с помощью разных бизнес контекстов. На собесах так вообще бесполезно про это спрашивать :)
DIP - это по факту простой колбэк если воспринимать это с точки зрения ФП. Мы инжектим в свою супер-функцию другую функцию в качестве параметра. И на этапе вызова в рантайме определяем какую реализацию будем передавать
**SOLID** - это набор принципов объектно-ориентированного программирования, направленных на улучшение качества кода. Принципы SOLID помогают делать код более гибким, понятным и поддерживаемым. Однако они также могут подвергаться критике при чрезмерном применении или в случаях, когда они не соответствуют задачам проекта. ### 1. **Single Responsibility Principle (SRP)** - Принцип единственной ответственности **Описание:** Каждый класс должен отвечать только за одну задачу или функцию в системе. Если класс выполняет несколько обязанностей, то изменения в одной обязанности могут повлиять на другую. **Плюсы:** Упрощает код, делает его более понятным, снижает взаимозависимость. **Критика:** При излишне строгом применении можно раздробить логику на слишком мелкие классы, что приведет к усложнению структуры и увеличению числа объектов. ### 2. **Open/Closed Principle (OCP)** - Принцип открытости/закрытости **Описание:** Программные сущности должны быть открыты для расширения, но закрыты для модификации. Это означает, что поведение системы можно изменять, не меняя исходный код. **Плюсы:** Уменьшает необходимость в изменении уже написанного кода, снижает вероятность появления багов при добавлении новых функций. **Критика:** Реализация этого принципа часто приводит к усложнению абстракций и созданию чрезмерного количества классов и интерфейсов. ### 3. **Liskov Substitution Principle (LSP)** - Принцип подстановки Барбары Лисков **Описание:** Объекты наследующих классов должны корректно заменять объекты базовых классов без нарушения работы программы. Другими словами, наследуемый класс не должен нарушать логику базового. **Плюсы:** Повышает предсказуемость поведения программы, снижает вероятность возникновения ошибок при использовании полиморфизма. **Критика:** В реальных проектах могут возникнуть ситуации, когда для соответствия этому принципу приходится искусственно ограничивать наследование, что снижает гибкость. ### 4. **Interface Segregation Principle (ISP)** - Принцип разделения интерфейсов **Описание:** Клиенты не должны быть вынуждены зависеть от интерфейсов, которые они не используют. То есть, лучше создавать несколько специализированных интерфейсов, чем один универсальный. **Плюсы:** Улучшает декомпозицию системы, делает код более читаемым и гибким. **Критика:** Излишнее следование принципу может привести к созданию множества мелких интерфейсов, что затруднит восприятие и усложнит работу с кодом. ### 5. **Dependency Inversion Principle (DIP)** - Принцип инверсии зависимостей **Описание:** Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций (интерфейсов), а абстракции не должны зависеть от конкретных реализаций. **Плюсы:** Позволяет легко заменять и масштабировать модули, что повышает гибкость и расширяемость системы. **Критика:** Реализация DIP требует написания большого числа интерфейсов и абстракций, что может усложнить код и сделать его трудным для понимания. --- ### Общая критика SOLID: - **Усложнение кода:** Излишнее следование SOLID может привести к фрагментации кода, увеличению числа классов, интерфейсов и абстракций. Это делает систему сложной для понимания и сопровождения, особенно для небольших проектов. - **Затруднённость рефакторинга:** В реальных проектах иногда проще модифицировать существующий код, чем расширять его через создание новых классов и интерфейсов. - **Избыточная гибкость:** В некоторых случаях требуется предсказуемая и прямая реализация функционала, а SOLID может слишком усложнить простые задачи. Тем не менее, **SOLID** остается важным инструментом для улучшения качества кода, особенно в больших проектах с множеством взаимозависимостей, при этом его применение должно быть оправдано контекстом проекта.
Ребят, всё супер, спасибо за такие разговоры вслух! Маленький нюанс/просьба - тайм-коды... те что есть - немного не айс, не найти потом быстро по теме что надо. Конкретно хочу упасть обратно на барбара-лисков начало обсуждения и попробуй вспомни и найди, к примеру )
O - принцип легко понять. Есть метод, расширяя его функционал для других использований нельзя менять поведение, которое существовала изначально. Дополнительное поведение не должно ломать предыдущее.
По-моему наоборот. Класс должен быть спроектирован так, чтобы его не нужно было менять а достаточно было бы расширять. Это не требование как пользоваться существующим кодом (расширять/менять), это требование как проектировать этот код - так чтобы мотиваций менять было мало а мотиваций расширять было много.
DI делает код "независимым" (и то условно) только относительно конкретной реализации. Это значит, предполагается, что реализаций потенциально может... нет, даже ДОЛЖНО быть несколько. И вот тут начинается "ОДНАКО": * а откуда известно, что реализаций будет несколько * а откуда известно, что реализации будут примерно такими * а кто сказал, что интерфейс останется постоянным Соответственно перед тем, как думать про DI, нужно понимать, что пункты выше хотя бы имеют реальный смысл, иначе программисты платят за ненужные часы разработки ненужной штуки, которая возможно будет выброшена завтра, или навсегда останется неизменной. Тут наверное самым главный вопросом может быть даже не вопрос... а будет ли несколько реализаций. А вопрос: а будет ли вообще интерфейс ВОЗМОЖЕН. Потому что бывают ситуации, когда стабильный интерфейс в принципе неизвестен.
Ну всё же можно в духе Unix-way продумать несложные и, предположительно, стабильные интерфейсы. Если опыт позволяет, то ждёт +/- успех, а остальное - комбинации и/или решается адаптерами.
@@VladimirS-h9o А в этом вся соль. Чтобы создать идеальные интерфейсы, которыми точно можно пользоваться нужно ЗАРАНЕЕ знать какие будут компоненты. Если компонентов заранее нет, то интерфейсов быть не может. Но об этом ни в какой книге ничего не говориться. Иначе говоря, если программист __заранее знает__ с вероятностью 80%, что у него будет вот такая БД и такая БД (или сервис или что там ещё), и при этом у него есть многолетний опыт работы с этими БД, то он может создать интерфейс, который будет обладать минимальной стабильностью. Есть ли такие проекты с такими условиями? Да. Но это проекты, когда ничего нового не создаётся. Шаг влево шаг вправо, и интерфейсы превращаются в 100% антипатерн.
@@EdmondDantesIf Так изначально ты же бьешь во слоям условно, кусок работы с бизнес логикой, кусок работы с базой/внешними сервисами, на каждом лое есть контракт, что он возвращает, условно какую-то доменную модель, которая будет универсальна для всех реализаций. Можно изначально предположить, сколько может быть реализаций, заложив заранее все риски, а так никто точно не скажет, сколько будет реализаций, но дальнейшая поддержка кода однозначно будет легче, хотя бы из-за того, что ты юниты на все это добро сможешь норм написать
@@Dmitry-ug1zq Это возможно только в том случае, если ДО того как код написан, уже известны абстракции и хотя бы на 90% понятно, как они разделены. И известно, какие реализации будут хотя бы с вероятностью 50%. А такое возможно только в небольшом количестве случаев... например когда компания рефакторит уже существующий проект.
Принципы SOLID , это не законы которые нельзя нарушать, это принципы позволяют принять решение в спорной ситуации когда стоит вопрос так или вот так, тогда тихий голос SOLID шепчет: «вот так будет лучше!»
С DIP хороший пример недавно видел, в проекте набор процессов, и каждый процесс заводит либо определенное количество потоков либо по требованию. Классы потоков расширяют общий класс с характерными только для них свойствами и методами, из-за ограничения языка в расширении более одного класса, пришлось разбивать и в конструктор каждому классу передавать коннектор, проблема в том, что коннекторы тоже имеют общие свойства и методы, но они не совместимы между собой полностью, тогда сделал для них один абстракный класс и реализовал его во всех, а потом просто инициализировал через конструктор в родительском общем классе. Про SOLID в тот момент не думал, просто прикинул если не кидать коннектор в общий класс через абстракцию, а каждому засунуть свой конкретный экземляр, то потом если что-то надо будет добавить всем сразу, всё же они родня по рантайму, то это будет боль, а так в абстрактном написал и все классы покраснели сколько бы их ни было. ❗Простыми словами . Есть класс User, который расширяет класс Database и User передает в Database экземпляр класса Websocket, чтобы Database сообщал на клиента ход событий. Так вот если зашить Websocket как экземпляр, то например класс Cron уже не сможет расширить Database, так как Websocket у него свой (Коннект с другим сервером), одинаковые лишь некоторые методы и свойства. Ну а то что разное в их вебсокетах - они внутри себя юзают, несмотря на то, что через один и тот же класс. При помощи DIP можно бесконечно много таких по своему уникальных, но имеющих ряд сходств классов вводить в АБСТРАКТНУЮ зависимость от одного общего. ❗❗❗ Вообще элементарный пример, есть функция, которая часто переопределяется, так вот мы пишем параметры для неё в отдельном интерфейсе, вместо того, чтобы просто проставлять типы в сигнатуре и используем везде где нужно повторить. Вот и вся инверсия зависимости, но узнают только те кто дочитал до конца😀
формат топ, продолжайте в том же духе! я бы правда хотел предложить перед тем как что-то обсуждать - проговорить формулировку и вообще обозначить что имеется ввиду. потому что интерпретаций разных букв солида по разному есть, не говоря о том что кто-то уже и забыл сами формулировки.
Не разбирал все принципы SOLID, но принцип единой ответственности разобрал подробно в 3 частях на своем канале - это если захочется подискутировать (ссылку оставить видимо нельзя, но оставлю название для поиска: "Принцип единой ответственности (SRP) - что с ним не так?" )
Отличное видео SOLID кажется крайне избитой темой, однако то, что он до сих пор так активно обсуждается как раз говорит об отсутствии консенсуса. Спасибо за новые точки зрения
Про Барбару Лисков мне нравится метафора воронки. Воронка - допустим это класс с одной функцией. Мы хотим поменять одну воронку на другую. Т.е. поменять супертип на подтип. Входное горлышко это что на вход, выходное на выход. В подтипе (другой воронке) можно входное горлышко расширить, но сужать его нельзя иначе то входило в супертип в подтип не пролезет. И наоборот выходное горлышко у новой воронки можно сужать, но нельзя расширять потому что там куда выходное горлышко у прежней воронки раньше входило оно не влезет.
58:55 не, возвращение нулевого элемента там, где супертип вернул бы другое значение - тоже нарушение БЛ. Мне кажется, вы недооценивать то, какие ограничения на самом деле накладывает БЛ. Оно же не про сигнатуры методов и исключений, а про полную подмену подтипа супертипом с полным сохранением поведения. Т.е. переопределение в этом контексте в принципе неуместно ни в какой форме. Как я понимаю, это очень сложный (для исполнения) принцип, который практически всегда нарушается. Например, в терминах канонического определения LSP (того, что в вики): T extends S, q := (x : T) |-> x.foo(55) == 20 forall (x:T)(q(x : T)) => forall (y : S)(q(y)) Или словами, если у любого инстанса суперкласса foo на 55 возвращает 20, то и все инстансы подкласса должны делать ровно так же. Строго по определению LSP.
Евгений вскользь упомянул Smalltalk. Это ключевой язык для понимания, откуда пришли паттерны и, в общем-то, принципы. И почему они именно так сформулированы. И именно в нём они приобретают полный смысл. В остальных языках они работают гораздо хуже. Как та самая сова на глобусе.
Спасибо, формат зашел, интересно послушать разные взгляды! Хотел бы закинуть еще одну холиварную тему - автотесты. Там также миллион пирамид разных, разные "школы", виды тестов и тд.
Кирилл, привет! 21:41 у меня появился вопрос по данной теме, который уже достаточно давно висит в неопределённости. 21:56 - "У тебя есть прототипы, которые ты можешь пофиксить" В сети среди программистов испокон веков бытует мнение, что язык имеет классы, если он соответствует требованиям закрытости. Например, в Java. А язык, основанный на прототипах, классов не имеет. Это всегда вызывало у меня вопросы, потому как в определении класса из CS "In object-oriented programming, a class is a template definition of the methods and variables in a particular kind of object" класс - это некоторый шаблон, на основе которого строятся объекты с одинаковым поведением. В определении нет никаких упоминаний о том, что класс должен быть статичным (закрытым, неизменяемым). Ещё во времена до ES6 в языке существовала возможность реализовать шаблон-конструктор с помощью function. На выходе получали объект с определенным поведением, принадлежность к конструктору которого можно было определить с помощью оператора instanceof. Собственно, сам вопрос: почему инструменты прототипного языка, попадающие под общее определение класса, классами не являются? Я понимаю разницу между классово-ориентированными и объектно-ориентированными языками. Первые всегда используют классы для создания объектов. Для вторых наличия класса для создания объекта не обязательно. Но ведь "не обязательно" не есть "невозможно". В том же Python, например, объект можно создать без класса на основе встроенных типов данных. Тогда почему про JS говорят, что в нём нет классов, потому что конструктор в нём открытый?
Почему нельзя просто использовать здравый смысл? Тот же SRP - просто базовый инженерный принцып, который говорит о том, что одна "штука" должна отвечать строго за одну единицу работы, тогда и надежность будет, и компоновать "штуки" можна. Или функциональное программирование - основные принцыпы: разделяем данные и сайд-эффекты, а если исполнителей (то есть типов функций) больше одного, просто передаем нужный исполнитель аргументом (то есть получаем тот же DI из функций высшего порядка). А вот с SOLID просто какой-то звиздец. Роберт Мартин где-то украл название, потом лет через 20 написал, что он-де что-то там не так понимал все это время (другими словами - сам не понимает, о чем говорит), а потом вообще спрыгнул с Джавы в Кложу, то есть, с ООП в Лисп, в функциональщину. А все годамы теребят яйки, обсуждая, что же на самом деле такое SOLID, и как и где и его использовать...
В реальном физическом мире это как раз не является жестким требованием. Есть устройства, где тепло, как побочный продукт работы одной подсистемы, используется другой подсистемой, то есть подсистемы получаются неявно связанными. Но там изначально и нет требования модульности.
@@VoroninPavel Согласен, но в инженерии подобная неявная связь считается "паразитной" и нежелательной, поскольку в итоге ведет к недетерменированному поведению в крайевых случаях. Я же, по большей части, говорил о другом - о том, что можно использовать здравый смысл и хорошо обкатанные методики из инженерии (посмотреть тот же курс MIT 6.001 SiCP) для создания сложных и расширяемых систем. А не надрачивать годами на слова одного мужика - т.е. Роба Мартина - создавая SOLID-религию из его интрепретаций чужих слов (учитывая еще и то, что он сам признал, что его интерпретации ошибочны).
@@AlexanderBorshak я думаю, дядя Боб по сути этими буквами обозначил тот же здравый смысл =) А религию... так Губерман хорошо написал: Возглавляя партии и классы, лидеры вовек не брали в толк, что идея, брошенная в массы, - это девка, брошенная в полк.
@@AlexanderBorshak сегодня вот Informit опубликовали наконец-то книгу Влада Хононова: Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems Будем посмотреть =)
@@VoroninPavel > я думаю, дядя Боб по сути этими буквами обозначил тот же здравый смысл =) Здравый смысл вроде как достаточно просто объяснить с помощью нескольких примеров, равно как и придти к какому-то общему мнению о нем. Тут же, как мы видим, никакого общего мнения нет годами, если не десятилетиями. Даже в данном видео (за которое авторам, конечно же, спасибо) - говорили 2 часа, но к общему знаменателю так и не пришли. Так что здесь явно что-то не то...
В конце совсем заболтались. Если у тебя все приложение реакт - это один класс, то этот класс не нарушает принцип единственной ответственности, потому что у него одна ответственность - инициализировать и соединить все взаимодействующие классы. Есть только одна причина для его изменения - когда нам ужны другие классы и другая хема их взаимодействия. Если класс создается чтобы склеить во-едино ввод-вывод и вычисления, то естественно он будет выполнять ввод-вывод и вычисления, но это не будет его ответвенностями. Он не меняется если меняется алгоритм вычислений, он только склеивает.
В Scala кстати, можно управлять вариантностью тайп параметров, задавать нижние и верхние границы. Это по поводу Лисков. Активно используется как писателями либ, таки и обычными работягами.
S - это база. Если класс называется User то там не должно быть полей accessToken refreshToken, потому что User и Token это разные сущности и когда то может появиться необходимость поддержки нескольких токенов для одного пользователя.
для меня LSP, это про то, что при разработке типов надо больше уделять внимание поведению типа, а не тому, какие данные этот тип предоставляет. а поведение типа, как раз и выражено в предусловиях и постусловиях
"Не слишком ли мы закопались в детали" имхо наоборот прошлись по верхам. На 43:38 так и не сказали что есть DIP и чем он отличается от DI. СОЕР пытался, но что-то его отвлекло))
В го неплохо обстоят дела с общими интерфейсам в разных библиотеках. Во многом за счёт того что го в свой стандартный набор библиотек затащили многие нужные для современной разработки вещи. И разработчикам сторонних библиотек для интеграции со стандартными необходимо использовать типовые интерфейсы.
Принцип LSP вообще фундаментальная вещь. Если у нас в родительком объекте url это url, то расширяющий его объект уж никак не должен держать в url что-то другое.
1:06:45 Я везде задаю этот вопрос: нахрена 95% разрабов знать алгоритмы, если всё уже написано? При таком подходе, всем надо уметь в ассемблер. А чё, везде же используется. А вот про то что прежде чем отвергать SOLID, надо плотно его год попрактиковать, согласен полностью. SOLID (большая его часть) выстреливает на длинной дистанции, и главный его плюс - легкость изменений. Конечно, все вмеру, но штука очень мощная, хоть и ни разу не новая концептуально.
Полиглотам "сверху" лучше видно, так же и в естественных языках - очередной язык/парадигма помогает лучше понимать предыдущие. Когда человек думает исключительно (иногда принципиально) в ООП - довольно сложно поднять его в абстракциях на уровень выше.
По Iнтерфейсам с Соером не согласен. Недавно сам к этому пришел. В проекте одна главная группа процессов и несколько зависимых групп процессов, в каждой группе один главный и несколько дочерних процессов, каждый из зависимых дочерних процессов работает через вебсокет с конкретными из главных дочерних. Так вот, по идее, протокол один, рантайм родственный, ну и сделал для всех коммуникаций один оберточный интерфейс с общими свойствами и одним свойством универсальным, которое является встроенным интерфейсом, каждая коммуникация отдельное свойство интерфейса, всё четко, работает через утиные генерики по одному из общих полей - другого не засунешь. Так вот проблема сейчас, что универсальный встроенный интерфейс юзают не связанные логически части программы. Нужно было использовать для каждой пары контактирующих процессов отдельный интерфейс или встроенному интерфейсу добавить ещё один уровень который тоже будет генерить по назначениям. Потому что, хотя коннекты используют только свои свойства, однако то, что все эти наборы в одном и том же интерфейсе это наводит путаницу, когда нужно быстро нарисовать в голове картину что и куда идет. ❗Сложно получается, вот простой пример. Если у тебя есть фабрика, которая производит широкий спектр товаров, с уникальными свойствами каждый, то пусть эти товары будут разбиты по категориям и каждый магазин ничего не знает о товарах из тех категорий с которыми он не работает.
подниму активность к вопросу про "грамар наци" в солид обсуждениях. мне кажется, что выяснять термины - это важно и нужно, это буквально основа любой хорошей дискуссии. когда каждый говорит о своём, всё скатывается в бессмысленный холивар. а аналогия с языком и учебниками кажется не совсем корректной, ведь есть ещё промежуточные варианты между слепым прескриптивизмом, от которого сейчас уходят, и полным отсутствием общепринятых дефиниций у слов по причине того, что все понимают по-разному
@@VladimirS-h9o Боюсь спикеры тоже не особо врубаються о чем рассказывают. Меня когда первый раз спросили на собесе про Солид, это был 2019 год, у меня тогда было 15 лет коммерческого опыта и 21 год опыт общего программирования и сотни тысяч строк кода написанного и десятки проектов. За следующие 5 лет я пытался найти ответы, смирился с тем что этот вопрос задают, заметил что мнения у людей по этим принципам всегда разные, кроме может буквы I. Доказательство кто прав обычно производиться оскорблениями или повышением голоса. Для себя я нашел способ рассказывать эту сказку, но не уверен что она нравиться всем.
43:40 Я бы наоборот настаивал на том, чтобы вы больше закапывались в детали. Я понимаю, что с одной стороны хочется, чтобы было понятно и новичкам, но я бы на них не фокусировался. Всё таки кажется, что ваша основная аудитория уже опытные программисты
SRP - это когда взяли программный модуль с состоянием и на его основе создали ООП и куча паттернов. И он ответственнен за кучу лишней архитектуры и тонны макулатуры на эту тему.
@@danilakhtarov SOLID появился в ООП, но многие его идеи перекликаются с базовыми принципами функционального программирования. Чистые функции, иммутабельность, функции высшего порядка и полиморфизм через алгебраические типы позволяют в ФП добиватся тех же целей - модульности, гибкости, переиспользуемости и независемости компонентов, как и SOLID в ООП.
Joel Spolsky в середине нулевых выкатил статью о видах ПО. Если Ваш код меньше 1000 строк, код одноразовый или embedded без возможности обновления, то SOLID не нужен. Буква O как мне кажется применимо только к такому виду софта как публичные библиотеки. Если Вы пишите enterprise и по сути прикладной софт, то скорее всего Вам все равно на модификации, поэтому и столько непонимания. Когда же Вам нужно backward compatibility, правила deprecation между версиями, то важно конечно создавать интерфейс нужной расширяемости и не требующий изменений.
Чтобы быть "адвокатом" нужно приобрести компетенции, а не опыт на основе проектов из лапши и кома грязи. Лучше бы просто задали вопросы гостю чем прерывайющий, загрязняющий шум, который и порождает непонимание. Книжки читать надо а не смотреть на опыт, основанный на вредных привычках аля "видел так делают, удобно"
Зайдите в ближайший бар, купите 2 литра разливного, вернись обратно, поставьте эту СОЛИДную философию на скорость x0.5 и можете понять как со стороны нас видят девушки, когда мы берем их с собой в заведение и компанией мужиков обсуждаем айтишечку.
Знаете, по-моему нифига понятней не стало, нагнали очередного тумана, налили воды, и у людей с критическим мышлением 😎 только укрепляются сомнения - а заслуживает ли тема такого внимания? Из пяти принципов два "по большому счету бесполезны", два "все понимают неправильно", а один "создает ложное чувство понимания".
По поводу DIP, ни один ни второе не знает что это такое. В обсуждении ошибочно подменили понятие DIP на "абстракция" из ООП. Здесь ключевое слове "инверсия", в общем погуглите. Но формат крутой, трушный.
По Single responsibility - уже по лучше интерпретация, уже ближе к правде, но тоже не совсем в точку. Хочется сказать ребят, ну вы почитайте книжку Дяди Боба, ну пожалуйста прежде чем рассуждать... А если прочитали переведите на русский верно то что написано в книжке... 😢 Это один из важнейших архитектурных принципов, который может очень грамотно изменить продукт, этот принцип нужен как для разработчика так и для продуктов. Беда в том что есть умные люди или понимающие люди, а есть те кто много говорит, но приведённый вариант уже по лучше... Кирилл если будет время, найди меня, свяжись - odyshew roman, объясню грамотно за SRP
@@agpone1 как можно не однозначно трактовать текст - "A module should be responsible to one, and only one, actor." The term actor refers to a group (consisting of one or more stakeholders or users) that requires a change in the module ? А вот как - не читать книгу, а читать статьи, цель написания который как раз таки поднять холивар что бы сделать саму статью популярной ☝
Насколько по вашему SOLID влияет на то как вы пишите код?
Прекрасные принципы если их не трактовать буквально.
ща посмотрим что это такое (помню только single responsibility) и скажу)
ни насколько, реквест кинул, данные по пропсам распихал, зарплату получил, пошел пиво пить.
@@mastnova2676 а че так можно было?
Srp, dip, open-closed прям топ, но команде объяснить зачем, конечно бывает сложно
Как выше в комменте написали - пиво,зарплата - что пристал 😅
Дед с батей сцепились по пьяни и испортили всем восприятие SOLID каждый раз одно и то же
Спрашивают на каждом собесе.
Выходишь на работу, в коде Х ночевал.
Я думаю каждый несёт ответственность чтобы самостоятельно использовать, как религиозные правила
Так тебя наверно и нанимают, чтобы Х не было. Не?
мы когда нанимаем я говорю что какая-то архитекрута у нас есть ) про солид не спрашиваем, спрашиваем как отредактировать коммит который запушил и не получить люлей )
Да часто любят эту херню спрашивать, а вот что замечал, когда спрашивает очень опытый специалист, ему вообще плевать, т.к. в коммерческой разработке нет времени, т.к. вот надо срочняк и самая жопа еще в том, что нет четкого понимания, а что будет дальше, поэтому особого смысла нет писать все красиво )
Ждем Егора Бугаенко с тру ООП
SOLIDный разговор SOLIDных мужчин
Ждем подкаста про GRASP
Евгений хорошо подметил, что одна из проблем кода - это "есть еще другие заинтересованные люди". Мне кажется это хорошо описывает ментальное состояние большинства ярых фанатов. Я назвал бы это принцип "инверсия понимания окружающего мира". То есть не мир ставит реальные задачи, а программист их автоматизирует, а программист строит свои замки идеальных абстракций, но иногда приходится загрязнять эти замки плохими хотелками злых дяденек и тетенек, которым что-то там надо.
В добавок получается странные парадокс. Чистый код нужен (так же) чтобы можно было быстра вносить изменения, но когда надо быстро вносить изменения то приходится использовать другие подходы так как с чистым кодом быстро вносить изменения не получается.
В целом дискуссия получилась интересная и я с удовольствием послушал обоих "спикеров".
Классно. Такие беседы заставляют мозг взглянуть на то, что он уже освоил с другого ракурса и немного переосмыслить сложившеся понимание этих принципов
Как по мне абсолютно неверно объяснен принцип DIP. Ключевое слово - это инверсия. Нужно для отделения высокоуровневых слоев от низкоуровневых (onion architerture, DDD и т.д.). Это возможно только через интерфейсы и только с помощью DI (в рантайме магия пропадает конечно). А зависимость от абстракций, а не от реализации - это только частично про DIP. И этот принцип далеко не всегда и везде нужен (в средних или небольших приложениях смысла нет в этом - используем интерфейсы в контексте полиморфизма и всё). А SRP - это вообще сакральная тема. Акторы, про которых упоминает Мартин, можно идендифицировать правильно только с опытом, когда ты видишь не только вертикальное разделение ответственности (домен - приложение - инфраструктура), но и вертикальное, с помощью разных бизнес контекстов. На собесах так вообще бесполезно про это спрашивать :)
Соер один из немногих кто дело говорит. Легендарный человек.
Выпуск зашел! Давайте еще
DIP - это по факту простой колбэк если воспринимать это с точки зрения ФП. Мы инжектим в свою супер-функцию другую функцию в качестве параметра. И на этапе вызова в рантайме определяем какую реализацию будем передавать
Только это DI, а не DIP
@@qqq2084ee похоже, потому что и то, и другое, и третье можно решить через коллбеки.
**SOLID** - это набор принципов объектно-ориентированного программирования, направленных на улучшение качества кода. Принципы SOLID помогают делать код более гибким, понятным и поддерживаемым. Однако они также могут подвергаться критике при чрезмерном применении или в случаях, когда они не соответствуют задачам проекта.
### 1. **Single Responsibility Principle (SRP)** - Принцип единственной ответственности
**Описание:** Каждый класс должен отвечать только за одну задачу или функцию в системе. Если класс выполняет несколько обязанностей, то изменения в одной обязанности могут повлиять на другую.
**Плюсы:** Упрощает код, делает его более понятным, снижает взаимозависимость.
**Критика:** При излишне строгом применении можно раздробить логику на слишком мелкие классы, что приведет к усложнению структуры и увеличению числа объектов.
### 2. **Open/Closed Principle (OCP)** - Принцип открытости/закрытости
**Описание:** Программные сущности должны быть открыты для расширения, но закрыты для модификации. Это означает, что поведение системы можно изменять, не меняя исходный код.
**Плюсы:** Уменьшает необходимость в изменении уже написанного кода, снижает вероятность появления багов при добавлении новых функций.
**Критика:** Реализация этого принципа часто приводит к усложнению абстракций и созданию чрезмерного количества классов и интерфейсов.
### 3. **Liskov Substitution Principle (LSP)** - Принцип подстановки Барбары Лисков
**Описание:** Объекты наследующих классов должны корректно заменять объекты базовых классов без нарушения работы программы. Другими словами, наследуемый класс не должен нарушать логику базового.
**Плюсы:** Повышает предсказуемость поведения программы, снижает вероятность возникновения ошибок при использовании полиморфизма.
**Критика:** В реальных проектах могут возникнуть ситуации, когда для соответствия этому принципу приходится искусственно ограничивать наследование, что снижает гибкость.
### 4. **Interface Segregation Principle (ISP)** - Принцип разделения интерфейсов
**Описание:** Клиенты не должны быть вынуждены зависеть от интерфейсов, которые они не используют. То есть, лучше создавать несколько специализированных интерфейсов, чем один универсальный.
**Плюсы:** Улучшает декомпозицию системы, делает код более читаемым и гибким.
**Критика:** Излишнее следование принципу может привести к созданию множества мелких интерфейсов, что затруднит восприятие и усложнит работу с кодом.
### 5. **Dependency Inversion Principle (DIP)** - Принцип инверсии зависимостей
**Описание:** Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций (интерфейсов), а абстракции не должны зависеть от конкретных реализаций.
**Плюсы:** Позволяет легко заменять и масштабировать модули, что повышает гибкость и расширяемость системы.
**Критика:** Реализация DIP требует написания большого числа интерфейсов и абстракций, что может усложнить код и сделать его трудным для понимания.
---
### Общая критика SOLID:
- **Усложнение кода:** Излишнее следование SOLID может привести к фрагментации кода, увеличению числа классов, интерфейсов и абстракций. Это делает систему сложной для понимания и сопровождения, особенно для небольших проектов.
- **Затруднённость рефакторинга:** В реальных проектах иногда проще модифицировать существующий код, чем расширять его через создание новых классов и интерфейсов.
- **Избыточная гибкость:** В некоторых случаях требуется предсказуемая и прямая реализация функционала, а SOLID может слишком усложнить простые задачи.
Тем не менее, **SOLID** остается важным инструментом для улучшения качества кода, особенно в больших проектах с множеством взаимозависимостей, при этом его применение должно быть оправдано контекстом проекта.
Спасибо большое за обсуждение :-)
Ребят, всё супер, спасибо за такие разговоры вслух! Маленький нюанс/просьба - тайм-коды... те что есть - немного не айс, не найти потом быстро по теме что надо. Конкретно хочу упасть обратно на барбара-лисков начало обсуждения и попробуй вспомни и найди, к примеру )
Соер: "зачем писать таймкоды? МОЖНО ЖЕ ПОПРОСТИЬ У AI!"
O - принцип легко понять. Есть метод, расширяя его функционал для других использований нельзя менять поведение, которое существовала изначально. Дополнительное поведение не должно ломать предыдущее.
По-моему наоборот. Класс должен быть спроектирован так, чтобы его не нужно было менять а достаточно было бы расширять. Это не требование как пользоваться существующим кодом (расширять/менять), это требование как проектировать этот код - так чтобы мотиваций менять было мало а мотиваций расширять было много.
DI делает код "независимым" (и то условно) только относительно конкретной реализации. Это значит, предполагается, что реализаций потенциально может... нет, даже ДОЛЖНО быть несколько. И вот тут начинается "ОДНАКО":
* а откуда известно, что реализаций будет несколько
* а откуда известно, что реализации будут примерно такими
* а кто сказал, что интерфейс останется постоянным
Соответственно перед тем, как думать про DI, нужно понимать, что пункты выше хотя бы имеют реальный смысл, иначе программисты платят за ненужные часы разработки ненужной штуки, которая возможно будет выброшена завтра, или навсегда останется неизменной.
Тут наверное самым главный вопросом может быть даже не вопрос... а будет ли несколько реализаций. А вопрос: а будет ли вообще интерфейс ВОЗМОЖЕН. Потому что бывают ситуации, когда стабильный интерфейс в принципе неизвестен.
Ну всё же можно в духе Unix-way продумать несложные и, предположительно, стабильные интерфейсы. Если опыт позволяет, то ждёт +/- успех, а остальное - комбинации и/или решается адаптерами.
@@VladimirS-h9o А в этом вся соль. Чтобы создать идеальные интерфейсы, которыми точно можно пользоваться нужно ЗАРАНЕЕ знать какие будут компоненты. Если компонентов заранее нет, то интерфейсов быть не может. Но об этом ни в какой книге ничего не говориться.
Иначе говоря, если программист __заранее знает__ с вероятностью 80%, что у него будет вот такая БД и такая БД (или сервис или что там ещё), и при этом у него есть многолетний опыт работы с этими БД, то он может создать интерфейс, который будет обладать минимальной стабильностью. Есть ли такие проекты с такими условиями? Да. Но это проекты, когда ничего нового не создаётся. Шаг влево шаг вправо, и интерфейсы превращаются в 100% антипатерн.
@@EdmondDantesIf Так изначально ты же бьешь во слоям условно, кусок работы с бизнес логикой, кусок работы с базой/внешними сервисами, на каждом лое есть контракт, что он возвращает, условно какую-то доменную модель, которая будет универсальна для всех реализаций. Можно изначально предположить, сколько может быть реализаций, заложив заранее все риски, а так никто точно не скажет, сколько будет реализаций, но дальнейшая поддержка кода однозначно будет легче, хотя бы из-за того, что ты юниты на все это добро сможешь норм написать
@@Dmitry-ug1zq Это возможно только в том случае, если ДО того как код написан, уже известны абстракции и хотя бы на 90% понятно, как они разделены. И известно, какие реализации будут хотя бы с вероятностью 50%. А такое возможно только в небольшом количестве случаев... например когда компания рефакторит уже существующий проект.
Принципы SOLID , это не законы которые нельзя нарушать, это принципы позволяют принять решение в спорной ситуации когда стоит вопрос так или вот так, тогда тихий голос SOLID шепчет: «вот так будет лучше!»
неплохо ) хорошо когда люди делятся практическим опыт а не просто обсуждают коров в вакууме
С DIP хороший пример недавно видел, в проекте набор процессов, и каждый процесс заводит либо определенное количество потоков либо по требованию. Классы потоков расширяют общий класс с характерными только для них свойствами и методами, из-за ограничения языка в расширении более одного класса, пришлось разбивать и в конструктор каждому классу передавать коннектор, проблема в том, что коннекторы тоже имеют общие свойства и методы, но они не совместимы между собой полностью, тогда сделал для них один абстракный класс и реализовал его во всех, а потом просто инициализировал через конструктор в родительском общем классе. Про SOLID в тот момент не думал, просто прикинул если не кидать коннектор в общий класс через абстракцию, а каждому засунуть свой конкретный экземляр, то потом если что-то надо будет добавить всем сразу, всё же они родня по рантайму, то это будет боль, а так в абстрактном написал и все классы покраснели сколько бы их ни было.
❗Простыми словами . Есть класс User, который расширяет класс Database и User передает в Database экземпляр класса Websocket, чтобы Database сообщал на клиента ход событий. Так вот если зашить Websocket как экземпляр, то например класс Cron уже не сможет расширить Database, так как Websocket у него свой (Коннект с другим сервером), одинаковые лишь некоторые методы и свойства. Ну а то что разное в их вебсокетах - они внутри себя юзают, несмотря на то, что через один и тот же класс. При помощи DIP можно бесконечно много таких по своему уникальных, но имеющих ряд сходств классов вводить в АБСТРАКТНУЮ зависимость от одного общего.
❗❗❗ Вообще элементарный пример, есть функция, которая часто переопределяется, так вот мы пишем параметры для неё в отдельном интерфейсе, вместо того, чтобы просто проставлять типы в сигнатуре и используем везде где нужно повторить. Вот и вся инверсия зависимости, но узнают только те кто дочитал до конца😀
Ура! Отличный звук
формат топ, продолжайте в том же духе!
я бы правда хотел предложить перед тем как что-то обсуждать - проговорить формулировку и вообще обозначить что имеется ввиду. потому что интерпретаций разных букв солида по разному есть, не говоря о том что кто-то уже и забыл сами формулировки.
Очень интересны подобные осуждения! Хотим продолжения!
Не разбирал все принципы SOLID, но принцип единой ответственности разобрал подробно в 3 частях на своем канале - это если захочется подискутировать (ссылку оставить видимо нельзя, но оставлю название для поиска: "Принцип единой ответственности (SRP) - что с ним не так?" )
Мне нравится такой формат, спасибо! :)
Высший пилотаж - не долбить головой стены, а знать когда или зачем принципы нужно нарушить на пользу делу.
Очень интересный выпуск, вы в процессе дискуссии обмениваетесь опытом из которого можно для себя многое вынести!
Отличное видео
SOLID кажется крайне избитой темой, однако то, что он до сих пор так активно обсуждается как раз говорит об отсутствии консенсуса.
Спасибо за новые точки зрения
Про Барбару Лисков мне нравится метафора воронки.
Воронка - допустим это класс с одной функцией.
Мы хотим поменять одну воронку на другую. Т.е. поменять супертип на подтип.
Входное горлышко это что на вход, выходное на выход.
В подтипе (другой воронке) можно входное горлышко расширить, но сужать его нельзя иначе то входило в супертип в подтип не пролезет.
И наоборот выходное горлышко у новой воронки можно сужать, но нельзя расширять потому что там куда выходное горлышко у прежней воронки раньше входило оно не влезет.
58:55 не, возвращение нулевого элемента там, где супертип вернул бы другое значение - тоже нарушение БЛ.
Мне кажется, вы недооценивать то, какие ограничения на самом деле накладывает БЛ.
Оно же не про сигнатуры методов и исключений, а про полную подмену подтипа супертипом с полным сохранением поведения.
Т.е. переопределение в этом контексте в принципе неуместно ни в какой форме.
Как я понимаю, это очень сложный (для исполнения) принцип, который практически всегда нарушается.
Например, в терминах канонического определения LSP (того, что в вики):
T extends S,
q := (x : T) |-> x.foo(55) == 20
forall (x:T)(q(x : T)) => forall (y : S)(q(y))
Или словами, если у любого инстанса суперкласса foo на 55 возвращает 20, то и все инстансы подкласса должны делать ровно так же. Строго по определению LSP.
И никаких новых исключений тоже быть не может. LSP действительно стоит особняком в этом списке, КМК.
Спасибо за дискуссию! Отлично закрепляется материал из курса JS: полиморфизм ;)
Евгений вскользь упомянул Smalltalk. Это ключевой язык для понимания, откуда пришли паттерны и, в общем-то, принципы. И почему они именно так сформулированы. И именно в нём они приобретают полный смысл. В остальных языках они работают гораздо хуже. Как та самая сова на глобусе.
Спасибо, формат зашел, интересно послушать разные взгляды!
Хотел бы закинуть еще одну холиварную тему - автотесты. Там также миллион пирамид разных, разные "школы", виды тестов и тд.
Отличный выпуск про дебри программирования. Давайте еще! Гость очень понравился. Здравые получились дебаты
49:00 принцип Барбары Лисков можно выразить как нельзя кристаллизировать предусловие и разряжать(диффузировать) постусловие
льзя
Кирилл, привет!
21:41 у меня появился вопрос по данной теме, который уже достаточно давно висит в неопределённости.
21:56 - "У тебя есть прототипы, которые ты можешь пофиксить"
В сети среди программистов испокон веков бытует мнение, что язык имеет классы, если он соответствует требованиям закрытости. Например, в Java. А язык, основанный на прототипах, классов не имеет. Это всегда вызывало у меня вопросы, потому как в определении класса из CS "In object-oriented programming, a class is a template definition of the methods and variables in a particular kind of object" класс - это некоторый шаблон, на основе которого строятся объекты с одинаковым поведением. В определении нет никаких упоминаний о том, что класс должен быть статичным (закрытым, неизменяемым).
Ещё во времена до ES6 в языке существовала возможность реализовать шаблон-конструктор с помощью function. На выходе получали объект с определенным поведением, принадлежность к конструктору которого можно было определить с помощью оператора instanceof.
Собственно, сам вопрос: почему инструменты прототипного языка, попадающие под общее определение класса, классами не являются?
Я понимаю разницу между классово-ориентированными и объектно-ориентированными языками. Первые всегда используют классы для создания объектов. Для вторых наличия класса для создания объекта не обязательно. Но ведь "не обязательно" не есть "невозможно". В том же Python, например, объект можно создать без класса на основе встроенных типов данных. Тогда почему про JS говорят, что в нём нет классов, потому что конструктор в нём открытый?
Очень классный выпуск. Формат шикарный
Почему нельзя просто использовать здравый смысл? Тот же SRP - просто базовый инженерный принцып, который говорит о том, что одна "штука" должна отвечать строго за одну единицу работы, тогда и надежность будет, и компоновать "штуки" можна. Или функциональное программирование - основные принцыпы: разделяем данные и сайд-эффекты, а если исполнителей (то есть типов функций) больше одного, просто передаем нужный исполнитель аргументом (то есть получаем тот же DI из функций высшего порядка). А вот с SOLID просто какой-то звиздец. Роберт Мартин где-то украл название, потом лет через 20 написал, что он-де что-то там не так понимал все это время (другими словами - сам не понимает, о чем говорит), а потом вообще спрыгнул с Джавы в Кложу, то есть, с ООП в Лисп, в функциональщину. А все годамы теребят яйки, обсуждая, что же на самом деле такое SOLID, и как и где и его использовать...
В реальном физическом мире это как раз не является жестким требованием. Есть устройства, где тепло, как побочный продукт работы одной подсистемы, используется другой подсистемой, то есть подсистемы получаются неявно связанными. Но там изначально и нет требования модульности.
@@VoroninPavel Согласен, но в инженерии подобная неявная связь считается "паразитной" и нежелательной, поскольку в итоге ведет к недетерменированному поведению в крайевых случаях. Я же, по большей части, говорил о другом - о том, что можно использовать здравый смысл и хорошо обкатанные методики из инженерии (посмотреть тот же курс MIT 6.001 SiCP) для создания сложных и расширяемых систем. А не надрачивать годами на слова одного мужика - т.е. Роба Мартина - создавая SOLID-религию из его интрепретаций чужих слов (учитывая еще и то, что он сам признал, что его интерпретации ошибочны).
@@AlexanderBorshak я думаю, дядя Боб по сути этими буквами обозначил тот же здравый смысл =) А религию... так Губерман хорошо написал:
Возглавляя партии и классы, лидеры вовек не брали в толк, что идея, брошенная в массы, - это девка, брошенная в полк.
@@AlexanderBorshak сегодня вот Informit опубликовали наконец-то книгу Влада Хононова: Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems
Будем посмотреть =)
@@VoroninPavel > я думаю, дядя Боб по сути этими буквами обозначил тот же здравый смысл =)
Здравый смысл вроде как достаточно просто объяснить с помощью нескольких примеров, равно как и придти к какому-то общему мнению о нем. Тут же, как мы видим, никакого общего мнения нет годами, если не десятилетиями. Даже в данном видео (за которое авторам, конечно же, спасибо) - говорили 2 часа, но к общему знаменателю так и не пришли. Так что здесь явно что-то не то...
Все должно быть на интуитивном уровне, как грамматика
Эти принципы обязательно нужно преподавать джунам.
Что применять или нет, профи решит сам интуитивно.
В конце совсем заболтались. Если у тебя все приложение реакт - это один класс, то этот класс не нарушает принцип единственной ответственности, потому что у него одна ответственность - инициализировать и соединить все взаимодействующие классы. Есть только одна причина для его изменения - когда нам ужны другие классы и другая хема их взаимодействия. Если класс создается чтобы склеить во-едино ввод-вывод и вычисления, то естественно он будет выполнять ввод-вывод и вычисления, но это не будет его ответвенностями. Он не меняется если меняется алгоритм вычислений, он только склеивает.
В Scala кстати, можно управлять вариантностью тайп параметров, задавать нижние и верхние границы. Это по поводу Лисков. Активно используется как писателями либ, таки и обычными работягами.
S - это база. Если класс называется User то там не должно быть полей accessToken refreshToken, потому что User и Token это разные сущности и когда то может появиться необходимость поддержки нескольких токенов для одного пользователя.
для меня LSP, это про то, что при разработке типов надо больше уделять внимание поведению типа, а не тому, какие данные этот тип предоставляет. а поведение типа, как раз и выражено в предусловиях и постусловиях
"Не слишком ли мы закопались в детали" имхо наоборот прошлись по верхам. На 43:38 так и не сказали что есть DIP и чем он отличается от DI. СОЕР пытался, но что-то его отвлекло))
В го неплохо обстоят дела с общими интерфейсам в разных библиотеках. Во многом за счёт того что го в свой стандартный набор библиотек затащили многие нужные для современной разработки вещи. И разработчикам сторонних библиотек для интеграции со стандартными необходимо использовать типовые интерфейсы.
Принцип LSP вообще фундаментальная вещь. Если у нас в родительком объекте url это url, то расширяющий его объект уж никак не должен держать в url что-то другое.
1:06:45 Я везде задаю этот вопрос: нахрена 95% разрабов знать алгоритмы, если всё уже написано? При таком подходе, всем надо уметь в ассемблер. А чё, везде же используется.
А вот про то что прежде чем отвергать SOLID, надо плотно его год попрактиковать, согласен полностью. SOLID (большая его часть) выстреливает на длинной дистанции, и главный его плюс - легкость изменений. Конечно, все вмеру, но штука очень мощная, хоть и ни разу не новая концептуально.
Надо шарить экран с кодом, чтобы не об облаках в небе говорить, а так классно
Не не, эти подкасты можно слушать на прогулке, а когда с кодом, то надо у компа сидеть.
Полиглотам "сверху" лучше видно, так же и в естественных языках - очередной язык/парадигма помогает лучше понимать предыдущие.
Когда человек думает исключительно (иногда принципиально) в ООП - довольно сложно поднять его в абстракциях на уровень выше.
1:27:20 final пишут что бы не наследовался, расширение должно быть устроено не через наследование ;)
класс. очень понравилось. обсудите TDD, там тоже много спорных моментов
Ну нормальный диалог, иногда в сторону (дебри) конечно уходили, но в целом зашло. Наткнулся на ссылку на LinkedIn , подписался.
Оч круто
По Iнтерфейсам с Соером не согласен. Недавно сам к этому пришел. В проекте одна главная группа процессов и несколько зависимых групп процессов, в каждой группе один главный и несколько дочерних процессов, каждый из зависимых дочерних процессов работает через вебсокет с конкретными из главных дочерних. Так вот, по идее, протокол один, рантайм родственный, ну и сделал для всех коммуникаций один оберточный интерфейс с общими свойствами и одним свойством универсальным, которое является встроенным интерфейсом, каждая коммуникация отдельное свойство интерфейса, всё четко, работает через утиные генерики по одному из общих полей - другого не засунешь. Так вот проблема сейчас, что универсальный встроенный интерфейс юзают не связанные логически части программы. Нужно было использовать для каждой пары контактирующих процессов отдельный интерфейс или встроенному интерфейсу добавить ещё один уровень который тоже будет генерить по назначениям. Потому что, хотя коннекты используют только свои свойства, однако то, что все эти наборы в одном и том же интерфейсе это наводит путаницу, когда нужно быстро нарисовать в голове картину что и куда идет.
❗Сложно получается, вот простой пример. Если у тебя есть фабрика, которая производит широкий спектр товаров, с уникальными свойствами каждый, то пусть эти товары будут разбиты по категориям и каждый магазин ничего не знает о товарах из тех категорий с которыми он не работает.
подниму активность
к вопросу про "грамар наци" в солид обсуждениях. мне кажется, что выяснять термины - это важно и нужно, это буквально основа любой хорошей дискуссии. когда каждый говорит о своём, всё скатывается в бессмысленный холивар.
а аналогия с языком и учебниками кажется не совсем корректной, ведь есть ещё промежуточные варианты между слепым прескриптивизмом, от которого сейчас уходят, и полным отсутствием общепринятых дефиниций у слов по причине того, что все понимают по-разному
Классно, но нехватает визуального отображения. сложно понимать
У меня возникло ощущение, что я понимаю о чём говорит каждый, но ребята друг друга не понимают.
подскажите что за наушники у вас с микрофоном
shokz
Мне всегда эти рассказы о SOLID напоминают:
- Сколько стоят помидоры?
- ... Идет часовой текст из видео...
- Так сколько стоят помидоры?
Мне когда разговор неинтересен, я тоже не врубаюсь что происходит
@@VladimirS-h9o Боюсь спикеры тоже не особо врубаються о чем рассказывают. Меня когда первый раз спросили на собесе про Солид, это был 2019 год, у меня тогда было 15 лет коммерческого опыта и 21 год опыт общего программирования и сотни тысяч строк кода написанного и десятки проектов. За следующие 5 лет я пытался найти ответы, смирился с тем что этот вопрос задают, заметил что мнения у людей по этим принципам всегда разные, кроме может буквы I. Доказательство кто прав обычно производиться оскорблениями или повышением голоса. Для себя я нашел способ рассказывать эту сказку, но не уверен что она нравиться всем.
43:40 Я бы наоборот настаивал на том, чтобы вы больше закапывались в детали. Я понимаю, что с одной стороны хочется, чтобы было понятно и новичкам, но я бы на них не фокусировался. Всё таки кажется, что ваша основная аудитория уже опытные программисты
SRP - это когда взяли программный модуль с состоянием и на его основе создали ООП и куча паттернов.
И он ответственнен за кучу лишней архитектуры и тонны макулатуры на эту тему.
Ты архитектор. Нет ты архитектор.
Хорошо, я архитектор, но ты архитектуристый архитектор.
Нет ты архитектуристый архитектор…
Успешно освоить JS и положить паттерны. Из - за динамической природы языка можно все перепробовать и переболеть краснухой.
А насколько SOLID применим к функциональному программированию по вашему мнению?
В фп всё есть функция.
S - функция
O - функция
L - функция
…
@@danilakhtarov
SOLID появился в ООП, но многие его идеи перекликаются с базовыми принципами функционального программирования. Чистые функции, иммутабельность, функции высшего порядка и полиморфизм через алгебраические типы позволяют в ФП добиватся тех же целей - модульности, гибкости, переиспользуемости и независемости компонентов, как и SOLID в ООП.
Joel Spolsky в середине нулевых выкатил статью о видах ПО. Если Ваш код меньше 1000 строк, код одноразовый или embedded без возможности обновления, то SOLID не нужен. Буква O как мне кажется применимо только к такому виду софта как публичные библиотеки. Если Вы пишите enterprise и по сути прикладной софт, то скорее всего Вам все равно на модификации, поэтому и столько непонимания. Когда же Вам нужно backward compatibility, правила deprecation между версиями, то важно конечно создавать интерфейс нужной расширяемости и не требующий изменений.
40:00 - не подходит как аргумент на примере базы данных. Это дерево. Частный случай леса.
Напоминает меня бухого с коллегой по работе на вечеринке, попытка разъяснить ситуацию кто же «батя» 😊😊😊
S0ER - легенда! 😎
Принцип Единственной Ответственности нарушает принципы ООП.
О, господин Промис, собственной персоной!Кирилл, пригласите Мурыча, пожалуйста!
Я понял инверсию зависимостей👍
Уж если это видео, то можно было бы и кода показать и графики немного хотя бы )
Кто знает, что за гарнитура у Кирилла?
@@3ggr shokz
Чтобы быть "адвокатом" нужно приобрести компетенции, а не опыт на основе проектов из лапши и кома грязи. Лучше бы просто задали вопросы гостю чем прерывайющий, загрязняющий шум, который и порождает непонимание. Книжки читать надо а не смотреть на опыт, основанный на вредных привычках аля "видел так делают, удобно"
2:50 мартин в блоге сказал что лисков это не про на следование как он раньше писал
Позовите Мурыча 😂 он вас спецификацией на место поставить
48:20 Два здоровых мужика начали обсуждать женщину за ее спиной 😂
после этого видео стало еще больше не ясно)
Зайдите в ближайший бар, купите 2 литра разливного, вернись обратно, поставьте эту СОЛИДную философию на скорость x0.5 и можете понять как со стороны нас видят девушки, когда мы берем их с собой в заведение и компанией мужиков обсуждаем айтишечку.
Solid топ монолит бататный Картоп
Каки
диалог двух странных))))))))))))
Такой противный Соер
Знаете, по-моему нифига понятней не стало, нагнали очередного тумана, налили воды, и у людей с критическим мышлением 😎 только укрепляются сомнения - а заслуживает ли тема такого внимания? Из пяти принципов два "по большому счету бесполезны", два "все понимают неправильно", а один "создает ложное чувство понимания".
Чисто фронтендер пытается в тему, в которой он не силен)
Ох повезло тебе что тут кловунов нет, тебе бы напихали
По поводу DIP, ни один ни второе не знает что это такое. В обсуждении ошибочно подменили понятие DIP на "абстракция" из ООП. Здесь ключевое слове "инверсия", в общем погуглите.
Но формат крутой, трушный.
Мнение процессора о SOLID:
11010000 10101111 00100000 11010000 10111101 11010000 10111000 11010001 10000101 11010001 10000011 11010001 10001111 00100000 11010000 10111101 11010000 10110101 00100000 11010000 10111111 11010000 10111110 11010000 10111101 11010001 10001111 11010000 10111011
Его мнение без солида может быть менее многословным
По Single responsibility - уже по лучше интерпретация, уже ближе к правде, но тоже не совсем в точку. Хочется сказать ребят, ну вы почитайте книжку Дяди Боба, ну пожалуйста прежде чем рассуждать... А если прочитали переведите на русский верно то что написано в книжке... 😢
Это один из важнейших архитектурных принципов, который может очень грамотно изменить продукт, этот принцип нужен как для разработчика так и для продуктов.
Беда в том что есть умные люди или понимающие люди, а есть те кто много говорит, но приведённый вариант уже по лучше...
Кирилл если будет время, найди меня, свяжись - odyshew roman, объясню грамотно за SRP
Может принцип не очень, если у него бесконечность интерпретаций?)
Да еще же нужно учитывать на каком слое этот принцип применяется. Тут у каждого своя предметная и системная область бдшники бэкендеры фронты
@@agpone1принципы топ. Но на разную семантику ЯП они накладываются иначе.
@@agpone1 как можно не однозначно трактовать текст - "A module should be responsible to one, and only one, actor." The term actor refers to a group (consisting of one or more stakeholders or users) that requires a change in the module ?
А вот как - не читать книгу, а читать статьи, цель написания который как раз таки поднять холивар что бы сделать саму статью популярной ☝
ШУЕ
40:00 - не подходит как аргумент на примере базы данных. Это дерево. Частный случай леса.