Дякую шановний ! Дуже цікавий приклад Ви розглянули. Геть по іншому сприймав цей принцип. Насправді, тут можна багато прикладів різних типів класів. Тонна корисної інфи, варто це обережно пробувати ручками 🤝
Касательно самого принципа, ну я бы немного придрался :) Все таки SRP также должен учитывать и функциональные требования, особенно это касается когда люди еще любят DRY применять всегда и везде. То что в данный момент некоторые куски кода или некоторые классы у вас выглядят одинаково совсем не значит, что в дальнейшем они будут одинаковы. SRP больше говорит о том, что причины для изменения одного класса должны лежать только в одной функциональной области. Например, не должно быть так, что один и тот же класс у вас правится, если вам необходимо поменять формат вывода счет фактуры в pdf и правило расчета цен для этой же фактуры. Расчет цен условий - одна функциональная область, вывод документа на печать - другая. Менять один и тот же класс(а тем более метод) в обоих этих случаях - чет хрень какая-то :) То что вы описали, все таки ближе именно к DRY(ну или очень сильно с ним пересекается), но тут опять такая загвоздка - не всегда код который выглядит одинаково - отвечает за один и тот же функционал с точки зрения бизнес логики. Тогда переиспользование таких классов - это только вред, т.к. рано или поздно(и с очень большой попаболью) придётся эти зависимости разрывать. Да и вообще SRP может быть(и должен) обоснован без упоминания переиспользования как такового, т.к. решает другую проблему - проблему раздутых и god классов. Упоминание переиспользования только добавляет каши и может привести к неверному выводу, что если я не хочу переиспользовать этот функционал где-то еще, то можно его в принципе и не выносить. Clean Code у Мартина очень спорная книга, большинство пунктов полезные, но есть и прям вредные моменты. Намного более нейтрально и основательно практически 90% пунктов(если не 100) из чистого кода также описаны в Совершенном коде Макконнелла. Не категорично, не безусловно, а скорее как раз так просто описательно. Что они дают и чего помогают достичь. Именно из-за того, что сначала читал Совершенный код, чистый код во многом казался уже вторичным продуктом. При этом намного более грубым в подаче, с невразумительными примерами. При этом в Совершенном коде кроме того что есть у Мартина дана еще куча полезной инфы. Так что я бы брал её и можно, в принципе, больше не читать книг именно касательно качества кодовой базы с точки зрения её организации. При этом обе книги я бы рекомендовал не сразу прям, а лучше где-то после нескольких месяцев(может даже полгода) работы. Чтобы уже была база и был опыт работы с большими кодовыми базами. Только тогда многие моменты будут понятны, иначе многие пункты просто ни за что не зацепятся(не будет опыта, на основе которого постоянно будет кликать в голове "а вот как это делается" или "блин, и так можно было"). Т.е. сначала немного покопаться, набить пару шишек и потом уже всё это разложить по полочкам. Читать эти книги при прохождении каких-то курсов, когда у вас опыта особо еще нет - трата времени, имхо конечно же. С паттернами "банды 4х" та же история, вообще не понимаю людей, которые эту книгу советуют новичкам. Обычно, когда человек "дорос" до этой книги, он о ней уже сам прекрасно знает :)
clean code довольно таки широко принятый подход...вполне можно сказать даже стандарт де факто, по крайней мере когда речь идет об современных ооп языках.
@@ergo_____3491 Волне возможно, только вот у Матрина такой же перекос, только в сторону длины методов, лишних . Не дай бог метод будет длинным! "Первое правило: Функции должны быть компактными. Второе правило: функции должны быть еще компактнее. Желательно, чтобы длина функции не превышала 20 строк". Не, я не спорю, может на основе его опыта это и так, но возводить это в правило? Или то что заголовочные комментарии javadoc к каждому методу - это трата времени. Абсолютно не упоминая контекст, когда это может быть необходимо для банальной сдачи проекта на поддержку, т.к. это требование было прописано в договоре, что все интерфейсы должны быть задокументированы. Да и по примерам с кодом есть вопросы. У вас наверняка есть эта книга, посмотрите примеры 6.1 и 6.2. Почему Мартин считает, что пример 6.2 лучше, без вопросов. Что он не раскрывает реализации(хотя это не так, геттеры без проблем раскрывают реализацию. При этом это интерфейс, и мы должны его реализовать, чтобы получить возможность использовать точки. А чтобы его реализовать, нам надо реализовать все методы, а что если они нам не нужны? Тут уже идет явное нарушение принципе YAGNI, зачем в интерфейс зашивать полярные координаты, если в требовании явно говорится что мы будем хранить координаты точки на декартовой плоскости? В каждой из этих книг есть перекосы, просто в книге Макконнелла они более нейтральны. Там меньше "правил" и "требований" в жестких формулировках. Ну и конечно когда читаешь эти книги надо понимать, что информатику может и можно отнести к точным наукам, но уж не в разрезе прикладного программирования с точки зрения структуры кода. Тут мы ближе к лингвистике. Так что любые советы надо не просто принимать, а анализировать и пропускать через себя и свой опыт. Именно поэтому я читал обе книги, именно поэтому и посоветовал эти книги(какую бы вы ни выбрали) читать уже получив какой-то свой, собственный опыт. Иначе это может превратится в слепое поклонение принципам. Я все эти книги воспринимаю больше как мнение старших товарищей, нежели как правила или требования, которые являются для меня отправной точкой, чтобы не пришлось самому набивать некоторые шишки. Но если в какой-то момент я решу написать метод длиннее 20 строк и мне это будет казаться более разумной идеей, нежели дробление его на 5 других методов - то почему нет?
@@dmitriyobidin6049 Методы должны быть максимально короткими, 1-5 строк идеально. Все остальное - рассадник багов, боль для тех, кто пишет тесты и тех, кто работает с этим кодом в будущем.
Огромное спасибо, что записали это видео. Программирование - это великая наука. А интересная просто ЖУТЬ как)))))))))))))))))) Однажды создав маленькую программу данный процесс уже не остановить!!!
тема определенно интересна, хотелось бы побольше таких видео - коротенько, суть, так сказать. Ведь самое сложное - дойти до простого. Когда большой тутор новичок теряется. Важно сначала понять суть, а потом уже можно вникать в детали. А у Сергея очень хорошая подача, что тоже очень важно
обожаю такие видео, где ты смотришь про то, что используешь - но при этом не знаешь как оно в мире зовется :) то что здесь рассказывает человек - ну это же "естественные" вещи, ну или меня так учили в 2000-х годах
Ну наконец-то. Хоть кто-то использует адекватные примеры. А то везде натыкаюсь на примеры, от которых возникает только один вопрос: "как про такую чушь бесполезную столько книг понаписали?" Теперь хоть понятно, что и так всегда его использовал) Спасибо
5:45 В книге "Чистая архитектура" дядюшка Боб говорит о том, что обычно этот принцип озвучивают про "одну обязанность", но это не совсем верно! Потом он вводит действующее лицо "Пользователь или группа пользователей. Назовем их авторами" и потом дает точную формулировку принципа: Модуль должен изменяться только из-за одного актора.
Спасибо Вам большое) Очень интересно Вас слушать на эти темы. Примерно год назад слушал это видео, но был, как я сейчас понял, даже еще не новичком, а пересматривая сейчас, понимаю, что эти принципы очень даже логичны и даже не осознанно сам так делаю) еще раз спасибо Вам за такие видео, однозначно лайк )
Спасибо! Я тоже программист с большим опытом (вероятно, не меньшим, чем у автора), и не то, чтобы меня настигло откровение в этом видео, но ещё разок вспомнить основы, рассказанные с чуть нового угла - всегда полезно и приятно.
Тема очень важна и подача хороша.Ждем скорее продолжения)Спасибо) Еще ,если будет время,интересно послушать о ЛЯМБДА-ВЫРАЖЕНИЯХ и ФУНКЦИОНАЛЬНЫХ ИНТЕРФЕЙСАХ. Еще интересно послушать о классах String Builder и String Buffer. Про многомерные массивы и еще куча всего)))
Сам я ни сколько не програмист. Но пришлось сделать автоматизацию рутины, которая сберегла кучу времени и нервов целому коллективу преподавателей. Писал в vba. Часть кода записал с помощью рикодера ворда, часть нагуглил в рунете. Вот тогда я интуитивно стал понимать что я столкнулся с проблемой правильной декомпозиции, а также создания правильных "классов". То есть коды на отдельные операции я где-то нагуглил, а где-то записал с помощью рикодера и изначально привязывал их к соответствующим горячим клавишам, с помощью которых их последовательно запускал. Но с увеличением количества таких макросов, запуск этих команд также стала превращаться в рутину. И меня осенило, что я их могу объеденить по определенным блокам, в зависимости от очередности исполнения кода. Я объединял их с помощью другого vba кода. И привязал исполнение всего кода лишь к одной комбинации горячей клавиши. Самое главное, этот макрос я мог переносить на любой пк, где после минутной настройки он становился рабочим и им мог пользоваться лбой юзер.
Здравствуйте, а вы сами придумали этот пример или из книги взяли? Я просто другие примеры читал, и вот после многочисленных споров по пониманию SRP нашел видео где Мартин 50 минут про него говорит. Линк - ruclips.net/video/Gt0M_OHKhQE/видео.html (с привязкой ко времени, в которое он дает определение). Главное в SRP, на сколько я понял - это то, чтобы модуль обслуживал одного актора (роль, группа пользователей), для решений задач которых и создан модуль. Дело о человеке, о той роли что он выполняет. Этот принцип чуть выше того что один метод должен выполнять что то одно. Например - у нас сайт с продажей видеокасет. По SRP у нас должны быть разные контроллеры, разные сервисы для Админа и Кастомера. Разные модули, для разных ролей. Изменяем Админку, не затрагиваем Кастомера и наоборот. Ну и внутри подроли - просматривающий отчет, ДБ администратор и т.п. Тут я сам не всегда понимаю где отличие от простого разбиение на функции. И получается что общий код (общий сервис, где то в глубине) может быть в общем модуле, но как только появляются отличия, код нужно разносить по разным модулям, каждый под свою роль, этот вопрос не очень раскрыт.
Поздравляю с новой камерой, отличная картинка! И вижу повышаете качество не только в картинке но и в умении заинтересовать новичков)) Хитрый Немчинский называет кучу новых терминов и ребята сразу начинают думать, ого как мало я знаю и как много неизвестных слов еще предстоит узнать))
Огромное спасибо! Послушать бы ещё про репозитории чтения/записи, потому-что каждый крутит их как хочет, и суёт и чтение и запись в один репозиторий... Было-бы классно услышать мнение опытного человека
Большое спасибо! Даже при условии прочтения о SOLID в книге "Чиста архитектура", интересно послушать, как это воспринимает профессиональный разработчик. Было бы интересно в кратце узнать о "Аспектно ориентированном программировании" и какие задачи оно решает на реальных проектах. Ещё раз огромное спасибо за Ваш труд.
Слышу я такой про active record, что так делать не надо и понимаю (о! а это оказывается шаблон такой есть! не знал, любовь к велосипедам с детства даёт о себе знать наверное), что я так делаю почти постоянно, ставлю на паузу, лезу в код, прикидываю, как исправить ситуцаию, начинаю набрасывать каркас решения, снимаю с паузы и ... "В энетепрайзе это нормально, многие так делают, хотя это и нарушает srp". Занавес.
@Sergey скажите, интересует вопрос связи грасп-паттерна информ.эксперт (IE) и текущего(SRP) - как их подружить, если по сути есть две ответственности - хранение (дто) и обработка - по СРП - их нужно разнести, т.к. я буду менять класс уже в 2х случаях (когда изменится параметры хранения или изменится обратотка)? Так же если есть пользователь (данные), есть регистрация, по IE - один класс, а если будет ещё логин - туда же, по СРП - здесь будет 3и класса. Или я что-то путаю?
Я немного дополню Сергея. #9:27 - Мы программисты не пророки и не умеем предсказывать будущее, понадобится или нет делить класс на два. НО!!!! Когда пришёл "Петя" за функциональностью для времени, то это и есть звонок остановиться и сделать рефракторинг и разделить классы как требует SRP. И для вменяемого начальника это должно быть достаточной уважительной причиной, чтобы включить это время в проект.
Извините, но вроде бы как Класс должен выполнять не одну какую-то работу, а должен выполнять что-то для одного чего-то или для одной какой-то группы. В книге Роберт Мартин приводил пример с классом Работник в котором обледенили методы работающие с разными отделами внутри их фирмы. И вот как раз по этой причине, что они работают для разных групп, его нужно было разделить. Но сам класс может много чего делать для этой группы.
Пытаюсь разработать уникальную систему диалогов для проекта по типу Baldur's Gate 3 с возможностью добавлять новые "ветки диалогов" по мере написания сюжета, или внесения изменений в структуру (поведение) персонажа. То есть, это будет интерфейс проектирования сюжета, сценария, так и тестирования. А в конечном итоге будет работоспособной, модульной частью, или вшитой (в зависимости от оптимизации (возможно многие функции, типа конструкторов баз данных будут удалены, потому что результаты их работу будут записаны в файловую систему))
Не подумайте что это какая-то претензия, видео отличное, спасибо вам, но немного хромает подача. Много ужимок, запинок и есть оговорки, немного мешает восприятию информации. Как вы правильно сказали, лучше дольше подумать, чем дольше делать, так же и тут, лучше подумать, написать текст и хорошо его выучить, тогда и запинок меньше будет, и подача будет на уровне и хронометраж короче. Еще раз спасибо! С нетерпением жду новых видео!
Скажите пожалуйста насколько принципы SOLID влияют на производительность? Я так понимаю если бы Время и Температура были примитивами то быстрее с ними работать на прямую, не оборачивая в специальные классы. Точно также влияет ли работа через интерфейсы на производительность? Спасибо.
Видео топ. Обращу ваше внимание, товарищи, что мы с вами живём в тот день, когда стаж нашего слуги стал не большим, а ОЧЕНЬ большим!
Ждём видео про "запахи кода".
Поддерживаю, ждём!
Очень
да!
плюс стопицот! очень-очень интересно :)
Smells like teen spirit. It stinks of beer and drugs.
Спасибо за видео. Да, интересно и про SOLID и про ошибки.
Дякую шановний !
Дуже цікавий приклад Ви розглянули.
Геть по іншому сприймав цей принцип.
Насправді, тут можна багато прикладів різних типів класів.
Тонна корисної інфи, варто це обережно пробувати ручками 🤝
Касательно самого принципа, ну я бы немного придрался :)
Все таки SRP также должен учитывать и функциональные требования, особенно это касается когда люди еще любят DRY применять всегда и везде. То что в данный момент некоторые куски кода или некоторые классы у вас выглядят одинаково совсем не значит, что в дальнейшем они будут одинаковы.
SRP больше говорит о том, что причины для изменения одного класса должны лежать только в одной функциональной области. Например, не должно быть так, что один и тот же класс у вас правится, если вам необходимо поменять формат вывода счет фактуры в pdf и правило расчета цен для этой же фактуры. Расчет цен условий - одна функциональная область, вывод документа на печать - другая. Менять один и тот же класс(а тем более метод) в обоих этих случаях - чет хрень какая-то :)
То что вы описали, все таки ближе именно к DRY(ну или очень сильно с ним пересекается), но тут опять такая загвоздка - не всегда код который выглядит одинаково - отвечает за один и тот же функционал с точки зрения бизнес логики. Тогда переиспользование таких классов - это только вред, т.к. рано или поздно(и с очень большой попаболью) придётся эти зависимости разрывать. Да и вообще SRP может быть(и должен) обоснован без упоминания переиспользования как такового, т.к. решает другую проблему - проблему раздутых и god классов. Упоминание переиспользования только добавляет каши и может привести к неверному выводу, что если я не хочу переиспользовать этот функционал где-то еще, то можно его в принципе и не выносить.
Clean Code у Мартина очень спорная книга, большинство пунктов полезные, но есть и прям вредные моменты. Намного более нейтрально и основательно практически 90% пунктов(если не 100) из чистого кода также описаны в Совершенном коде Макконнелла. Не категорично, не безусловно, а скорее как раз так просто описательно. Что они дают и чего помогают достичь. Именно из-за того, что сначала читал Совершенный код, чистый код во многом казался уже вторичным продуктом. При этом намного более грубым в подаче, с невразумительными примерами. При этом в Совершенном коде кроме того что есть у Мартина дана еще куча полезной инфы. Так что я бы брал её и можно, в принципе, больше не читать книг именно касательно качества кодовой базы с точки зрения её организации.
При этом обе книги я бы рекомендовал не сразу прям, а лучше где-то после нескольких месяцев(может даже полгода) работы. Чтобы уже была база и был опыт работы с большими кодовыми базами. Только тогда многие моменты будут понятны, иначе многие пункты просто ни за что не зацепятся(не будет опыта, на основе которого постоянно будет кликать в голове "а вот как это делается" или "блин, и так можно было"). Т.е. сначала немного покопаться, набить пару шишек и потом уже всё это разложить по полочкам. Читать эти книги при прохождении каких-то курсов, когда у вас опыта особо еще нет - трата времени, имхо конечно же. С паттернами "банды 4х" та же история, вообще не понимаю людей, которые эту книгу советуют новичкам. Обычно, когда человек "дорос" до этой книги, он о ней уже сам прекрасно знает :)
А с чем именно не согласны с Мартином, не могли бы в двух словах рассказать?
clean code довольно таки широко принятый подход...вполне можно сказать даже стандарт де факто, по крайней мере когда речь идет об современных ооп языках.
Интересная точка зрения, спасибо за советы!
@@ergo_____3491 Волне возможно, только вот у Матрина такой же перекос, только в сторону длины методов, лишних . Не дай бог метод будет длинным! "Первое правило: Функции должны быть компактными. Второе правило: функции должны быть еще компактнее. Желательно, чтобы длина функции не превышала 20 строк". Не, я не спорю, может на основе его опыта это и так, но возводить это в правило? Или то что заголовочные комментарии javadoc к каждому методу - это трата времени. Абсолютно не упоминая контекст, когда это может быть необходимо для банальной сдачи проекта на поддержку, т.к. это требование было прописано в договоре, что все интерфейсы должны быть задокументированы.
Да и по примерам с кодом есть вопросы. У вас наверняка есть эта книга, посмотрите примеры 6.1 и 6.2. Почему Мартин считает, что пример 6.2 лучше, без вопросов. Что он не раскрывает реализации(хотя это не так, геттеры без проблем раскрывают реализацию. При этом это интерфейс, и мы должны его реализовать, чтобы получить возможность использовать точки. А чтобы его реализовать, нам надо реализовать все методы, а что если они нам не нужны? Тут уже идет явное нарушение принципе YAGNI, зачем в интерфейс зашивать полярные координаты, если в требовании явно говорится что мы будем хранить координаты точки на декартовой плоскости?
В каждой из этих книг есть перекосы, просто в книге Макконнелла они более нейтральны. Там меньше "правил" и "требований" в жестких формулировках. Ну и конечно когда читаешь эти книги надо понимать, что информатику может и можно отнести к точным наукам, но уж не в разрезе прикладного программирования с точки зрения структуры кода. Тут мы ближе к лингвистике. Так что любые советы надо не просто принимать, а анализировать и пропускать через себя и свой опыт. Именно поэтому я читал обе книги, именно поэтому и посоветовал эти книги(какую бы вы ни выбрали) читать уже получив какой-то свой, собственный опыт. Иначе это может превратится в слепое поклонение принципам. Я все эти книги воспринимаю больше как мнение старших товарищей, нежели как правила или требования, которые являются для меня отправной точкой, чтобы не пришлось самому набивать некоторые шишки. Но если в какой-то момент я решу написать метод длиннее 20 строк и мне это будет казаться более разумной идеей, нежели дробление его на 5 других методов - то почему нет?
@@dmitriyobidin6049 Методы должны быть максимально короткими, 1-5 строк идеально. Все остальное - рассадник багов, боль для тех, кто пишет тесты и тех, кто работает с этим кодом в будущем.
круто, продолжайте эту серию, и делайте про другие принципы, наконец-то качественный контент, а не жевание одного и того же много раз.
Спасибо! КОнечно ДА!
п.с. спасибо что всё так подробно объясняете вплоть до "это ромбик", чтобы мы не додумывали и не тупили)
Крутой формат, и видео как раз оптимальной длины
Мне хоть уже и знакомы SOLID принципы, все равно с удовольствием прослушал. Повторение - мать учения.
Определённо нужно больше таких видео!
Огромное спасибо, что записали это видео. Программирование - это великая наука. А интересная просто ЖУТЬ как)))))))))))))))))) Однажды создав маленькую программу данный процесс уже не остановить!!!
13:10 - не, ну чё сразу котики, я вот Немчинского смотрю)
а вдруг он тоже котик?
@@Mr43046721 он лиса
Denis ору)
Спасибо! Очень интересно! Продолжайте про все принципы!
тема определенно интересна, хотелось бы побольше таких видео - коротенько, суть, так сказать. Ведь самое сложное - дойти до простого. Когда большой тутор новичок теряется. Важно сначала понять суть, а потом уже можно вникать в детали. А у Сергея очень хорошая подача, что тоже очень важно
Спасибо за ваше время, если можно больше про принципов.
Сергей, огромное спасибо за видео! Очень подробно и понятно! Вы отлично умеете объяснять
обожаю такие видео, где ты смотришь про то, что используешь - но при этом не знаешь как оно в мире зовется :)
то что здесь рассказывает человек - ну это же "естественные" вещи, ну или меня так учили в 2000-х годах
Побольше таких видео. Здорово получается.
зеленый маркер, на белом фоне, и освещением. почему сразу желтый или белый не взять?
🤣
Это фишка Немчинского, так сказатб.
Постоянно жалуются, что текст не видно.
К чему изменять традициям)
@@furrai Не фишка, а принцип ))
Да всё интересно, всё записывайте!
Ждём продолжения. Молодец Серёга.
Ну наконец-то. Хоть кто-то использует адекватные примеры. А то везде натыкаюсь на примеры, от которых возникает только один вопрос: "как про такую чушь бесполезную столько книг понаписали?"
Теперь хоть понятно, что и так всегда его использовал)
Спасибо
Круто! Спасибо. Самое главное что в подаче материала нет заумных терминов/слов.
Супер! Как же дождаться последнего принципа теперь...
Сергей, благодарю!
Конечно будет интересно послушать про Code Smells
Супер. Ждем все принципы)..
Браво 👍❤ жду продолжения
Спасибо, Сергей. Замечательное дополнение к книге дяди Боба.
5:45 В книге "Чистая архитектура" дядюшка Боб говорит о том, что обычно этот принцип озвучивают про "одну обязанность", но это не совсем верно! Потом он вводит действующее лицо "Пользователь или группа пользователей. Назовем их авторами" и потом дает точную формулировку принципа:
Модуль должен изменяться только из-за одного актора.
Спасибо. Очень познавательно и, главное, понятно.
Ждем про code smells! Спасибо за видео
Спасибо Вам большое) Очень интересно Вас слушать на эти темы. Примерно год назад слушал это видео, но был, как я сейчас понял, даже еще не новичком, а пересматривая сейчас, понимаю, что эти принципы очень даже логичны и даже не осознанно сам так делаю) еще раз спасибо Вам за такие видео, однозначно лайк )
Зашёл чтобы лайкнуть серьёзную тему на канале
Спасибо! Я тоже программист с большим опытом (вероятно, не меньшим, чем у автора), и не то, чтобы меня настигло откровение в этом видео, но ещё разок вспомнить основы, рассказанные с чуть нового угла - всегда полезно и приятно.
Очень информативно, интересно смотреть про паттерны с такой визуализацией, одно пожелание, поменять цвет маркера на черный
Тема очень важна и подача хороша.Ждем скорее продолжения)Спасибо) Еще ,если будет время,интересно послушать о ЛЯМБДА-ВЫРАЖЕНИЯХ и ФУНКЦИОНАЛЬНЫХ ИНТЕРФЕЙСАХ. Еще интересно послушать о классах String Builder и String Buffer. Про многомерные массивы и еще куча всего)))
Ждал это видео от вас, еще не смотрел но уже знаю что все будет на уровне)))
Спасибо за видио! Интересное тема, жду продолжения
Сам я ни сколько не програмист. Но пришлось сделать автоматизацию рутины, которая сберегла кучу времени и нервов целому коллективу преподавателей. Писал в vba. Часть кода записал с помощью рикодера ворда, часть нагуглил в рунете. Вот тогда я интуитивно стал понимать что я столкнулся с проблемой правильной декомпозиции, а также создания правильных "классов". То есть коды на отдельные операции я где-то нагуглил, а где-то записал с помощью рикодера и изначально привязывал их к соответствующим горячим клавишам, с помощью которых их последовательно запускал. Но с увеличением количества таких макросов, запуск этих команд также стала превращаться в рутину. И меня осенило, что я их могу объеденить по определенным блокам, в зависимости от очередности исполнения кода. Я объединял их с помощью другого vba кода. И привязал исполнение всего кода лишь к одной комбинации горячей клавиши. Самое главное, этот макрос я мог переносить на любой пк, где после минутной настройки он становился рабочим и им мог пользоваться лбой юзер.
спасибо за примеры и видео!
Запишите, пожалуйста еще про dry kiss yagni, вот что еще бы хотелось)) вот шаг до идеала)
DRY - Повторяется код? Выносим за "скобки" )
KISS - Чем проще код, тем проще его поддерживать.
YAGNI - Всё что не нужно и не используется, выбросить.)
👨💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 ruclips.net/video/NnM1Od1TKdA/видео.html
Здравствуйте, а вы сами придумали этот пример или из книги взяли?
Я просто другие примеры читал, и вот после многочисленных споров по пониманию SRP нашел видео где Мартин 50 минут про него говорит.
Линк - ruclips.net/video/Gt0M_OHKhQE/видео.html (с привязкой ко времени, в которое он дает определение).
Главное в SRP, на сколько я понял - это то, чтобы модуль обслуживал одного актора (роль, группа пользователей), для решений задач которых и создан модуль.
Дело о человеке, о той роли что он выполняет. Этот принцип чуть выше того что один метод должен выполнять что то одно.
Например - у нас сайт с продажей видеокасет. По SRP у нас должны быть разные контроллеры, разные сервисы для Админа и Кастомера. Разные модули, для разных ролей. Изменяем Админку, не затрагиваем Кастомера и наоборот. Ну и внутри подроли - просматривающий отчет, ДБ администратор и т.п. Тут я сам не всегда понимаю где отличие от простого разбиение на функции. И получается что общий код (общий сервис, где то в глубине) может быть в общем модуле, но как только появляются отличия, код нужно разносить по разным модулям, каждый под свою роль, этот вопрос не очень раскрыт.
Спасибо за видео. Приведите, пожалуйста, пару примеров из практики, где нарушался принцип SRP, к чему это привело и как вы это исправили.
Всё интересно! Всё делайте!
Поздравляю с новой камерой, отличная картинка! И вижу повышаете качество не только в картинке но и в умении заинтересовать новичков)) Хитрый Немчинский называет кучу новых терминов и ребята сразу начинают думать, ого как мало я знаю и как много неизвестных слов еще предстоит узнать))
вот эти все новые термины только уводят от главной темы. весь фокус объяснения сбивается
Так спокойно и размеренно все объясняешь. Хоть для медитации включай)
Спасибо) это интересно и про code smells тоже было бы интересно послушать)
Видео хорошее, я хотел бы увидеть больше подобных видео
Очень интересная тема!
Спасибо, ждём продолжения
Очень интересное видео. Да, хотелось бы ещё цикл видео про рефакторинг.
Огромное спасибо! Послушать бы ещё про репозитории чтения/записи, потому-что каждый крутит их как хочет, и суёт и чтение и запись в один репозиторий...
Было-бы классно услышать мнение опытного человека
Спасибо! Именно с этим принципом у меня проблем не было, но всё равно интересно. А вот про другие принципы было бы хорошо послушать
Запах кода очень интересно)
Крутой формат. Спасибо за инфу!
Большое спасибо! Даже при условии прочтения о SOLID в книге "Чиста архитектура", интересно послушать, как это воспринимает профессиональный разработчик.
Было бы интересно в кратце узнать о "Аспектно ориентированном программировании" и какие задачи оно решает на реальных проектах.
Ещё раз огромное спасибо за Ваш труд.
Ураааааааа))))Спасибо, дождались наконец-то)
Хорошая серия. Интересно про Лисков послушать :)
спасибо за видео
Про котиків і соцмережі- це ваще крутяк. Сміюся)))
Супер! Продолжайте
Сергей, спасибо огромное.
Если будет возможность, пожалуйста выпустите серию роликов про запахи кода (и рефакторинг вообще).
Дичайше интересно, спасибо!
Отличное оюъяснение
Интересно про запах кода послушать.
супер, хороший разбор
Давайте про code smells тоже. Ну и про остальные принципы.
Супер! Все по делу.
Слышу я такой про active record, что так делать не надо и понимаю (о! а это оказывается шаблон такой есть! не знал, любовь к велосипедам с детства даёт о себе знать наверное), что я так делаю почти постоянно, ставлю на паузу, лезу в код, прикидываю, как исправить ситуцаию, начинаю набрасывать каркас решения, снимаю с паузы и ... "В энетепрайзе это нормально, многие так делают, хотя это и нарушает srp". Занавес.
Очень интересно! А еще интересно про вонючий код ))))
Кто-нибудь знает как его зовут? Эта конфиденциальность невыносима уже
А разве не Сергей?
Поправочка на счет ORM, AR это тоже ORM.
И фактически основных подхода к построению ORM существует два: AR и Data mapper.
Нет, если верить Фаулеру, это разные паттерны. И для построения дао слоя их больше. Приходите на тренинг по энтерпрайз паттернам
Доброго времени суток, было очень интересно. Хотелось бы серию насчёт паттернов программирования. Думаю, всем будет интересно.
Спасибо вам за ваше видео!
@Sergey скажите, интересует вопрос связи грасп-паттерна информ.эксперт (IE) и текущего(SRP) - как их подружить, если по сути есть две ответственности - хранение (дто) и обработка - по СРП - их нужно разнести, т.к. я буду менять класс уже в 2х случаях (когда изменится параметры хранения или изменится обратотка)? Так же если есть пользователь (данные), есть регистрация, по IE - один класс, а если будет ещё логин - туда же, по СРП - здесь будет 3и класса.
Или я что-то путаю?
Спасибо, очень интересно и очень нужно!
Видео отличное!
Но как же грустно смотреть на вашу футболку 😢
Про S.O.L.I.D очень интересно и желательно видосы подлиннее и с примерами.
Спасибо
👍Well done!
Не знал что есть люди пользующиеся фломастерами, а то думал что тут что-то полезное.
оо круто очень хоу тренинг про энтерпрайз патерны.
Тема крутая, спасибо
На полном серьезе предполагается, что те кто не знаком с солид знают что такое актив рекорд? :)
Я немного дополню Сергея. #9:27 - Мы программисты не пророки и не умеем предсказывать будущее, понадобится или нет делить класс на два. НО!!!! Когда пришёл "Петя" за функциональностью для времени, то это и есть звонок остановиться и сделать рефракторинг и разделить классы как требует SRP. И для вменяемого начальника это должно быть достаточной уважительной причиной, чтобы включить это время в проект.
Извините, но вроде бы как Класс должен выполнять не одну какую-то работу, а должен выполнять что-то для одного чего-то или для одной какой-то группы. В книге Роберт Мартин приводил пример с классом Работник в котором обледенили методы работающие с разными отделами внутри их фирмы. И вот как раз по этой причине, что они работают для разных групп, его нужно было разделить. Но сам класс может много чего делать для этой группы.
Ааа, ты лучший, огромное спасибо!!!
Да, хорошо бы про запахи кода
Интересно про code smells
Ух, уже жду историю как появился принцип Барбары Лисков
Пытаюсь разработать уникальную систему диалогов для проекта по типу Baldur's Gate 3 с возможностью добавлять новые "ветки диалогов" по мере написания сюжета, или внесения изменений в структуру (поведение) персонажа.
То есть, это будет интерфейс проектирования сюжета, сценария, так и тестирования. А в конечном итоге будет работоспособной, модульной частью, или вшитой (в зависимости от оптимизации (возможно многие функции, типа конструкторов баз данных будут удалены, потому что результаты их работу будут записаны в файловую систему))
Спасибо, познавательно, продолжайте :)
класс! про всё это надо рассказывать,и поуглублённей!
если 15 минут для Вас много, делите пожалуйста, мы не против. хотя они пролетели.. ИМХО
Не подумайте что это какая-то претензия, видео отличное, спасибо вам, но немного хромает подача. Много ужимок, запинок и есть оговорки, немного мешает восприятию информации. Как вы правильно сказали, лучше дольше подумать, чем дольше делать, так же и тут, лучше подумать, написать текст и хорошо его выучить, тогда и запинок меньше будет, и подача будет на уровне и хронометраж короче.
Еще раз спасибо! С нетерпением жду новых видео!
интересно полезно 👍
видео топ! еще бы научиться, как вы говорите, продумывать структуру перед началом работы, это значительно упростило бы жизнь...
лучше наоборот - сначала написать как пришло в голову, а потом - рефакторить в нужном направлении. Так советуют все столпы
Скажите пожалуйста насколько принципы SOLID влияют на производительность? Я так понимаю если бы Время и Температура были примитивами то быстрее с ними работать на прямую, не оборачивая в специальные классы. Точно также влияет ли работа через интерфейсы на производительность?
Спасибо.