Введение в шаблоны GRASP. Онлайн лекция

[@alexandrapersukova]

Ребят, как вам лекция?

[@Vitalik186]

супер! я аж покурив в кінці :)

[@SadSvit17]

Здравствуйте, хотел вас поблагодарить, ваша лекция помогла подготовиться к экзамену в магистратуре по дисциплине ЯЗЫК UML И ОСНОВЫ ОБЪЕКТНООРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ ИС

[@AlexClamp]

Дякую за лекцію, займаюсь в тренажерному залі й дивлюсь 🙃

[@_GreenSnake_]

Спасибо за Ваш труд

[@itclassiq2879]

Лекция отличная, спикер как всегда на высоте, ещё бы лекций хотя бы парочку по PoEAA

[@alex_nevskiy_888]

Спасибо, весьма понятно. Интересно было бы послушать мысли про "паттерн" "Package by features, not layers".

[@ZekeFast]

1:55:22 Я гадаю, що GoF дуже гарно описали повні шаблони, але у реальних системах вони змінюються та адаптуються, а іноді використовую не у повному вигляді. Дуже гарна книга на цю тему: "Рефакторінг із використанням шаблонів" від Джошуа Карієвскі ("Refactoring to Patterns" by Joshua Kerievsky).

[@FreemanFromSteppe]

дьякую. посмотрю

[@MrPotapovV]

Дякую за цінні знання!

[@ZekeFast]

@Sergey Nemchinskiy Я гадаю, що на сучасному етапі розвитку розробники мов програмування зрозуміли, що спадкування у стандартній формі (С++, Java, etc.) несе більше проблем ніж бенефітів. Тож у нових мовах від стандартної реалізації відмовились: Go, Rust не мають можливості стандартного спадкування між типами. Але є ідеї інтерфейсного спадкування (aka traits in Rust). Також треба зауважити, що стандартний ООП non-sense, це щось на кшталт AWS жаргону де віртуальний сервер зветься нодою, та інше. Але усі звикли і ніхто вже не пам'ятає, що було колись не так. Гадаю, що треба було б додати, що створення нового классу, це створення нового типу перш за все, а спадкування це не дуже гарна форма створення product типів. При цьому нормальна можливість створення Sum типів зазвичай у розповсюджених стандартних мовах програмування зазвичай відсутня, що дуже часто викликає багато проблем при моделюванні предметної області, бо у реальному житті Sum типи доволі розповсюджені. То ж не дуже обізнанні архітектори залишаються із спадкуванням та намагаються за його допомогою та ще й якоїсь матері моделювати поведінку типів-сум. З дуже редукованих можливостей типу-суми у Java є тільки enum, який на відміну від enum-а у тому ж Rust має більші обмеження та меньш елегантно використовується мовою.

[@QimAliq]

тээк ну насчет однопоточности UI Немчинский зря на человека наезжал! UI реально выполняется в одном потоке обычно, а примеры, которые приводил Немчинский, относятся к асинхонности / очереди (помпе) сообщений / реакции на события (или как оно там правильно называется?). в браузере скрипт вообще всегда в одном потоке выполняется, насколько я знаю, для скрипта в принципе многопоточность невозможна

[@ZekeFast]

Також Node.js у більшості випадків працює у одному потоці, але асінхронно. Також є можливість пускати її з декількома воркерам та різними потоками. Щей зараз, якщо додаток виконується на кубері (Kubernetes), то часто конфігурують лише один потік на под (pod) із котейнером.

[@BidonNadoev]

1:21:04 Текст на экране про промежуточный объект, а Сергей рассказывает про интерфейс.

[@ZekeFast]

27:18 Linux написан на C, але є нюанс! :D Там буже часто використовується такий підхід де у структурі разом із даними є посилання на функції які треба викликати! Ось вам і класи! А може ще хтось пам'ятає, що перший "компілятор" С++ насправді був транслятором в код на С, який робив такий самий фокус! :) Тож ООП це парадигма (то як люди мислять о програмі), а писати можна й на С. А окрім Linux-a, ще є GTK, який теж на С написаний, але сказати, що він не об'єктноорієнтований язик не повертається, хоча ця об'єктнаорієнтовність й дуже незвично виглядає для Java розробника.

[@ВладимирЗавидонов-и4т]

Когда будут книги? Беру. Две.

[@seoonlyRU]

лайк от СЕООНЛИ

[@mykola_antal]

1:35:00 Gold фігня, якщо брати, то або Standart (для ознайомлення, подешевше), або Platinum (для повного розуміння). Gold прям для дуже специфічних умов підійде, можливо устаканити і закріпити накопичений досвід (не малий досвід)

[@ZekeFast]

1:17:10 @Sergey Nemchinskiy У вас точка зору виключно бекенд-розробника. Є багато інших видів розробки де широке використання поліморфізму із динамічним диспатчем призводить до несприйнятливої вартості у продуктивності виконання програм: системне програмування, розробка ігор, баз даних, HPC, near real time та real time системи та багато інших. Зазвичай, але не завжди, полімормізм у мовах програмування виконано за допомогою динамічного диспатчу, що одразу вбиває можливість компілятора заглядати за такі виклики методів та інлайнити їх, що у свою чергу погіршує роботи блоку передбачення переході у ЦП та призводить до погіршення швидкості виконання програми. Але треба також зазначити, що існують можливості у мовах програмування для статичного поліморфізму із дженеріками. У цьому випадку увесь код мономорфізується для уособленого типу та усі проблеми у рантаймі зникають (але можливий code bloat). Про роботу JIT та його можливість інлайнити поліморфні виклики на жаль не знаю багато, може він і здатен це оптимізувати у JVM, але є багато інших мов де JIT не такий просунений чи може бути зовсім відсутній.

[@Sprint-n3n]

Fine

[@savchuk-ruslan]

Стосовно термінів для coupling cohesion. Бачив переклад "связанность" і "связность" мені більше сподобалось

[@ZekeFast]

1:48:00 Що до великої Domain Model, то у DDD (Domain-Driven Design) вже доволі давно відомо про шаблон (aka pattern) Bounded Context, який дозволяє розподілити дуже велику й багату модель між контекстами у яких вона використовується. Модель може мати різний набір полів у залежності від контексту. Domain Model складна, тому що її створення лягає цілковито на розробників конкретної системи. Якщо маппінг даних, зв'язок із БД та інші функції можно якось винести до бібліотек та фреймворків та у такий спосіб зменшити вимоги до проєктувальників та розробників системи, то Domain Model є безпосередньо конкретною системою і якість її реалізації залежить від розробників системи та їх обізнаності, а також наявності часу та коштів на досягнення бажаної якості.

[@speedyjet4508]

😂😂😂какой-то козёл, который пришёл снаружи это однозначно 5!

[@oleksiymusiyezdov5040]

Cohesion - однородность (как вариант).

[@АлексейБаранов-з1ц]

Сергей, я нашёл отсылку на Вас в мультике 95 квартала (младший брат) kzbin.info/www/bejne/rKHUindtqLeJZqs

[@eligolin9947]

Ха ха... весь IoC это полное противоречия этому так сказать Creator принципу. 😂

[@aleksandrbeloushkin7971]

Зачем нужны справочники, если есть ChatGPT)

[@анатолийАнатольевич-ю4ч]

Вообще не зашло, пробовал смотреть три ваших видео... Вы хотя бы примеры меняли бы...

[@errandir]

А почему бы «cohesion» не перевести просто как «когезия» и начать использовать именно его? Вполне себе нормальный термин, и суть отражает. Ну и что, что там ранее напереводили.