Подивився повністю, заходить формат. Відео довге, але зовсім не стомлює.
@АлександрГулюк-ъ4п Жыл бұрын
я додивися :D
@arsenbatyuchok4377 Жыл бұрын
Клас! Які загалом враження про серію цих відео? Любий фідбек - дуже цінний! Дайте свій імейл і я додам вас в CNTRL :)
@slipenkyibohdan3205 Жыл бұрын
наскільки я зрозумів, то немає експортів/імпортів, бо немає що експортувати/імпортувати. Думаю якщо додати якусь чанкінг стратегію, то імпорт зявиться🍿
@tkustov Жыл бұрын
можливо)
@v.shchepotin Жыл бұрын
45:32 Шановий сеніор, думаю ви не до кінця розумієте, що таке Dependency Injection (DI) та Dependency Inversion Principle (DIP). Це різні речі, і якось повʼязувати їх взагалі не коректно. Ніхто нікого там не повинен наслідувати. DI та DIP реалізовуються на різних рівнях. Спробую пояснити максимально тупо: DI, грубо кажучи, це штука яка зберігає інстанси класів, і потім, за потреби, дозволяє взяти ці інстанси де тобі треба, без створення додаткових інстансів (як би власне заради цього всі цей DI реалізовують, це дуже зручно). DIP це штука яка рекомендує (робить настанови), як правильно проектувати класи, щоб вони не залежали від модулів нижчого рівня. Пане, перед тим як розповідати такі теми треба дуже гарно підготуватись. 47:34 Доречі, додавайте посилання на першоджерела, дуже цікаво почитати, де це таке пишуть.
@tkustov Жыл бұрын
Якщо абстрагувати: DIP - принцип, завдяки якому досягається loose coupling. DI - механізм (або паттерн, або техніка, як вам зручно), що має на меті (одній з) забезпечення loose coupling. Також слід зазначити separation of concerns у сенсі розділення відповідальностей по _створенню_ залежностей від їх _використання_. Тут і статей з вікі достатньо (англомовної, українську не перевіряв). Ще раджу статтю за авторством Марка Сімана "Pure DI" і книгу, що в ній зазначена (дуже хотів привести посилання, але KZbin видаляє комент) Тому, я і не кажу що "це одне і те саме", але зв'язок очевидний. Звісно, DIP не єдиний принцип, спрямований на loose coupling, але вписується у механізм DI найбільше, із відомих мені. Вважайте це моєю інтерпретацією, але я пов'язую DIP і DI у контексті інструментів для досягнення loose coupling. "Ніхто нікого там не повинен наслідувати." Я казав "слідувати", а не "наслідувати". Принципам слідують. DIP (слідую)--> loose coupling
@v.shchepotin Жыл бұрын
@@tkustov дякую за відповідь, я уважно вивчу все що ви надали, та повернусь
@v.shchepotin Жыл бұрын
@@tkustov ще раз переглянув фрагмент відео та те що ви надали в коментарі і зрозумів що ви мали на увазі. По-перше хочу вибачитись. Я спочатку не до кінця дослухав ваші міркування, бо триґернувся з моменту 46:50 по 47:08 про те що DI в NestJS порушує DIP, мені тоді здалося, що ви взагалі переплутали DI та DIP, але додивившись до кінця, впевнився що зробив невірний висновок. Я з вами згоден що DI повинен слідувати DIP для досягення loose coupling. Тут ніяких питань немає. По-друге, я все ще не згоден з тим, що "те що в Nest це не DI, бо порушує DIP". Так, DI в dotnet реалізований краще ніж в nest, але тут більше проблема в мовах. C# дає нам змогу використовувати інтерфейси, в той час для досягення подібних цілей в typescript ми повинні використовувати токени (я зрозумів, що вам це не подобається, мені також не дуже подобається, але жити можна) або абстрактні класи (ось з ними виглядає все доволі не погано, і рекомендую звернути на це увагу). trilon крапка io слеш blog слеш dependency-inversion-principle - перегляньте цю статтю, можливо ви зміните свою думку. Все ж таки, наступний раз, краще покажіть в відео статті або подібне, де хто що говорить, типу ангуляр розробники визнають, що в них не справжній DI, і подібні речі про які ви говорите. Або хочаб попросіть автора канала додати посилання в описі під відео. Можливо б з цим ви змогли когось переконати, а так більше виглядає, як ваша особиста думка.
@tkustov Жыл бұрын
@@v.shchepotin Прочитав зазначену вами статтю - це саме те, через що мені і не подобається підхід до DI подібний до того що у NestJS, тобто фоловити DIP можно, але ціною доволі великої кількості додаткового коду і залучення ще кількох елементів бібліотеки, тобто збільшенням складності на рівному місці. Та і заради чого? Фенсі синтаксису з анотаціями? Серед слабких місць DI-системи NestJS _я виділяю_ для себе такі пункти: * У коді сутності присутній особливий синтаксис DI-системи. Як не крути але це обмежує свободу дій із цією сутністю, наприклад, будь-яка інтеграція із умовно старим кодом, без DI-системи, або просто з іншою. Синтаксис анотацій (декораторів) додає неявної поведінки у код юніта. Та і взагалі, присутність цього синтаксису створює залежність сутності від елемента системи організації залежностей, що попахує Service Locator'ом :). Ця претензія стосується всіх подібних систем і у C#, і у Java і т.д. (тут маю на увазі що сутність aware про DI-систему) * "Розмазування" декларацій DI-системи по проекту як наслідок синтаксису анотацій. Мені набагато більш до вподоби паттерн Composition Root, про нього можна почитати у Марка Сімана. * Фоловання DIP не заохочується: в екзамплах і документації повно прикладів саме із посиланням на реалізацію. Думаю, причина цього проста - маркетинг. Бо весь додатковий код, що робить DI-систему хоч якось придатною для слідування DIP виглядає не те щоб фенсі :) Може я неправий, сподіваюсь є більш вагома причина. * Тайп-чекінг в рантаймі, замість компайл-тайма. Чому? :). У підсумку: _для мене_ така DI-система є meaningless, бо втрачає ключові моменти: не заохочує до DIP, тайп-чекінг такий собі та присутність елементів DI-системи у коді юніта. Добре, я згоден, що DI-систему NestJS, з натяжкою, але можна називати DI - формальні ознаки присутні, хоч і гарні принципи організації залежностей не заохочуються. В ідеалі - мати DI-систему, із якою _не_ слідувати DIP _неможливо_. Доречі, я не проти токенів, якщо немає кращого рішення, це така собі "ручна заміна рефлексії". На рахунок розробників ангулар: говорив по пам'яті, був упевнений що бачив подібні рядки у документації, у секції про DI, перепровіривши - не знайшов - або мене підводить пам'ять, або підправили доки. Звісно, це все *моя особиста думка*, перепрошую, якщо недостаньо це артикулював, мабуть - через брак ораторського досвіду. Було б дивно, якби я просто вікі або доки переказував. Тим більше у мене не було цілі когось у чомусь переконувати, я лише вказав на реальні нагальні проблеми конкретної реалізації, поділився наслідками, які вбачаю у використання подібного рішення.
@arsenbatyuchok4377 Жыл бұрын
@@tkustov 1) У коді сутності присутній особливий синтаксис DI-системи. - на цьому все)))