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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

спасибо!

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

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

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

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

Спасибо)

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

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

спасибо

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

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

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

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

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

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

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

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

Полезно

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

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

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

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

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

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

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

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

Вы лучший

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слушать надо не соера, а уан лоун кодэра(one lone coder)

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

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

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

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

По архитектуре нужен курс лекций, а не просто пару видео

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

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

Я испытываю нехватку знаний по архитектуре.

Принцип единственной ответственности не про единственную ответственность, а про зависимость от одного актора и не совпадает с high cohesion. А в целом норм😅

Не хера не понимаю, но мне очень интересно.

Soer ты самый зрелый и адекватный из всех IT-ютуберов; хотя было время я смотрел инфоцыган типа winderton, каюсь

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

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

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

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

Более подробно о Grasp и о многом другом мне понравилось в курсе Немчинского: ru-vid.com/group/PLmqFxxywkatStbd9hdzVOS1hZa9dc56k4

качество видео все выше и выше