G.R.A.S.P | шаблоны проектирования

[@maxfolch]

Архитектура очень интересна, чем больше видео будет - тем лучше ! Спасибо !

[@vitprof]

С моей точки зрения важно понимать какому уровню абстракции принадлежат описываемые паттерны. Если паттерны Банды Четырех применяются непосредственно при написании кода (его структурировании), то паттерны GRASP относятся к более высокому уровню абстракции (архитектурные паттерны), так же как и принципы SOLID. Использование паттернов для разработчиков - не плодить сложные абстракции и не изобретать велосипеды. Несмотря на то, что ООП позволяет реализовывать сложные проекты, он довольно сложный и не совсем естественный. Очень часто разработчики переусердствуют в придумывании ненужных абстракций. Всю эту концепцию еще важно дополнить принципом Бритвы Оккама.

[@serhiis_]

где вы были когда sun писали java 6? throws в каждом методе сдк - хватит это терпеть!

[@Pitometsu]

Проблема паттернов в ООП. Проблема ООП в том, что это _несколько_ техник воспринимаемых как одна, некоторые из которых, строго говоря, анти-паттерны. Хорошая статья по теме: medium.com/@stephenebly/an-introduction-to-existential-types-25c130ba61a4

[@kandreyk9159]

@@Pitometsu проблема паттернов в том, что помогая в решении одних проблем, они порождают другие проблемы, требующие новых паттернов...

[@AndriiKuftachov]

ООП - это абстракция, которая не соответствует современным веб-симтемам. По сути, люди просто объединяют какие-то данные с методами в классы, но это совсем не то. Например, Контроллер - это просто набор методов. Дальше, если Модель не анемичная, то ни все равно её не хватит и придется использовать сервисы. Мыслить категориями объекта хорошо тогда, когда реально моделируем поведение объекта, например, UI или в играх.

[@aliorunity]

Я бы еще добавил YAGNI и KISS

[@vzzzk]

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

[@zultulce]

Согласен, я думал, что голова лопнет от понимания. Со скрипом по книгам проходит, мало демонстрации, а то, что встречается в видео, то это как хауди - за час java, за час php и прочая херня!

[@ПавелКуликов-и3м]

а не надо строить систему на паттернах, их нужно применять только когда возникает проблема в проектировании (нарушение принципов и тд)

[@NookeSt]

Было бы интересно про иерархию шаблонов, принципов проектирования. Как пересекаются, какие взаимосвязи.

[@lavcoder]

Сделай видео про CQRS. Кто за, ставь лайк!

[@Pitometsu]

И про кеширование. И про event sourcing до кучи!

[@__alexfox__]

Очень интересная тема. Несколько раз переслушивал ролик! Пожалуйста, больше!!!

[@Pitometsu]

Спасибо большое. Прекрасно разделение принципов проектирования и паттернов, т.к. первые ложатся не только на ООП, но и на структурное, модульное, и функциональное программирование, помогая проектировать грамотный DSL и повышая переиспользование, и упрошая поддержку. Хотелось бы послушать о распределенных архитектурах, если будет желание о них рассказать, например.

[@goliafffff]

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

[@ЮраГайдучик-э4о]

Архитектура интересна!) Спасибо за видео. Хочется больше видео по DDD, принципы, слои, примеры реализации.

[@drVatman]

Было бы интересно увидеть ваш список проектов с открытым исходным кодом, которые вы рекомендуете как примеры хорошей архитектуры. Чем больше и разноплановее тем лучше.

[@lavcoder]

Сделай видео про микросервисную архитектуру. Кто за, ставь лайк!

[@Pitometsu]

Особенно о том, как решать проблему переиспользование кода. И как делать CI/CD и версионирование всего этого добра с поддержанием консистентности.

[@omgoood]

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

[@АндрейРеш-г9в]

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

[@TimothyNazar]

Среди всех призывов коментировать только это видео смотивировало :) Очень буду ждать видео на тему: "Проектирования приложений - основные подходы" или в формате потенциальных вопросов которые ты бы задал кандидату на позицыю архитекта.

[@RobinGoodwe872]

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

[@Василий-е2ш4щ]

Отличная лекция, спать не хочется, очень интересно

[@AAAGaming69]

Видео супер, как всегда! Очень хотелось бы послушать про этапы проектирования архитектуры

[@AntiPolarity]

Поддерживаю архитектурные видосы!

[@МедведьСтранник]

Спасибо за ролик. Тема актуальная. Как по мне, будет интересно обозначать проблему, а затем выдвигать архитектурное решение. Тогда, паттерны будут к чему-то привязаны и в голове что-то отложится. Думаю, имеет смысл рассматривать [не все подряд] шаблоны из разных групп: паттерны банды четырёх, паттерны DDD, шаблоны микросервисного взаимодействия

[@dmitrypichugin7449]

Я из GRASP запомнил только 6 из 9 шаблонов. Другие это полный клон SOLID, или очень похожие. Для себя выделил приблизительно такие ключевые определения: 1) Информационный эксперт - владелец знаний, сами их обрабатывает. 2) Креатор - создает объекты тот кто обладает всей необходимой для этого информацией, чаще других их использует и/или агрегирует в себе. (аналог фабричного метода и абстрактрой фабрики) 3) Контроллер - отделяет UI от логики приложения. 4) ЛоуКоплин - классы должны быть как можно меньше связаны между собой, и знать о внутреннем устройстве друг друга. 5) ХайКохесин - класс должен выполнять только ту работу для которой он создан, например класс работающий с сетью должен работать только с сетью и ничего больше. (и это не S из SOLID, там речь про акторов (групп пользователей)) 6) ПьюрФабрикейшн - это когда в программной реализации используются понятия не существующие в предметной области, например - репозитории и БД. Нужно для удовлетворения другим шаблонам. Например, следуя шаблону информационный эксперт, класс сам бы сохранял себя в БД, но это не круто, поэтому и ORM etc. Чем больше шаблонов, тем больше связей между ними.

[@savalex1990]

Давайте больше архитектуры. Это очень востребовано.

[@ziyadseykhanov3967]

02:08 Уже больше 3000 лайков. ))

[@TimurSevimli]

:)

[@PoletaevRoman]

Про архитектуру очень интересно

[@voothi]

Очень интересная тема, спасибо! Стало понятно как связаны подходы

[@fpv_am]

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

[@terminakter]

Было бы интересно посмотреть про архитектуру баз данных, как лучше всего хранить/считывать/заполнять через встроенные функции СУБД данные, чтобы не было проблем в будущем. Например в тематике бронирование времени

[@LeonwPRO]

Хочу узнать всё что только можно об архитектуре. Прям сложно определиться что выбрать. Отличная тема! Спасибо

[@pavelnemoi]

Спасибо вам за контент! Архитектура скорей всего интересна почти всем, думаю видео в этом направлении будут пользоваться спросом большой аудитории. Хотелось бы послушать ваше мнение о практической реализации конкретной архитектуры приложения в проекте, к примеру, Onion или Hexagonal, CQRS architecture. Важности знакомства с ней разработчиков и объяснения основных принципов.

[@egordoynikov8597]

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

[@Freddis]

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

[@MrBivanovs]

лучшее объяснение без воды

[@ИванНикитин-ч7б]

Интересует слоистая архитектура мелких переходящих в средние программ. То есть, подробный пристальный архитектурный разбор, в какой последовательности происходит проектирование разных слоёв программы. Как грамотно и полно спроектировать архитектуру и внутренний дизайн мелкой/средней программы до этапа написания кода.

[@cffee_]

Интересует MVVM vs MVC

[@arsenykonohov]

low coupling high cohesion - низкая связь высокая связность (google translate). Возможно лучший перевод мог бы быть "Низкая связанность (с внешним) высокая концентрация (на задаче)" чисто по контексту задачи этого патерна.

[@sovrinfo]

Спасибо за видео.Коммент в поддержку!

[@АленаЕршова-ъ5ю]

супер, очень интересное и понятное объяснение!

[@Mike-hp3fh]

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

[@timofey9052]

4:32, низкое зацепление и высокая связность, наоборот должно быть. А, у вас зацепление и связность перепутаны

[@popuzin]

Архитектура интересна. Продолжайте пожалуйста :)

[@slavanslavan9330]

Низкая связанность (Low Coupling) и Высокое зацепление (High Cohesion), а не наоборот же

[@batyr71]

Пожалуйста, по архитектуре побольше. 👍👏

[@petrplotnikov4307]

не совсем понятно как определить что должно быть в моделе, как определить что относится к бизнес логике?

[@NadChel1]

Отличное видео, спасибо!

[@VYACHESLAVx]

Спасибо)

[@4Funoff]

Уже почти три тысячи лайков 😊 ждём продолжения!! Видео классное, благодарю!!

[@caffeinejavacode1475]

как рекомендуете попрактиковать чтоб их лучше понять?

[@Richard___52]

I hope you're grinning all the way.

[@mikhaildiesperov2345]

Ну конечно нужны такие видео. Нужны такие выжимки.

[@ЕвгенийБабурин-х5х]

приятный паарень, голос тоже. Я открыл видео поскольку искал конкретный пример на GRASP контроллер и этого мне и не хватило :(

[@madmad7201]

Здравствуйте:) О GRASP толком ничего не слышал, но очень интересно

[@only_noma]

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

[@0imax]

Интересный взгляд. Но мне больше нравится объяснение от Немчинского.

[@танунахепта]

Пока что я понимаю так, качественные источники можно связать головой. Это про то что в конце видео.

[@chu_ri5470]

Да да да, архитектура. Хочу хочу хочу. Да видео вышло год назад, но архитектура.... Я её чувствую. Она нужна мне.

[@ajajapenoflex]

Устойчивость к изменениям разве не относится к принципу открытости\закрытости?

[@S0ERDEVS]

Это один из вариантов реализации.

[@ЕгорТвердохлеб-й2р]

круто изложили инфу! приспект!

[@MelineWald]

Спасибо за такое хорошее обьяснение

[@himyl13]

Привет! Меня вот мучает такая проблема в архитектуре, что не всегда понятно, стоит независимую логическую задачу выносить в модули или контроллеры. Я стараюсь сделать так, чтобы ни один модуль не зависел от другого и с ними работали только контроллеры, но встаёт ситуация, что типичная операция должна включать в себя несколько процессов и.. тут дилемма в каком виде лучше организовать не создавая зависимости.

[@itcloudguy]

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

[@spathochu]

спасибо!

[@mamkinproger]

увидел видео. думаю, о сейчас посмотрю кое-что для себя полезное(я начинающий). в ходе просмотра понял, что пока ничего не понял - отложил на время до лучших времен. А так, спасибо за полезный контент!

[@user-friendhors]

какой умный человек!! спасибо за ценную информацию!!!

[@xabikiqwe]

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

[@mutniytip2000]

Мне в принципе очень интересна тема архитектуры, не имею большого опыта в программировании, и хочу знать все и обо всем)

[@Cleannetcode]

Очень интересует данное направление. Хотелось бы послушать ваше мнение: - чем отличается архитектор от проектировщика? - может ли заказчик влиять напрямую на проектно/архитектурное решение или все такие за это должен полностью отвечать разработчик? - на каких этапах роста проекта стоит делать ревью проекта?

[@davidapk323]

спасибо

[@tanyagibadulina8809]

Хорошо рассказано

[@alexeyveseliev106]

Лайкаем, лайкаем!!!

[@Lisa___9c]

Several stories of empty rooms rewarded their search, but nothing more; so after a time they came back to the platform again.

[@vasilys9776]

Годно, пили ещё в том же ключе

[@АркадийПотапов-з9т]

Ничего не понял, но очень интересно!

[@user-QesOrwuMqN]

Расскажи что знаешь по DDD

[@atlasua2021]

DDO?

[@user-QesOrwuMqN]

@@atlasua2021 domain driven design (DDD)

[@EugenBatmanoff]

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

[@InkeriLantieri]

An insider's perspective: exclusive interview with Binance's CEO on future developments

[@monoteiz]

Расскажи про ИИ

[@ifastenko]

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

[@AndriiKuftachov]

Это ты ещё про Go не знаешь 😉

[@ДжонСноу-я8э]

грамотный мужик, лайк

[@maksimsergeevich5939]

Посоветуйте пожалуйста лекции или выступления где также хорошо рассказывают про построение просто больших программ: 1000,10000,100000 строчек кода. Потому что, пока, я это воспринимаю как искусство: не утонуть в объеме кода который ты сам написал. Ведь с увеличением программы неизбежно увеличивается связанность кода даже если ты стараешься ее избежать. Как писать большую программу так чтобы она не превращалась в лапшу из гoвнокода с увеличением объема?

[@dmitriy1129]

Для начала, С ДНЁМ ПРОГРАММИСТА!А по делу: GRASP, SOLID и т.д. по факту не имеют принципиальной разницы

[@qdexy]

Архитектура это самое сложное для меня

[@mihaelvetkin3257]

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

[@ДанилПархоменко-й5я]

где купить такие очки ?

[@Nerossoul]

Полезно

[@tinkerbel1955]

Как уже отметили в комментах, о том что хотелось бы увидеть сам ход мыслей при выборе паттерна.. что-то вроде: "я собираюсь подобрать паттерн для X проекта, и найболее подходящие кандидаты на роль паттерна конкретно этому проекту: паттерны 1 два и три (а причины почему именно они это ... и т.к. 1 и 2ой паттерн довольно так похожие в.. но..)... НО я остановлю свой выбор на втором паттерне, по целому ряду причин.. А так же взглянув на опыт проектировщиков, таких сервисов как * * *, можно понять что мой выбор не является ошибочным."

[@andreykhalepov8260]

По построению архитектуры очень мало информации в интернете. Было бы здорово

[@didexdida1697]

Как визуализировать архитектуру проекта?

[@valentinkhomutenko6308]

UML диаграммы

[@nikshadow92]

Будет бомба если этот мужик разжует Liskov principe, мда, SOLID много где спрашивают)

[@НикитаГлухов-п5ю]

А че его разжевывать, он простой как пробка на практике, так как там есть конкретные определения, тот принцип "единственной ответственности" гораздо более абстрактный и понимаемый скорее интуитивно. Принцип подстановки Лисков - подкласс должен дополнять контракт родителя, а не замещать его (т.е. предусловия нельзя усилять, постусловия - ослаблять, инварианты класса нужно сохранять). Вот и всё.

[@nikshadow92]

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

[@eleimt]

Видео том, как SaaS поддерживать для пользователей. Как вносить изменение для каких-то клиентов, и как это поддерживать.

[@cultofsogga5863]

Кому помогло в жизни употребление и курение грибов???

[@maratimus]

Я хочу начать микродозить через день псило - сила, в долине многие коддеры юзают

[@karim4046]

Что оно даст на практике?

[@Skellag]

@@karim4046 +1-го торчка через лет 5

[@freestailist]

Сними пожалуйста про работу с данными в ангуляре, используешь сторы (если есть опыт использования сторов на реальных проектах, то плюсы и минусы их), сервисы или все в компонентах хранится, плюсы и минусы данных подходов

[@RezetRoy]

сторы от лукавого (мода)

[@NecroRomnt]

Нахожусь на позиции middle fullstack developer. Постоянно ощущаю нехватку знаний об архитектурных подходов, но наибольшие сложности появляются когда пытаюсь применить неосвоенный подход. Часто получается нелепо и требуется время на причёсывание кода, а времени, естественно, нет.

[@sergeyintegral451]

Было бы интересно послушать про саги.

[@Mark___551x]

Taking it one step at a time-refund details and expected actions

[@ILMIRazmach]

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

[@Termonna]

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

[@xelaksal6690]

Как вообще к ней подступиться?(я про архитектуру)

[@dmitryb530]

И где супер ПО написанное по всем этим правилам??

[@JaroslavNesterov]

ты сибирский из будущего?

[@nikshadow92]

Помнишь все GoF? Не забывай про KISS )

[@Ren-z5m3t]

Лучше слова подкреплять текстом, а не мимикой. Но зашло. Спасибо

[@vll1976]

"В MVC framewёrках" - оговорка по Фрейду, что называется...

[@МедведьСтранник]

Что ты хочешь этим сказать - типа, фрэймворк не может базироваться на паттерне MVC?

[@blackgolddev4023]

Вы лучший