G.R.A.S.P | шаблоны проектирования
Vložit
- čas přidán 10. 09. 2019
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwareengineervlog
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/id/5f578bdf22e2...
GitHub - github.com/soerdev
Чат для программистов - / discord
Группа ВК - codeartblog
Архитектура очень интересна, чем больше видео будет - тем лучше ! Спасибо !
С моей точки зрения важно понимать какому уровню абстракции принадлежат описываемые паттерны. Если паттерны Банды Четырех применяются непосредственно при написании кода (его структурировании), то паттерны GRASP относятся к более высокому уровню абстракции (архитектурные паттерны), так же как и принципы SOLID. Использование паттернов для разработчиков - не плодить сложные абстракции и не изобретать велосипеды. Несмотря на то, что ООП позволяет реализовывать сложные проекты, он довольно сложный и не совсем естественный. Очень часто разработчики переусердствуют в придумывании ненужных абстракций. Всю эту концепцию еще важно дополнить принципом Бритвы Оккама.
где вы были когда sun писали java 6? throws в каждом методе сдк - хватит это терпеть!
Проблема паттернов в ООП. Проблема ООП в том, что это _несколько_ техник воспринимаемых как одна, некоторые из которых, строго говоря, анти-паттерны.
Хорошая статья по теме: medium.com/@stephenebly/an-introduction-to-existential-types-25c130ba61a4
@@Pitometsu проблема паттернов в том, что помогая в решении одних проблем, они порождают другие проблемы, требующие новых паттернов...
ООП - это абстракция, которая не соответствует современным веб-симтемам.
По сути, люди просто объединяют какие-то данные с методами в классы, но это совсем не то.
Например, Контроллер - это просто набор методов.
Дальше, если Модель не анемичная, то ни все равно её не хватит и придется использовать сервисы.
Мыслить категориями объекта хорошо тогда, когда реально моделируем поведение объекта, например, UI или в играх.
Я бы еще добавил YAGNI и KISS
Очень интересная тема. Несколько раз переслушивал ролик! Пожалуйста, больше!!!
Вот очень правильно сказал. В сети до фига теории, с пояснениями, простейшими примерами и т.п. Но как только дело доходит до практики, конкретной задачи, то начинаются трудности с применением этих знаний. Зачастую совершенно непонятно, на каком паттерне/принципе/шаблоне построить ту или иную часть системы. Хотелось бы увидеть больше видео с демонстрацией применения теории на конкретных задачах. Не так важно каких именно принципов и на каких языках/технологиях. Важнее понять ход мысли при проектировании.
Согласен, я думал, что голова лопнет от понимания. Со скрипом по книгам проходит, мало демонстрации, а то, что встречается в видео, то это как хауди - за час java, за час php и прочая херня!
а не надо строить систему на паттернах, их нужно применять только когда возникает проблема в проектировании (нарушение принципов и тд)
Очень интересная тема, спасибо! Стало понятно как связаны подходы
Архитектура интересна!) Спасибо за видео. Хочется больше видео по DDD, принципы, слои, примеры реализации.
Отличная лекция, спать не хочется, очень интересно
Спасибо большое. Прекрасно разделение принципов проектирования и паттернов, т.к. первые ложатся не только на ООП, но и на структурное, модульное, и функциональное программирование, помогая проектировать грамотный DSL и повышая переиспользование, и упрошая поддержку.
Хотелось бы послушать о распределенных архитектурах, если будет желание о них рассказать, например.
Видео супер, как всегда! Очень хотелось бы послушать про этапы проектирования архитектуры
супер, очень интересное и понятное объяснение!
Сделай видео про CQRS. Кто за, ставь лайк!
И про кеширование. И про event sourcing до кучи!
Тема архитектуры приложения очень интересна, с удовольствием посмотрю об этом видео.
Было бы интересно про иерархию шаблонов, принципов проектирования. Как пересекаются, какие взаимосвязи.
Отличное видео, спасибо!
Уже почти три тысячи лайков 😊 ждём продолжения!! Видео классное, благодарю!!
Да. Просто нужное. Нужно. И Вы очень интересный Чел. Пробую на ходу. Обязательно сообщу - что нужно и как это классно. Сама подборка видео по архитектуре -какая то очень-очень творческая и хорошая.
Как же круто что я понимаю это, и вспоминаю реальные примеры из реальных проектов, хоть и кажется вчера ничего не знал о программировании, так что программирование это действительно просто, по крайней мере бэкэнд архитектура.
Среди всех призывов коментировать только это видео смотивировало :)
Очень буду ждать видео на тему: "Проектирования приложений - основные подходы" или в формате потенциальных вопросов которые ты бы задал кандидату на позицыю архитекта.
лучшее объяснение без воды
Спасибо за такое хорошее обьяснение
Архитектура интересна. Продолжайте пожалуйста :)
спасибо!
Поддерживаю архитектурные видосы!
Наверное, необходим обзор архитектур. Где на практике какие подходы применяются, а затем рассматривать отдельно.
Годно, пили ещё в том же ключе
Спасибо за видео.Коммент в поддержку!
Было бы интересно увидеть ваш список проектов с открытым исходным кодом, которые вы рекомендуете как примеры хорошей архитектуры. Чем больше и разноплановее тем лучше.
Хорошо рассказано
Спасибо)
Спасибо за ролик. Тема актуальная. Как по мне, будет интересно обозначать проблему, а затем выдвигать архитектурное решение. Тогда, паттерны будут к чему-то привязаны и в голове что-то отложится. Думаю, имеет смысл рассматривать [не все подряд] шаблоны из разных групп: паттерны банды четырёх, паттерны DDD, шаблоны микросервисного взаимодействия
Сделай видео про микросервисную архитектуру. Кто за, ставь лайк!
Особенно о том, как решать проблему переиспользование кода. И как делать CI/CD и версионирование всего этого добра с поддержанием консистентности.
Да забейте, без нормального штата не вытянуть микросервисную архитектуру. А все видео чисто абстрактные
спасибо
I hope you're grinning all the way.
Про архитектуру очень интересно
круто изложили инфу! приспект!
Было бы интересно посмотреть про архитектуру баз данных, как лучше всего хранить/считывать/заполнять через встроенные функции СУБД данные, чтобы не было проблем в будущем. Например в тематике бронирование времени
увидел видео. думаю, о сейчас посмотрю кое-что для себя полезное(я начинающий). в ходе просмотра понял, что пока ничего не понял - отложил на время до лучших времен. А так, спасибо за полезный контент!
Хочу узнать всё что только можно об архитектуре. Прям сложно определиться что выбрать. Отличная тема! Спасибо
Давайте больше архитектуры. Это очень востребовано.
Лайкаем, лайкаем!!!
Здравствуйте:)
О GRASP толком ничего не слышал, но очень интересно
Полезно
Спасибо вам за контент! Архитектура скорей всего интересна почти всем, думаю видео в этом направлении будут пользоваться спросом большой аудитории. Хотелось бы послушать ваше мнение о практической реализации конкретной архитектуры приложения в проекте, к примеру, Onion или Hexagonal, CQRS architecture. Важности знакомства с ней разработчиков и объяснения основных принципов.
грамотный мужик, лайк
Пожалуйста, по архитектуре побольше. 👍👏
Вы лучший
low coupling high cohesion - низкая связь высокая связность (google translate).
Возможно лучший перевод мог бы быть "Низкая связанность (с внешним) высокая концентрация (на задаче)"
чисто по контексту задачи этого патерна.
Several stories of empty rooms rewarded their search, but nothing more; so after a time they came back to the platform again.
Интересный взгляд. Но мне больше нравится объяснение от Немчинского.
Да, видео по архитектуре нужны, так как у меня, лично, с этим есть пробелы. Будет здорово получить еще какое-то поле для размышлений.
приятный паарень, голос тоже. Я открыл видео поскольку искал конкретный пример на GRASP контроллер и этого мне и не хватило :(
Я из GRASP запомнил только 6 из 9 шаблонов. Другие это полный клон SOLID, или очень похожие.
Для себя выделил приблизительно такие ключевые определения:
1) Информационный эксперт - владелец знаний, сами их обрабатывает.
2) Креатор - создает объекты тот кто обладает всей необходимой для этого информацией, чаще других их использует и/или агрегирует в себе. (аналог фабричного метода и абстрактрой фабрики)
3) Контроллер - отделяет UI от логики приложения.
4) ЛоуКоплин - классы должны быть как можно меньше связаны между собой, и знать о внутреннем устройстве друг друга.
5) ХайКохесин - класс должен выполнять только ту работу для которой он создан, например класс работающий с сетью должен работать только с сетью и ничего больше. (и это не S из SOLID, там речь про акторов (групп пользователей))
6) ПьюрФабрикейшн - это когда в программной реализации используются понятия не существующие в предметной области, например - репозитории и БД. Нужно для удовлетворения другим шаблонам. Например, следуя шаблону информационный эксперт, класс сам бы сохранял себя в БД, но это не круто, поэтому и ORM etc.
Чем больше шаблонов, тем больше связей между ними.
Мне в принципе очень интересна тема архитектуры, не имею большого опыта в программировании, и хочу знать все и обо всем)
Ну конечно нужны такие видео. Нужны такие выжимки.
Отличное видео, очень своевременно, т.к. злобные собеседователи уже лупят сложные вопросы по паттернам уже для ранних мидлов ( говорю про свой опыт Java дева). А в этих паттернах всё весьма запутано и абстрактно.
Пока что я понимаю так, качественные источники можно связать головой. Это про то что в конце видео.
Для начала, С ДНЁМ ПРОГРАММИСТА!А по делу: GRASP, SOLID и т.д. по факту не имеют принципиальной разницы
Да да да, архитектура. Хочу хочу хочу.
Да видео вышло год назад, но архитектура.... Я её чувствую. Она нужна мне.
Было бы интересно послушать про саги.
Ничего не понял, но очень интересно!
4:32, низкое зацепление и высокая связность, наоборот должно быть. А, у вас зацепление и связность перепутаны
Интересует слоистая архитектура мелких переходящих в средние программ. То есть, подробный пристальный архитектурный разбор, в какой последовательности происходит проектирование разных слоёв программы. Как грамотно и полно спроектировать архитектуру и внутренний дизайн мелкой/средней программы до этапа написания кода.
02:08 Уже больше 3000 лайков. ))
:)
Интересует MVVM vs MVC
Мне интересна какая-то систематизация архитектурных решений и базовый фундамент. Пока для меня многие шаблоны проектирования как склад инструментов которые непонятно как и где использоватиь и с чего вообще начинать разработку приложения.
Для себя я выделил следующие фундаментальные принципы:
* Модульность.
* Один модуль - одна ответственность.
* Продуманные интерфейсы модулей. Они должны быть как можно меньше и как можно более функциональны. При этом не так важно как реализованы сами модули, их потом можно переписать или связать с этим интерфейсом другие модули
* Предпочитать стандартные интерфейсы, т.к. они проверены на практике и дают возможность легко подключать свои модули к другим, которые тоже придерживаются стандартов.
* Минимальная зависимость модулей друг от друга. Лучше перенести в модуль какой-то небольшой код из другого модуля, чем зависеть от него целиком.
* Универсальность модулей. Модуль должен как можно полнее охватывать спектр задач из области своей ответственности.
* Простота модуля. Чем меньше кода - тем лучше.
Модулями могут быть классы, функции, наборы связанных классов, компоненты, и пр.
Самый главный принцип - это продуманые интерфейсы, которые разработать довольно сложно.
спасибо! могли бы вы поделиться опытом ,как и какие проблемы вы решали на практике с помощью паттернов проектирования и что из этого вышло в плане прозрачности кода и производительности системы. Стоит ли строго ограничивать проект каким-то набором паттернов? Были ли случаи на практике, когда паттерны излишне усложняли код проекта или паттерны это всегда догма и городить лес из абстракций просто необходимо , чтобы код оставался единообразным?
Такого вопроса в принципе быть не должно. Паттерны проектирования (GOF) надо использовать тогда когда знаешь, что они нужны и помогут. А GRASP паттерны можно использовать всегда, они почти не оказывают влияния на абстракции и тем более код. По сути это не техники какие-то, а то, как ты должен в голове распределять обязанности между классами. Фактически только ты один будешь знать, что они использованы. Найти их в коде будет невозможно - просто код будет причесанным и не будет вызывать проблем.
Очень интересует данное направление.
Хотелось бы послушать ваше мнение:
- чем отличается архитектор от проектировщика?
- может ли заказчик влиять напрямую на проектно/архитектурное решение или все такие за это должен полностью отвечать разработчик?
- на каких этапах роста проекта стоит делать ревью проекта?
Архитектура это самое сложное для меня
По построению архитектуры очень мало информации в интернете. Было бы здорово
Будет бомба если этот мужик разжует Liskov principe, мда, SOLID много где спрашивают)
А че его разжевывать, он простой как пробка на практике, так как там есть конкретные определения, тот принцип "единственной ответственности" гораздо более абстрактный и понимаемый скорее интуитивно. Принцип подстановки Лисков - подкласс должен дополнять контракт родителя, а не замещать его (т.е. предусловия нельзя усилять, постусловия - ослаблять, инварианты класса нужно сохранять). Вот и всё.
@@user-gh8sg8nr4w я именно так и понимал его всегда (никаких оверрайдов). На практике как раз таки доовольно тяжело создать иерархию в которой не будет таких нарушений. Но понимать этот принцип и почему переопределения - плохо, важно, да
По архитектуре нужен курс лекций, а не просто пару видео
После окончания универа испытываю нехватку знаний по архитектуре. Приходится всё собирать по крупицам
Как уже отметили в комментах, о том что хотелось бы увидеть сам ход мыслей при выборе паттерна.. что-то вроде: "я собираюсь подобрать паттерн для X проекта, и найболее подходящие кандидаты на роль паттерна конкретно этому проекту: паттерны 1 два и три (а причины почему именно они это ... и т.к. 1 и 2ой паттерн довольно так похожие в.. но..)... НО я остановлю свой выбор на втором паттерне, по целому ряду причин.. А так же взглянув на опыт проектировщиков, таких сервисов как * * *, можно понять что мой выбор не является ошибочным."
Спасибо за контент. Да, видео про архитектуру очень было бы полезно послушать, этого не хватает на русском языке. Очень часто возникает сложность продумать архитектуру проекта. Я конечно понимаю что архитектура создается под проекты. Было бы интересно послушать на примерах каких то проектов, например построение архитектуры для какого то проекта, и почему архитектура построена так, а не иначе, и какие она проблемы решает.
Видео том, как SaaS поддерживать для пользователей. Как вносить изменение для каких-то клиентов, и как это поддерживать.
Лучше слова подкреплять текстом, а не мимикой. Но зашло. Спасибо
Привет! Меня вот мучает такая проблема в архитектуре, что не всегда понятно, стоит независимую логическую задачу выносить в модули или контроллеры. Я стараюсь сделать так, чтобы ни один модуль не зависел от другого и с ними работали только контроллеры, но встаёт ситуация, что типичная операция должна включать в себя несколько процессов и.. тут дилемма в каком виде лучше организовать не создавая зависимости.
Сними пожалуйста про работу с данными в ангуляре, используешь сторы (если есть опыт использования сторов на реальных проектах, то плюсы и минусы их), сервисы или все в компонентах хранится, плюсы и минусы данных подходов
сторы от лукавого (мода)
какой умный человек!! спасибо за ценную информацию!!!
как рекомендуете попрактиковать чтоб их лучше понять?
Я работаю на паттерне MVVM. Пишу корпоративное десктопное приложение на C#. Хотелось бы узнать, в какой момент можно понять, что ты нарушаешь этот паттерн. Но возможно это вопрос немного специфичный.
Я испытываю нехватку знаний по архитектуре.
Помнишь все GoF? Не забывай про KISS )
Всегда было интересно насколько избыточны все эти программные конструкции. Да, конечно нужно учитывать последующую поддержку кода и величину системы, но всё равно вопрос актуален. Насколько выгоднее было бы писать не структурированный по паттернам код?
Принцип единственной ответственности не про единственную ответственность, а про зависимость от одного актора и не совпадает с high cohesion. А в целом норм😅
где купить такие очки ?
"В MVC framewёrках" - оговорка по Фрейду, что называется...
Что ты хочешь этим сказать - типа, фрэймворк не может базироваться на паттерне MVC?
Не хера не понимаю, но мне очень интересно.
😂
😂👍
Низкая связанность (Low Coupling) и Высокое зацепление (High Cohesion), а не наоборот же
Нахожусь на позиции middle fullstack developer. Постоянно ощущаю нехватку знаний об архитектурных подходов, но наибольшие сложности появляются когда пытаюсь применить неосвоенный подход. Часто получается нелепо и требуется время на причёсывание кода, а времени, естественно, нет.
Расскажи про ИИ
Слушать надо не соера, а уан лоун кодэра(one lone coder)
ты сибирский из будущего?
Кому помогло в жизни употребление и курение грибов???
Я хочу начать микродозить через день псило - сила, в долине многие коддеры юзают
Что оно даст на практике?
@@karim4046 +1-го торчка через лет 5
Архитектура очень нужна. Я запутался, как в коде реализовать ассоциации и чем на коде она отличается от агрегации :с В разных источниках пишут разные примеры и не понятно, а какой из них правильный. Пока что свожусь к мысли, что ассоциации и агрегация реализуются одинаково, просто в агрегации агрегируемые экземпляры могут принадлежать только к одному экземпляру класса-агрегатора.
В общем, очень не хватает понимания, как теорию реализовать на практике
Тот случай, когда утрамбовал свои идеи в чей-то неуклюжий кубик(GRASP).
качество видео все выше и выше
Расскажи что знаешь по DDD
DDO?
@@atlasua2021 domain driven design (DDD)
Высокая связность и слабое зацепление напрямую связаны с устойчивостью к изменениям, т.е. с выделением интерфейсов. Яву , такие как java, подталкивают разработчиков связывать классы разрабатываемой фичи в один пакет. Там даже специальный модификатор доступа есть. Внутри пакета может быть много связей между классами, это и есть высокая связность. Но вот взаимодействие между пакетами происходит через интерфейсы, желательно с низким колвом методов. Гдето даже слышал, что желательно не более 5 на интерфейс, и не более двух-трех интерфейсов на пакет. Это и есть слабое зацепление.
Это ты ещё про Go не знаешь 😉
не совсем понятно как определить что должно быть в моделе, как определить что относится к бизнес логике?