Дякую, корисно і пізнавально! Про адаптер здогадався майже одразу, згадав картинку де у квадратний отвір треба було всунути циліндр) Закортіло перечитати патерни і передивитись свій код ☺
Основна проблема в темі патернів - їх достатньо багато, половина майже не використовується, а на співбесіді треба впевнено сказати "так, знаю". Згоден з тим, що патерни - це надовго, і від того що ти перечитав гуру нічого не зміниться. Але й працювати треба вже зараз, а не через рік-два, коли ти більшість патернів спробуєш і зрозумієш. І, виходить, що більшість програмістів десь посередині між "я робив Адаптер та Singleton, але не знав що це так називається" і "я розумію всі, але роблю 3".
Бо реалізувати один патерн, особливо породжуючий - це вже задача впровадження патерну в якості ядра архітектури однієї великої фічі, розробка якої в цілому триває кілька місяців. Якщо середній досвід програміста 4 роки, то не надто багато патернів вдається реалізувати при цьому не натягуючи сову на глобус. Намагатись в кожному модулі реалізувати якийсь патерн - це ще гірша помилка, ніж їх взагалі не використовувати.
категорично не згоден. щодо багато, так, там є десь альманах на 500 паттернів, але важливо не знати їх всі напам'ять, важливо розуміти які за ними спільні ідеї й принципи проєктування - GRASP (Applying UML and Patterns, Larman1998). Щодо того, що половина майже не використовується - це просто неправда, більшість активно використовується, а деякі з них - взагалі фундаментальні техніки без яких майже нічого не напишеш. То ви просто не знаєте що те що ви написали - це варіація якогось патерну, або у вас просто біда в коді з cohesion/coupling, і з патернами могло бути набагато краще. І туди ж те що ви написали про "роблю 3". Ну хіба що припускаю що може таке бути якщо шльопати форми на реакті то там дійсно багато патернів не використаєш, але і там cohesion/coupling це фактори. Що на співбесіді треба впевнено казати (брехати) "так, знаю" якщо не знаєш - це, перепрошую, взагалі крінж. Хто вас змушує брехати на співбесіді?
@@nqhndl > То ви просто не знаєте що те що ви написали - це варіація якогось патерну, або у вас просто біда в коді Автор навів приклад використання патерну Адаптер, де градуси Цельсія конвертується в Фаренгеїти convertCelciumToFarengeit(temperature). То виходить створити якусь функцію - це вже використання патерну? Дуже круто, тоді все на світі є патерном або її варіацею. А особливо патерном Міст.
@@nqhndl ок, у вас на співбесіді спитають "а розкажіть мені про *pattern name* - і ви там сидіть та згадуйте які в них принципи, а від вас чекають банальних знань з книжки. In the same way - А я кажу правда) У frontend-і саме більшість не використовується, бо є декілька найбільш зручних і роблять все по ним. Для чого робити щось не звичне і не зручне, якщо можна зробити звичне і зручне? Дійсно, я не знаю, що пишу. І жодного патерну не бачу і не застосовую в своєму коді. Вам краще видно. Очевидно, що до замовчування проблеми веде бажання отримати роботу. Я і не кажу брехати - а саме бути невпевненим в тому що кажеш. Дуже радий що Ви крінжуєте з ситуації, яка для багатьох стала новою реальністю за останній рік.
Дякую за пізнавальний та корисний контент. Дякую за промокод, давно книга "Патерни проєктування" лежить в списку бажано, а тут знижка, гріх не купити, вже замовив. Дякую.
Приклади малюнків Пікассо і Далі в академічному стилі (ті які побоявся добавляти на ютуб) - t.me/AlexKovalchukTg/50 Я зміг домовитись з видавництвом Фабула про знижку підписникам 15%. Знаходьте цікаву вам літературу на сайті ( cfy.li/fabula ), вводьте промокод - FabulaIT15 діє до 22.09.2023) і підтримайте Українську локалізацію.
Тема цікава і важлива. На практиці нажаль люди дуже часто ігнорують цю тему і пишуть свої велосипеди. Але тут є один момент - наприклад ви шукаєте фронта який працює на Vue, і вчить паттерни просто щоб пройти співбесіду - бо ви цього від нього очікуєте - далі він їх забуває і далі пише на своєму Vue. Насправді якщо вам потрібен не інженер - а девелопер який збирає фронт на Vue - то і очікуйте від нього паттернів Vue - такі є, і книги по ним також є, так само як і по паттернам до інших фреймворків. Це не означає що не треба знати орігінальну базу, але так хоч люди будуть одразу бачити практичний результат - і почнуть використувавати на практиці і можливо колись дійдуть і до класичних паттернів.
ота проблема -- що беремо і робимо новий клас, що бере нове та переводить у старе ) Цей шаблон було створено до того, як з'явилися лямбди в Java ) Зараз було б вже досить для такого маппінгу зробити тільки одну функцію, яка живе без класу і дозволяє вирішити таку задачу. В тім, коли треба розширитися на кріпту -- то швидше треба робити композит, що вмії з'єднувати декілька дата-сет-провайдерів в один дата-сет-провайдер. До речі, сам елементарний дата-сет може приймати клас-стратегію, а не адаптер, що буде відображати домен конкретної біржі у домен застосунку. ну то таке ;) Власне проблема з патернами в тому, що доки до реальних задач справа не дійде, то паттерни дуже важко зрозуміти. А інша -- І як я вже сказав, паттерни реально обтяжені специфікою конкертної мови программування, а саме Java, що по-перше вимагає знання тієї самої джава, а по-друге вимагає розуміння того, як аналогічні задачі вирішуються в мові конкретного проекта. Наприклад -- є у нас сінглтон. За паттерном треба створювати новий клас-нащадок (щоб не втрачати можливість мульті-інстанціування головного класу), в ньому сховати конструктори, додатави статичні методи інстанціювання в яких власне або повертати раніше створений, або створювати та зберігати новий екземпляр класу. В JS/TS можна створити лише одну функцію-фабрику, що буде робити те саме, а дуже часто можна взагалі просто інстанціювати клас і просто імпортувати той екземпляр там де треба. Я широко використовує DI, куди я замість фабрики для DB Connection кладу вже готовий інстанц, або, наприклад, fetch (http client) -- я також кладу просто екземпляр. А про мій улюблений паттерн "декоратор" і казати нема чого. Якщо дивитись на першоджерело -- все таке складне і для декорації функцій ґеть не підходить (бо там класи) ... а найпоширішений в JS декоратор memo -- це саме функція, яка декорує теж функцію. До речі -- ще один спосіб імплементації сінглтона ;) Якщо казати про FP-мови програмування, то там можна окрему книгу видати з того, як застосувати паттерни проектування, скажімо в тому самому Гаскелі або більше реальному Рвсті, де ООП так би мовоти "транспановано" відносно тієї самої Java
@@Digey90 та як би ж то ;) до речі, монади є не тількив ФП, а і не у ФП також ... І то трохи інший рівень абстракції, ніж "бандитьскі" патерни. Патерни ближчі до бізенсової логіки. А от монади -- то про з'єднання стрілок клейслі, тобто про написання коду з ефектами в термінах чистих функцій. То ж, паттерни та монади дуже добре один одного доповнюють
Паттерни - то цікава тема. Сліпо їм слідувати не треба. Бо можна наплодити абстракцій/шарів там, де вони нафіг не потрібні. Їх треба зрозуміти. Але і зрозуміти до кінця їх можна тоді, колі протрахаєшся з проблемою, що вони вирішують. І тому, виходить, треба спочатку натрахатись самому - а потім вже лізти патерни розбирати...
Цікавий факт, але до більшості патернів можна дійти й самому вирішуючи проблему low coupling та high cohesion. Решта ж патернів досить нішева та треба 10 разів подумати перед тим як їх використовувати, бо абстракції мають ціну, а код в першу чергу має бути зрозумілим
Дякую тобі. За твій труд й цікаву подачу. Книги, що ти рекламуєш, майже всі "зібрав" й прочитав. Без промокоду, ех :(. Але в них ще бувають цікаві акції й знижки на "бандли"
Я не згоден, що треба придумувати свій. Я вважаю, треба розуміти проблему, яку треба вирішити та шукати в теоретичній базі, яку ти вже вивчив/зазубрив/опрацював рішення. В мене так завжди відбувається. І Вас, скоріше за все, так само. Якби не читали теорію, то не було б матеріалу для генерації свого рішення
Це топ 😂 Пояснюю жарт (може хтось не зрозуміє). Сінглтон входить в список патернів, але його часто називають антипатерном, бо він порушує принцип ООП (принцип єдиної відповідальності)
@@alex-kovalchuk ось про принципи і треба зробити відео. Бо насправді принцип єдиної відповідальності - це принцип що який говорить що на одну частину коду має відповідати тільки один "аткор" (де актор це можна сказати замовник цього коду) - і це якраз SOLID. А те що ви маєте на увазі це принцип separation of concerns - це якраз більше ООП принцип. І сінголтон йог порушує тільки якщо його не правельно використувавати. Про те як його правельно використовувати - теж можна зробити відео :) Розмова про те що солід це антипаттерн уже говорить про те що тема не пройдена і не зрозуміла до кінця - і будьякий паттерт може стати антипаттерном якщо його засунути не туди куди треба - це доречі перша проблема початківців - після засвоєння теорії засовувати паттерни всюди :)
100%, люди за патерни не шарять і шарити не хочуть, хочуть хіба що знати що відповісти на співбесіді) Скільки через мене таких пройшло це просто біда, і кожен з впевненим видом розказує що знає, поки не почнеш розпитувати. Зробіть, будь ласка, такий самий ролик про СОЛІД, бо патерни хоча б зрозуміло, там їх багато. СОЛІД принципів всього 5, 90% не знають і їх, тільки хіба що як кожна літера розшифровується, і не глибше.
Як на мене більшість патернів це рішення в стилі "капітан очевидність" які можна застосувати маючи базове логічне мислення, навіть ніколи не чувши про патерни
Полностью согласен! В любом случае если много практиковать то разные подходы родятся в здравой голове сами собой! Это как у Фиби было с гитарой «старушичья рука» :))))
ну або якщо ти сам маєш створити код від початку до кінця, зліпити все до купи, то в тебе немає вибору окрім як мати досвід, здоровий глузд і розуміти, що не можна пришивати яйця до легень бо воно просто не буде працювати. слово "паттерни" вигадали тролі з HR щоб знущатись з аплікантів на співбесідах.
Щодо мідла - то в них як раз хромає застосування патернів, тому що їм притаманно писати оверлоад функції та класи. А ось Senior вже має навички, як будувати певні архітектурні рішення. У більшості ж випадків, коли питаєш - то так, можуть проговорити SOLID, певні патерни. Коли питаєш, а як зрозуміти, що десь є порушення застосування того ж підходу Ліскоі, то й все. Загубилися... І так повністю погоджуюсь, що тільки практика допоможе. Але тут в гру вступає не один фактор, якщо є бажанні, адекватні архітект та ліди і є на це час.
а паттерни що, не з функцій і класів складаються? як же можна відповісти на питання чи є порушення у використанні паттерна? це суб'єктивна думка тому що паттерни це дуже абстрактна річ, правила гарного тону у програмуванні + досвід і майстерність кодера. кожен кодер, навіть самий тупий індус якому в школі математику не викладали, використовує паттерни для створення коду, просто вони не настільки ефективні як у кодера, який розуміє ТА і візуалізує проєкт від початку і до кінця знаючи що і як він буде писати, які модулі потрібні, які будуть баги чи несумісність і які танці з бубнами треба виконати, щоб все те запрацювало. сучасні мови програмування роблять паттерни архаїзмами тому що достатньо мати здоровий глузд і ефективно використовувати наявні інструменти. то що таке Ліскоі? навіть гугл не знає. в цього дивного слова є нормальна англійська версія?
Патерни це та річ, про яку тебе питають на співбесіді: - а ти знаєш ось такий патерн і для чого саме він викрористовується? - ні, не знаю. а що саме? - ну це паттерн який...(далі йде опис патерна як у книжці). Зрозуміло? - тю! так я майже все своє програмістське життя так роблю. і якось воно само по собі з досвідом прийшло та забуло сказати, що ось воно - це патерн з конкретною назвою. Я привів приклад з типовою співбесідою. Сам я цікавився темою патернів не після питань на співбесіді. Але в мене було так само - прочитав про патерн, подивився приклади і "тю! так я так і робив все життя, коли вирішував типову для цього патерну задачу". Декілька з них звичайно не були знайомі, але вони були відмічені авторами книжки як рідко використовувані або такі, що не дуже підходять для реалізації в моїй мові програмування.
Кажуть, що маючи молоток, все навколо здається гвоздем. Тобто, знаючи шаблон А, будеш його пхати де тільки вийде. Я чогось замість адаптера подумав, що простіше було б мати remapping function. Але я джаву змінив на тайпскрипт кілька років тому. Дякую за відео! Треба ще
Так є ж різні патерни і їх багато. Тут питання скільки людей їх знає, які знає і скільки їх правильно використовують, хоча це взаємопов'язані речі, якщо розумієш - то звісно що будеш їх використовувати.
Я 35 років прожив і не знав що таке патерни і навіть не знав про їх існування. Я просто шокований що не знав про їх існування, світ ніколи не буде для мене таким як раніше. Як тепер дальше жити? Блін напевно так як раніше...
Співбесіди це як продажу б/в авто. Якщо продавець буде максимально чесним, він ніколи не продасть авто. Тому і співбесіда це процес коли від кандидата хочуть чути лише те що хочуть.
Патерни як інструмент спонукають користувачів до вибору патерна ще до того як вони зрозуміють усю сукупність проблем (concerns) які слід вирішити цим дизайном. Чи навіть ігнорування деяких concerns щоб можна було використати улюблений патерн. Крім того навіть вдало підібраний для поточної сукупності concerns патерн може виявитись невдалим у ході розвитку дизайну і виявлення нових concerns. Як інформаційний матеріал патерни корисні, а як нормативний - шкідливі
Вони скоріше підходять більше для рефакторінгу, коли є більш-менш стала версія і необхідно все привести у охайний вигляд. Але хто в умовах швидкоплинності бізнесу витрачає час на рефакторінг архітектури?)) Хіба, що ідейні програмісти-перфекціоністи, які під час овертаймів це роблять, а потім пишуть книги про патерни.
@@РазбавлякаЗабывака коли працюєш на себе, а не на контору, яка тобі оплачує час знаходження за компом, то і гратись в рефакторинг уже й не так хочеться. одразу треба писати код на стилі, щоб було приємно потім подивитись. паттерни вигадали для тих, в кого туго зі здоровим глуздом і артистизмом бо їм треба на щось спиратись там, де вони мають спиратись на свій досвід і свій стиль як кодера.
Нічого не зрозумів з прикладу про термометри. Чим використання патернів відрізняється від використання процедур чи методів об'єктів, чи засад ооп? Чи патерни і шаблони це одне і те? Чи можна перед тим, як вигадувати зоопарк з пінгвінами, дати приклад якогось реального патерну, який створила четвірка супергероїв? Бо підсумок, що щоб зрозуміти патерни, маєш створити власний патерн якось не того, якщо взагалі не пояснено, що це. А так дякую за відео, було цікаво
Зоопарк з пінгвінами це приклад патерну Адаптер (Wrapper) від четвірки. По суті вони створили патерни за одною схемою на найпопулярніші проблеми. Патерни це та штука які програмісти і так використовують постійно просто систематизована. Кожен патерн складається з - проблема, яку вирішує патерн; - мотивація щодо вирішення проблеми способом, який пропонує патерн; - структура класів, складових рішення; - приклад однією з мов програмування; - особливості реалізації в різних контекстах; - зв’язки з іншими патернами
От з шаблонами завжди так: ніби і прості речі, але ніби і складні, все-одно нічого не зрозуміти, доки не спробуєш. Для мене це відео скоріше працює як нагадування, досить вчасно випущене, до речі)
Я інженер будівельник, дотичний до урбаністики. Це будинок це просто ***** собача, той ****** хто це побудував просто ******, співчуваю тому хто проектував це *****, з усвідомленням того урбаністичного *** який поклали на цей ******** шедевр марнотраству і *******. *****, слів немає
Я не програміст і ці всі слова (мід, джун, фреймворк, патерни etc) для мене незрозумілі. В жаргонному сенсі, англійську я знаю нормально. В мене просто є блокнот, в котрому пишу код і запускаю його з терміналу. Пояснення доволі просте. Виявляється патерни -- це штуки які працюють та існували ще до того, як їх так назвали.
Але ж їх придумали люди. І придумавши свій можна набагато краще зрозуміти складність з якою стикались автори а також ще раз переосмислити своє рішення. В книзі від банди чотирьох так і радять робити Звичайно самописні патерни не варто навʼязувати іншим, це має бути просто елементом навчання.
@@alex-kovalchuk дійсно їх придумали люди, але не ті, кого ти звеш авторами ))) мільйони інших людей використовували ці паттерни задовго до того бо це логічно і ефективно. а тут з'являються хайпожери і розповідають, що це вони автори паттернів і навіть імена їм подавали. прям Лиса Аліса і Кіт Базіліо 2 комплекта. і тому прямий доказ - несвідоме використання паттернів людьми, які навіть не здогадуються про їхнє існування.
Патерни - настільки зрозумілі та очевидні, що про них можна говорити тільки алюзіями та аналогіями. Є питання, я пишу на реакті, відповідно в 99 випадках з 100 - це функціональне програмування. Чи обов'язково використовувати патерни у поєднанні з об'єктами, чи це нормально - реалізовувати цю логіку на функціях?
Якщо ти береш готовий каркас, наприклад nuxtjs то можна жити без них. Але всерівно будеш придумувати певні свої рішення проблем Я б радив хоча б ознайомитись з ними щоб при потребі згадав що десь чув про це
яким прикладом? паттерни це абстракція. типу в тебе як людини такий паттерн вранці: прокинувся (паттерн ефективного виконання дії - спустив одну ногу з кроваті, намацав підлогу, спустив іншу, топ-топ), пішов в туалет (паттерн: підняв кришку, і т.д). тобто ти виконуєш набір дій і вони мають бути злагоджені і ефективні. бо якби ти не підняв кришку, почав сцяти то це був би неефективний паттерн бо тоді довелось би додатково прибирати і витрачати на це час. тобто паттерн це абстракція, ідея, яка містить у собі найбільш ефективний спосіб виконання дії. якщо про приклади з програмування, то в програмуванні немає єдиного закону щоб прописував як і що програмувати, головне щоб код був коротким, легким у розумінні, структурно мав сенс і можна було легко додавати нові фічі. коли всі ці критерії будуть виконані тоді кодер застосував вірні паттерни. але оскільки програмування це теж мистецтво і два різних кодера можуть знайти зовсім різні підходи до вирішення проблеми, то будь які приклади будуть такою ж абстракцією. люди ще й почнуть сваритись що так не можна треба було робити по іншому )))
Я знаю паттерни 😅 приходьте і вас навчу. Це безкоштовно. А взагалі паттерни мають різну реалізацію і різну корисність в різних мовах. Небуває універсального паттерну всього і на все. А от чи знаєте ви парадігми....
Зустрічав ще проблему. "Нам вумні дядькі сказали після код-рев'ю, що тут краще використати такий-то патерн. хтось щось розуміє?". Й починається таке натягування сови на глобус... Краще б взагалі не чіпали
У багатьох людей чомусь фіксація на GoF-паттернах, а про Distributed systems design patterns чомусь багато хто забуває, хоча без останніх якраз набагато тяжче обійтись backend developer'у на великому проекті з мікросервісами і DDD
А як е антипатерни? Що раніше було патерном зараз вже вважається антипатерном. В тій же книгі банди 4, перші патерни сінгелтон, але зараз це вважається погано його використовувати.
Я колись PHP 3 вчив і на патернах запоровся ну і лишив то все діло бо думав що тупий.Потім через Х років почав з С де немає ООП і зрозумів що без тої фігні можна жити і ООП це не головне.Треба все робити за технологією "keep it simple " і все буде ок.
На одне з відео де я порівнюю функціонал ютубу і порнхабу ютуб заагрився, хоча я там закрив усе що могло не сподобатись. Тому зараз вирішив не ризикувати. Коли канал виросте можна буде одразу в ютуб вставляти, але поки що при проблемах я навіть не зможу до сапорту достукатись
@@nqhndl які саме? В об'єктно орієнтовному програмуванні, в С++ подібних мовах оператор new є мовним аналогом паттерну Factory. Інший паттерн: абстрактні класи.
@@AndriiMuliar це називається ідіоми. Патерни це більш високорівневі конструкції. Очевидно ви не читали книжку GoF, раджу почитати І ні, factory це не new
@@jannadark8100 ти впевнений, що ти "знаєш ООП"? Що ти розумієш, що це не про ключові слова extends або class? Як побудувати систему, яка не буде схожа на написану у процедурному стилі (класи-структури та класи без стейту, але з поведінкою - це не схоже на ООП)? Так, я можу сказати що я "не знаю ООП", далеко не один рік у програмуванні.
@@andrewD508 там теорії всього кілька сторінок. структурне (процедурне програмування) відрізняється тим, що виконання йде зверху вниз але і має менше інструментів (немає наслідування, абстракції і ін.). ооп це лего, а структурне програмування це лапша :)
Їх особо не використовують тому шо нема де. В аутсорсі пишуть в основному на якихось фреймворках і там вже все зроблено і так. Патерни можуть знадобитися при розробці бібліотек наприклад. Тому їх мало хто знає тому що маже немає де їх використовувати і воно все забувається швидко
Зазвичай автори фреймоврку навʼязують структуру проекту. Там виділяють папку під бізнес логіку. Якщо навіть в рамках неї реалізовано погано такий проект не складно підтримувати. Але за умови що розробники дотримувались рамок фреймворка
@@VladiqLot а шо таке бізнес логіка ? пару крудів и вьюха ? Питання куди можна засунути патерни наприклад Observer, Singleton, Proxy, Composite, Facade итп в бізнес логіку ? Максимум що там може буде це наслідування похожих якихось моделей.
@@alex-kovalchuk ну я в курсі. Я кажу про те шо більшість, яка працює в бізнесі не використовує патерни тому шо нема просто де. Якщо ти працюешь в опенсорсі і котрібьютишь в якісь фреймворки то там це використовується. Більшість же робить круди і там немає просто місця де вліпить ці патерни. Тому їх мало хто знає тому що у повсякденному житті мало де їх можно використати, якщо ти не розробник фреймворку якогось.
Ну як я і казав в першу чергу щоб понтуватись перед іншими програмістами😅 Дуже часто з патернів роблять каргокульт а не використовують як зручний інструмент
Я певний час не міг зрозуміти нашо ті паттерни, якшо можна по іншому розв'язувати ту проблему. Виявилось, деякі паттерни актуальні для одних, і не актуальні для інших мов.
Синглтон то теж паттерн і я сумніваюся, що його знають лише одиниці. А взагалі так, ніхто не знає паттерни і в реальних проектах з легасі кодом їх важко знайти та/або застосувати
За визначенням синглтон гарантує, що клас матиме тільки один екземпляр, і забезпечує глобальну точку доступу до цього екземпляра. Проте у більшості С++ прикладів він вирішує ще дві проблеми: - гарантує існування екземпляру коли він потрібен - лінива ініціалізація Інша комбінація цих проблем привести до іншого рішення, звісно якщо не обмежувати себе патернами
Як в кінці кінців вчити ці патерни? Я постійно їх забуваю, хоча взяв розібрався написав його з часом не пам'ятаю і не знаю коди їх застосувати. Як розібратись раз і назавжди?
В прикладному програмуванні фреймворки заміняють патерни, тому це тепер не обов'язкові знання. Але якщо захочеш поковиряти сам фреймворк який використовуєш то варто просто мати їх під рукою Бо якщо не використовуєш і вивчиш, то просто знову забудеш, або що ще гірше то почнеш тулити їх туди куди непотрібно
@@alex-kovalchuk Фреймвьорки не замінюють бізнес логіку. Я не розумію як ФВ можуть замінити патерни, вони тільки можуть під капотом використовувати, а вот бізнес логіка зовсім інша.
Продовжуй розвивати український контент, подача відео на вищому рівні!
Дякую за підтримку
Лайк за Троєщину❤
Го на каву вийдем? Шукаю однодумців з Троєщини
Надзвичайно цікаве та корисне відео
Дуже дякую тобі за твою працю!
Дякую за підтримку, такий фітбек надихає фігачити далі
Дякую, корисно і пізнавально! Про адаптер здогадався майже одразу, згадав картинку де у квадратний отвір треба було всунути циліндр) Закортіло перечитати патерни і передивитись свій код ☺
Велике дякую вам за це відео❤❤❤
Бажаю вам міцного здоров'я та сил🦾
Знайшов ваш контент, це неймовірно!
Ідейно, винахідливо, корисно.
Підписка, та лайк обов'язково! 🔥
Дуже класний формат, так тримати 🙌
Основна проблема в темі патернів - їх достатньо багато, половина майже не використовується, а на співбесіді треба впевнено сказати "так, знаю".
Згоден з тим, що патерни - це надовго, і від того що ти перечитав гуру нічого не зміниться. Але й працювати треба вже зараз, а не через рік-два, коли ти більшість патернів спробуєш і зрозумієш. І, виходить, що більшість програмістів десь посередині між "я робив Адаптер та Singleton, але не знав що це так називається" і "я розумію всі, але роблю 3".
💯%
Бо реалізувати один патерн, особливо породжуючий - це вже задача впровадження патерну в якості ядра архітектури однієї великої фічі, розробка якої в цілому триває кілька місяців. Якщо середній досвід програміста 4 роки, то не надто багато патернів вдається реалізувати при цьому не натягуючи сову на глобус. Намагатись в кожному модулі реалізувати якийсь патерн - це ще гірша помилка, ніж їх взагалі не використовувати.
категорично не згоден.
щодо багато, так, там є десь альманах на 500 паттернів, але важливо не знати їх всі напам'ять, важливо розуміти які за ними спільні ідеї й принципи проєктування - GRASP (Applying UML and Patterns, Larman1998).
Щодо того, що половина майже не використовується - це просто неправда, більшість активно використовується, а деякі з них - взагалі фундаментальні техніки без яких майже нічого не напишеш. То ви просто не знаєте що те що ви написали - це варіація якогось патерну, або у вас просто біда в коді з cohesion/coupling, і з патернами могло бути набагато краще. І туди ж те що ви написали про "роблю 3". Ну хіба що припускаю що може таке бути якщо шльопати форми на реакті то там дійсно багато патернів не використаєш, але і там cohesion/coupling це фактори.
Що на співбесіді треба впевнено казати (брехати) "так, знаю" якщо не знаєш - це, перепрошую, взагалі крінж. Хто вас змушує брехати на співбесіді?
@@nqhndl
> То ви просто не знаєте що те що ви написали - це варіація якогось патерну, або у вас просто біда в коді
Автор навів приклад використання патерну Адаптер, де градуси Цельсія конвертується в Фаренгеїти convertCelciumToFarengeit(temperature). То виходить створити якусь функцію - це вже використання патерну? Дуже круто, тоді все на світі є патерном або її варіацею. А особливо патерном Міст.
@@nqhndl ок, у вас на співбесіді спитають "а розкажіть мені про *pattern name* - і ви там сидіть та згадуйте які в них принципи, а від вас чекають банальних знань з книжки.
In the same way - А я кажу правда) У frontend-і саме більшість не використовується, бо є декілька найбільш зручних і роблять все по ним. Для чого робити щось не звичне і не зручне, якщо можна зробити звичне і зручне?
Дійсно, я не знаю, що пишу. І жодного патерну не бачу і не застосовую в своєму коді. Вам краще видно.
Очевидно, що до замовчування проблеми веде бажання отримати роботу. Я і не кажу брехати - а саме бути невпевненим в тому що кажеш.
Дуже радий що Ви крінжуєте з ситуації, яка для багатьох стала новою реальністю за останній рік.
Дякую за пізнавальний та корисний контент. Дякую за промокод, давно книга "Патерни проєктування" лежить в списку бажано, а тут знижка, гріх не купити, вже замовив. Дякую.
Крутяк, на днях почав перелистувати цю книгу. Сподіваюсь тобі також сподобається
Приклади малюнків Пікассо і Далі в академічному стилі (ті які побоявся добавляти на ютуб) - t.me/AlexKovalchukTg/50
Я зміг домовитись з видавництвом Фабула про знижку підписникам 15%. Знаходьте цікаву вам літературу на сайті ( cfy.li/fabula ), вводьте промокод - FabulaIT15 діє до 22.09.2023) і підтримайте Українську локалізацію.
Тема цікава і важлива. На практиці нажаль люди дуже часто ігнорують цю тему і пишуть свої велосипеди. Але тут є один момент - наприклад ви шукаєте фронта який працює на Vue, і вчить паттерни просто щоб пройти співбесіду - бо ви цього від нього очікуєте - далі він їх забуває і далі пише на своєму Vue. Насправді якщо вам потрібен не інженер - а девелопер який збирає фронт на Vue - то і очікуйте від нього паттернів Vue - такі є, і книги по ним також є, так само як і по паттернам до інших фреймворків. Це не означає що не треба знати орігінальну базу, але так хоч люди будуть одразу бачити практичний результат - і почнуть використувавати на практиці і можливо колись дійдуть і до класичних паттернів.
ота проблема -- що беремо і робимо новий клас, що бере нове та переводить у старе )
Цей шаблон було створено до того, як з'явилися лямбди в Java )
Зараз було б вже досить для такого маппінгу зробити тільки одну функцію, яка живе без класу і дозволяє вирішити таку задачу.
В тім, коли треба розширитися на кріпту -- то швидше треба робити композит, що вмії з'єднувати декілька дата-сет-провайдерів в один дата-сет-провайдер. До речі, сам елементарний дата-сет може приймати клас-стратегію, а не адаптер, що буде відображати домен конкретної біржі у домен застосунку.
ну то таке ;)
Власне проблема з патернами в тому, що доки до реальних задач справа не дійде, то паттерни дуже важко зрозуміти.
А інша -- І як я вже сказав, паттерни реально обтяжені специфікою конкертної мови программування, а саме Java, що по-перше вимагає знання тієї самої джава, а по-друге вимагає розуміння того, як аналогічні задачі вирішуються в мові конкретного проекта.
Наприклад -- є у нас сінглтон. За паттерном треба створювати новий клас-нащадок (щоб не втрачати можливість мульті-інстанціування головного класу), в ньому сховати конструктори, додатави статичні методи інстанціювання в яких власне або повертати раніше створений, або створювати та зберігати новий екземпляр класу.
В JS/TS можна створити лише одну функцію-фабрику, що буде робити те саме, а дуже часто можна взагалі просто інстанціювати клас і просто імпортувати той екземпляр там де треба. Я широко використовує DI, куди я замість фабрики для DB Connection кладу вже готовий інстанц, або, наприклад, fetch (http client) -- я також кладу просто екземпляр.
А про мій улюблений паттерн "декоратор" і казати нема чого. Якщо дивитись на першоджерело -- все таке складне і для декорації функцій ґеть не підходить (бо там класи) ... а найпоширішений в JS декоратор memo -- це саме функція, яка декорує теж функцію. До речі -- ще один спосіб імплементації сінглтона ;)
Якщо казати про FP-мови програмування, то там можна окрему книгу видати з того, як застосувати паттерни проектування, скажімо в тому самому Гаскелі або більше реальному Рвсті, де ООП так би мовоти "транспановано" відносно тієї самої Java
В фп є один патерн - монада і її достатньо для вирішення більшості проблем.
@@Digey90 та як би ж то ;)
до речі, монади є не тількив ФП, а і не у ФП також ...
І то трохи інший рівень абстракції, ніж "бандитьскі" патерни. Патерни ближчі до бізенсової логіки. А от монади -- то про з'єднання стрілок клейслі, тобто про написання коду з ефектами в термінах чистих функцій.
То ж, паттерни та монади дуже добре один одного доповнюють
Дякую за якісний контент, за промокод і за нагадування купити класику 🙏
За диплом однозначно лайк
Не дарма його добивався 😅
@@alex-kovalchuk впевнений, тоді, навіть не знали накой воно знадобиться😂
Хай квітне український UA-cam! 🇺🇦
Дуже цікаво, але поки мало зрозуміло, та поза як, дякую за Український контент
Сподіваюсь це через поріг входу, а не через те що я так погано розказую 😅
Паттерни - то цікава тема. Сліпо їм слідувати не треба. Бо можна наплодити абстракцій/шарів там, де вони нафіг не потрібні. Їх треба зрозуміти. Але і зрозуміти до кінця їх можна тоді, колі протрахаєшся з проблемою, що вони вирішують. І тому, виходить, треба спочатку натрахатись самому - а потім вже лізти патерни розбирати...
Цікавий факт, але до більшості патернів можна дійти й самому вирішуючи проблему low coupling та high cohesion. Решта ж патернів досить нішева та треба 10 разів подумати перед тим як їх використовувати, бо абстракції мають ціну, а код в першу чергу має бути зрозумілим
Відео хороше. Гумористична складова шикарна. На кількох місцях голосно засміявся. Легко сприймається інформація з цього відео.
Дякую за підтримку, буду фігачити далі)
Junior - не старається використовувати патерни
Middle - старається використовувати патерни
Senior - старається не використовувати патерни
Дуже дякую Вам за вашу працю, за ваші цікаві та корисні україномовні випуски!
Дякую за підтримку
*Тому що треба грошей!* 🤗
Кім Чен Ір як кодревюер це бомба)))
дякую за класне відео ))
Хто ми з тобою? Ми з тобою хрещені! Де ми хрещені - в церкві на Троєщині 😈
Дякую тобі. За твій труд й цікаву подачу. Книги, що ти рекламуєш, майже всі "зібрав" й прочитав. Без промокоду, ех :(. Але в них ще бувають цікаві акції й знижки на "бандли"
Дякую
Дякую за відео. Невеличке зауваження: в нашій мові нема слова получається/получилося.
Я не згоден, що треба придумувати свій. Я вважаю, треба розуміти проблему, яку треба вирішити та шукати в теоретичній базі, яку ти вже вивчив/зазубрив/опрацював рішення. В мене так завжди відбувається. І Вас, скоріше за все, так само. Якби не читали теорію, то не було б матеріалу для генерації свого рішення
Я знаю! Ось до прикладу сінглтон!
Це топ 😂
Пояснюю жарт (може хтось не зрозуміє). Сінглтон входить в список патернів, але його часто називають антипатерном, бо він порушує принцип ООП (принцип єдиної відповідальності)
@@alex-kovalchukімпостер серед патернів😂
@@alex-kovalchuk може вже SOLID а не ООП?
Так, SOLID. Щось перегрівся на сонці і не то написав
@@alex-kovalchuk ось про принципи і треба зробити відео. Бо насправді принцип єдиної відповідальності - це принцип що який говорить що на одну частину коду має відповідати тільки один "аткор" (де актор це можна сказати замовник цього коду) - і це якраз SOLID. А те що ви маєте на увазі це принцип separation of concerns - це якраз більше ООП принцип. І сінголтон йог порушує тільки якщо його не правельно використувавати. Про те як його правельно використовувати - теж можна зробити відео :)
Розмова про те що солід це антипаттерн уже говорить про те що тема не пройдена і не зрозуміла до кінця - і будьякий паттерт може стати антипаттерном якщо його засунути не туди куди треба - це доречі перша проблема початківців - після засвоєння теорії засовувати паттерни всюди :)
Це лайкооосс! В ім*я святого Сінглтона, блаженнійшого Білдера і всіх Фабрик!
Круть!
Величезне дякую за відео! Якраз ніяк руки не доходили до патернів!
Класний канал , скоро у вас буде 100к+ підписників
Дякую, якщо буде я буду дуже щасливим😅
100%, люди за патерни не шарять і шарити не хочуть, хочуть хіба що знати що відповісти на співбесіді) Скільки через мене таких пройшло це просто біда, і кожен з впевненим видом розказує що знає, поки не почнеш розпитувати.
Зробіть, будь ласка, такий самий ролик про СОЛІД, бо патерни хоча б зрозуміло, там їх багато. СОЛІД принципів всього 5, 90% не знають і їх, тільки хіба що як кожна літера розшифровується, і не глибше.
А хтось із цих людей точно думає, що це ви не знаєте паттерни, бо ви читали не ту книгу, що вони 😂
@@yuriy5376 щодо даної гіпотетичної ситуації, сподіваюсь ви жартуєте, а не серйозно маєте на увазі що таке можливо)
Як на мене більшість патернів це рішення в стилі "капітан очевидність" які можна застосувати маючи базове логічне мислення, навіть ніколи не чувши про патерни
У книзі “GOF” так і пишуть «можливо багато патернів ви застосовуєте не знаючи що це вони»
Полностью согласен! В любом случае если много практиковать то разные подходы родятся в здравой голове сами собой! Это как у Фиби было с гитарой «старушичья рука» :))))
ну або якщо ти сам маєш створити код від початку до кінця, зліпити все до купи, то в тебе немає вибору окрім як мати досвід, здоровий глузд і розуміти, що не можна пришивати яйця до легень бо воно просто не буде працювати. слово "паттерни" вигадали тролі з HR щоб знущатись з аплікантів на співбесідах.
Щодо мідла - то в них як раз хромає застосування патернів, тому що їм притаманно писати оверлоад функції та класи. А ось Senior вже має навички, як будувати певні архітектурні рішення. У більшості ж випадків, коли питаєш - то так, можуть проговорити SOLID, певні патерни. Коли питаєш, а як зрозуміти, що десь є порушення застосування того ж підходу Ліскоі, то й все. Загубилися... І так повністю погоджуюсь, що тільки практика допоможе. Але тут в гру вступає не один фактор, якщо є бажанні, адекватні архітект та ліди і є на це час.
а паттерни що, не з функцій і класів складаються? як же можна відповісти на питання чи є порушення у використанні паттерна? це суб'єктивна думка тому що паттерни це дуже абстрактна річ, правила гарного тону у програмуванні + досвід і майстерність кодера. кожен кодер, навіть самий тупий індус якому в школі математику не викладали, використовує паттерни для створення коду, просто вони не настільки ефективні як у кодера, який розуміє ТА і візуалізує проєкт від початку і до кінця знаючи що і як він буде писати, які модулі потрібні, які будуть баги чи несумісність і які танці з бубнами треба виконати, щоб все те запрацювало. сучасні мови програмування роблять паттерни архаїзмами тому що достатньо мати здоровий глузд і ефективно використовувати наявні інструменти. то що таке Ліскоі? навіть гугл не знає. в цього дивного слова є нормальна англійська версія?
Лайк за Факторіо!
Чудове відео. Дякую!
Я також з Тернопільської обл
Дякую за відео. Вподобайку за мотивацію
Лайк за факторіо
Як на мене, факторіо це ідеальний приклад любові програмістів автоматизувати усе
dsltj njgxbr - переклад (відео топчик)
Патерни це та річ, про яку тебе питають на співбесіді:
- а ти знаєш ось такий патерн і для чого саме він викрористовується?
- ні, не знаю. а що саме?
- ну це паттерн який...(далі йде опис патерна як у книжці). Зрозуміло?
- тю! так я майже все своє програмістське життя так роблю. і якось воно само по собі з досвідом прийшло та забуло сказати, що ось воно - це патерн з конкретною назвою.
Я привів приклад з типовою співбесідою. Сам я цікавився темою патернів не після питань на співбесіді. Але в мене було так само - прочитав про патерн, подивився приклади і "тю! так я так і робив все життя, коли вирішував типову для цього патерну задачу". Декілька з них звичайно не були знайомі, але вони були відмічені авторами книжки як рідко використовувані або такі, що не дуже підходять для реалізації в моїй мові програмування.
Капець крутий конь тент
В тебе топові відоси! Дуже дякую! Давай ще))
Дякую за підтримку, буде ще)
Подача крута, дякую тобі!
Все так, якраз на цьому тижні було багато інтерв'ю, але про патерни не говоримо, мучаю більш дикими речами 😊 але то корисно, принаймні мені здається 😊
А якими речами допитуєш кандидатів?
якраз дивлюсь різні матеріали на цю тему і тут вийшло нове відео ))
Радий допомогти)
Кажуть, що маючи молоток, все навколо здається гвоздем. Тобто, знаючи шаблон А, будеш його пхати де тільки вийде. Я чогось замість адаптера подумав, що простіше було б мати remapping function. Але я джаву змінив на тайпскрипт кілька років тому.
Дякую за відео! Треба ще
> Я чогось замість адаптера подумав, що простіше було б мати remapping function
бо так і є
Так є ж різні патерни і їх багато. Тут питання скільки людей їх знає, які знає і скільки їх правильно використовують, хоча це взаємопов'язані речі, якщо розумієш - то звісно що будеш їх використовувати.
Моя повага за правду)
Я 35 років прожив і не знав що таке патерни і навіть не знав про їх існування. Я просто шокований що не знав про їх існування, світ ніколи не буде для мене таким як раніше. Як тепер дальше жити? Блін напевно так як раніше...
Зате тепер в компанії програмістів зможеш сказати "Так, знаю про патерни, не вразило" 😅
Співбесіди це як продажу б/в авто.
Якщо продавець буде максимально чесним, він ніколи не продасть авто.
Тому і співбесіда це процес коли від кандидата хочуть чути лише те що хочуть.
Патерни як інструмент спонукають користувачів до вибору патерна ще до того як вони зрозуміють усю сукупність проблем (concerns) які слід вирішити цим дизайном. Чи навіть ігнорування деяких concerns щоб можна було використати улюблений патерн. Крім того навіть вдало підібраний для поточної сукупності concerns патерн може виявитись невдалим у ході розвитку дизайну і виявлення нових concerns. Як інформаційний матеріал патерни корисні, а як нормативний - шкідливі
Вони скоріше підходять більше для рефакторінгу, коли є більш-менш стала версія і необхідно все привести у охайний вигляд. Але хто в умовах швидкоплинності бізнесу витрачає час на рефакторінг архітектури?)) Хіба, що ідейні програмісти-перфекціоністи, які під час овертаймів це роблять, а потім пишуть книги про патерни.
@@РазбавлякаЗабывака коли працюєш на себе, а не на контору, яка тобі оплачує час знаходження за компом, то і гратись в рефакторинг уже й не так хочеться. одразу треба писати код на стилі, щоб було приємно потім подивитись. паттерни вигадали для тих, в кого туго зі здоровим глуздом і артистизмом бо їм треба на щось спиратись там, де вони мають спиратись на свій досвід і свій стиль як кодера.
Колись давно на код ревью мій тім лід(а він був досить скіловий розробник) показав на шматок кода і сказав “це порушує якусь хуйню з SOLID”
Нічого не зрозумів з прикладу про термометри.
Чим використання патернів відрізняється від використання процедур чи методів об'єктів, чи засад ооп?
Чи патерни і шаблони це одне і те?
Чи можна перед тим, як вигадувати зоопарк з пінгвінами, дати приклад якогось реального патерну, який створила четвірка супергероїв?
Бо підсумок, що щоб зрозуміти патерни, маєш створити власний патерн якось не того, якщо взагалі не пояснено, що це.
А так дякую за відео, було цікаво
Зоопарк з пінгвінами це приклад патерну Адаптер (Wrapper) від четвірки. По суті вони створили патерни за одною схемою на найпопулярніші проблеми. Патерни це та штука які програмісти і так використовують постійно просто систематизована. Кожен патерн складається з
- проблема, яку вирішує патерн;
- мотивація щодо вирішення проблеми способом, який пропонує патерн;
- структура класів, складових рішення;
- приклад однією з мов програмування;
- особливості реалізації в різних контекстах;
- зв’язки з іншими патернами
От з шаблонами завжди так: ніби і прості речі, але ніби і складні, все-одно нічого не зрозуміти, доки не спробуєш. Для мене це відео скоріше працює як нагадування, досить вчасно випущене, до речі)
Не пробуйте факторіо, якщо у вас нема зайвого(або вільного) місяця-двох часу
хехех :) ви б в мене співбесіду не пройшли :)
Я інженер будівельник, дотичний до урбаністики.
Це будинок це просто ***** собача, той ****** хто це побудував просто ******, співчуваю тому хто проектував це *****, з усвідомленням того урбаністичного *** який поклали на цей ******** шедевр марнотраству і *******.
*****, слів немає
Я не програміст і ці всі слова (мід, джун, фреймворк, патерни etc) для мене незрозумілі. В жаргонному сенсі, англійську я знаю нормально. В мене просто є блокнот, в котрому пишу код і запускаю його з терміналу. Пояснення доволі просте. Виявляється патерни -- це штуки які працюють та існували ще до того, як їх так назвали.
Свої патерни - це нісенітниця. А тим паче вігадування своїх назв. Тому вони і патерни, що використовуються більшістю і вирішують схожі проблеми
Але ж їх придумали люди. І придумавши свій можна набагато краще зрозуміти складність з якою стикались автори а також ще раз переосмислити своє рішення. В книзі від банди чотирьох так і радять робити
Звичайно самописні патерни не варто навʼязувати іншим, це має бути просто елементом навчання.
@@alex-kovalchuk дійсно їх придумали люди, але не ті, кого ти звеш авторами ))) мільйони інших людей використовували ці паттерни задовго до того бо це логічно і ефективно. а тут з'являються хайпожери і розповідають, що це вони автори паттернів і навіть імена їм подавали. прям Лиса Аліса і Кіт Базіліо 2 комплекта. і тому прямий доказ - несвідоме використання паттернів людьми, які навіть не здогадуються про їхнє існування.
Остання фраза кожен раз винос😂
Ну таке собі поясненя
Взяв спочатку приклад з біржою і перескочив на пінгвінчиків.
Патерни - настільки зрозумілі та очевидні, що про них можна говорити тільки алюзіями та аналогіями. Є питання, я пишу на реакті, відповідно в 99 випадках з 100 - це функціональне програмування. Чи обов'язково використовувати патерни у поєднанні з об'єктами, чи це нормально - реалізовувати цю логіку на функціях?
Якщо ти береш готовий каркас, наприклад nuxtjs то можна жити без них. Але всерівно будеш придумувати певні свої рішення проблем
Я б радив хоча б ознайомитись з ними щоб при потребі згадав що десь чув про це
Алекс, чого так рідко щось випускаєте? Ви дуже цікаво розказуєте, класні відео!
Взяв невелику паузу, уже повернувся
@@alex-kovalchuk вас вистачить на раз в тиждень випускати відео? )
Нічого обіцяти не можу, на наступні вихідні відео уже знято, але на ці вихідні напевне не зможу. Тому майже кожного тижня буде відео 😅
Дякую за український контент. а буде продовження теми ? якимось прикладом ?
яким прикладом? паттерни це абстракція. типу в тебе як людини такий паттерн вранці: прокинувся (паттерн ефективного виконання дії - спустив одну ногу з кроваті, намацав підлогу, спустив іншу, топ-топ), пішов в туалет (паттерн: підняв кришку, і т.д). тобто ти виконуєш набір дій і вони мають бути злагоджені і ефективні. бо якби ти не підняв кришку, почав сцяти то це був би неефективний паттерн бо тоді довелось би додатково прибирати і витрачати на це час. тобто паттерн це абстракція, ідея, яка містить у собі найбільш ефективний спосіб виконання дії. якщо про приклади з програмування, то в програмуванні немає єдиного закону щоб прописував як і що програмувати, головне щоб код був коротким, легким у розумінні, структурно мав сенс і можна було легко додавати нові фічі. коли всі ці критерії будуть виконані тоді кодер застосував вірні паттерни. але оскільки програмування це теж мистецтво і два різних кодера можуть знайти зовсім різні підходи до вирішення проблеми, то будь які приклади будуть такою ж абстракцією. люди ще й почнуть сваритись що так не можна треба було робити по іншому )))
@@jannadark8100 ну правильно можна просто поводити а ти там розбирайся ... але "истина гдето там"
почув про аналогії, пінгвінів, бінанс, тощо. Так а шо по тій фабриці?
От не знаю як там патерни, але після вашого відео вже я від Mini Motorways відірватися не можу.))))
Я також залип на них. Дуже крута гра з простою механікою. Бо в факторіо треба лише туторіал проходити декілька годин
Я знаю паттерни 😅 приходьте і вас навчу. Це безкоштовно. А взагалі паттерни мають різну реалізацію і різну корисність в різних мовах. Небуває універсального паттерну всього і на все. А от чи знаєте ви парадігми....
щойно ти почав розповідати про задачу я вже зрозумів що мова йтиме про адаптер/врапер)
Зустрічав ще проблему. "Нам вумні дядькі сказали після код-рев'ю, що тут краще використати такий-то патерн. хтось щось розуміє?". Й починається таке натягування сови на глобус... Краще б взагалі не чіпали
Так, є проблема коли після того, як вивчили пробують присунути патерни/підходи всюди де треба і де не треба
На своїй практиці використав тільки два. Команда і фабрика і то поверхнево. Там ще тої фабрики також є три види вроді
У багатьох людей чомусь фіксація на GoF-паттернах, а про Distributed systems design patterns чомусь багато хто забуває, хоча без останніх якраз набагато тяжче обійтись backend developer'у на великому проекті з мікросервісами і DDD
А як е антипатерни? Що раніше було патерном зараз вже вважається антипатерном. В тій же книгі банди 4, перші патерни сінгелтон, але зараз це вважається погано його використовувати.
сінглтон не погано і не добре використовувати - все залежить від того де, і для чого.
Я колись PHP 3 вчив і на патернах запоровся ну і лишив то все діло бо думав що тупий.Потім через Х років почав з С де немає ООП і зрозумів що без тої фігні можна жити і ООП це не головне.Треба все робити за технологією "keep it simple " і все буде ок.
Ага, програмування на мовах з іншими підходами дуже сильно розширює бачення
Картини з оголенням можна публікувати в ЮТ так как це памʼятка культури
На одне з відео де я порівнюю функціонал ютубу і порнхабу ютуб заагрився, хоча я там закрив усе що могло не сподобатись.
Тому зараз вирішив не ризикувати. Коли канал виросте можна буде одразу в ютуб вставляти, але поки що при проблемах я навіть не зможу до сапорту достукатись
Треба розібратись. Думаю, що використовую паттерни несвідомо, але які саме, як і де, пояснити не зможу бо власне не знаю паттернів.
FSM можна вважати патерном?
Він занадто конкретний, але можна описати патерн для якого FSM буде елементом прикладу рішення (той же патерн State використовує скінченний автомат)
@@alex-kovalchuk ось і я нашкрябав відео, як раз по цій темі, якщо хочете можете глянути
Я не брешу, що я знаю патерни. Я чесно знаю, що я їх не знаю
Паттерни програмування: оператор new (Factory pattern), struct, NULL, switch.... Усі ми використовуємо ці паттерни які стали частиною мови
та ні, під патернами розуміють абсолютно інші речі
@@nqhndl які саме? В об'єктно орієнтовному програмуванні, в С++ подібних мовах оператор new є мовним аналогом паттерну Factory.
Інший паттерн: абстрактні класи.
@@AndriiMuliar це називається ідіоми. Патерни це більш високорівневі конструкції. Очевидно ви не читали книжку GoF, раджу почитати
І ні, factory це не new
Їх треба не так знати як вміти використовувати
А танці з бубном це дуже тонко і смішно 😂
Кандидати кажуть те, чого від них хочуть.
Як часто інтерв'юери НЕ будуть дивитись на кандидата "як на дурника", якщо він буде казати "я не знаю ООП"?
Так, і дуже часто інтерв'юєри питають те що їм не треба на роботі, а кандидати зубрять для інтерв'юєрів не розуміючи суті
в сенсі не знає ООП? а нахіба тоді приперся на роботу влаштовуватись? чи в нас в країні такі низькі стандарти до кодерів що ООП можна і не знати?
@@jannadark8100 ти впевнений, що ти "знаєш ООП"? Що ти розумієш, що це не про ключові слова extends або class? Як побудувати систему, яка не буде схожа на написану у процедурному стилі (класи-структури та класи без стейту, але з поведінкою - це не схоже на ООП)?
Так, я можу сказати що я "не знаю ООП", далеко не один рік у програмуванні.
@@andrewD508 там теорії всього кілька сторінок. структурне (процедурне програмування) відрізняється тим, що виконання йде зверху вниз але і має менше інструментів (немає наслідування, абстракції і ін.). ооп це лего, а структурне програмування це лапша :)
Той момент, коли ти зрозумів, що це адаптер паттерн ще на середині формулювання...
Їх особо не використовують тому шо нема де. В аутсорсі пишуть в основному на якихось фреймворках і там вже все зроблено і так. Патерни можуть знадобитися при розробці бібліотек наприклад. Тому їх мало хто знає тому що маже немає де їх використовувати і воно все забувається швидко
Бізнес-логіку як допомагає писати фреймворк?)
Зазвичай автори фреймоврку навʼязують структуру проекту.
Там виділяють папку під бізнес логіку. Якщо навіть в рамках неї реалізовано погано такий проект не складно підтримувати.
Але за умови що розробники дотримувались рамок фреймворка
@@VladiqLot а шо таке бізнес логіка ? пару крудів и вьюха ? Питання куди можна засунути патерни наприклад Observer, Singleton, Proxy, Composite, Facade итп в бізнес логіку ? Максимум що там може буде це наслідування похожих якихось моделей.
@@alex-kovalchuk ну я в курсі. Я кажу про те шо більшість, яка працює в бізнесі не використовує патерни тому шо нема просто де. Якщо ти працюешь в опенсорсі і котрібьютишь в якісь фреймворки то там це використовується. Більшість же робить круди і там немає просто місця де вліпить ці патерни. Тому їх мало хто знає тому що у повсякденному житті мало де їх можно використати, якщо ти не розробник фреймворку якогось.
@@maxleo3374 якщо у вас пару вьюх і круди, то дійсно нікуди.
4:23 гарна аналогія з північною корею 😂
Цікаве відево лайк
Якщо це така неважлива річ, іку ніхто не знає, то навіщо питати?
А взагалі просто не потрібно бути абстрактним фабричним суперсеньором...
Ну як я і казав в першу чергу щоб понтуватись перед іншими програмістами😅
Дуже часто з патернів роблять каргокульт а не використовують як зручний інструмент
Рекапча ще жива?)
Гугл старається її показувати все менше і менше. Але на жаль ще жива
Все пішла реєструватись на конкурс декламаторів віршів, щоб і собі мати диплом по патернах 😅
Тепер буде що показати на співбесіді 😅
не розумію, це відео про патерни чи про аналогії між програмуванням і мистецтвом?
Тут і те і інше. Добре що вирізав великий блок про урбаністів, бо це було уже занадто 😅
Я певний час не міг зрозуміти нашо ті паттерни, якшо можна по іншому розв'язувати ту проблему. Виявилось, деякі паттерни актуальні для одних, і не актуальні для інших мов.
Ага, при чому деякі мови просто почали реалізовувати патерни самі і тому програмісти зараз не розуміють в чому взагалі проблема
Ось підписався на канал,
Тупеньким був - розумним став
(але це не точно)
🤓
Синглтон то теж паттерн і я сумніваюся, що його знають лише одиниці. А взагалі так, ніхто не знає паттерни і в реальних проектах з легасі кодом їх важко знайти та/або застосувати
За визначенням синглтон гарантує, що клас матиме тільки один екземпляр, і забезпечує глобальну точку доступу до цього екземпляра. Проте у більшості С++ прикладів він вирішує ще дві проблеми:
- гарантує існування екземпляру коли він потрібен
- лінива ініціалізація
Інша комбінація цих проблем привести до іншого рішення, звісно якщо не обмежувати себе патернами
За сінгелтон бʼють по руках у нормальних командах:)
Бо є DI
Як в кінці кінців вчити ці патерни?
Я постійно їх забуваю, хоча взяв розібрався написав його з часом не пам'ятаю і не знаю коди їх застосувати.
Як розібратись раз і назавжди?
В прикладному програмуванні фреймворки заміняють патерни, тому це тепер не обов'язкові знання. Але якщо захочеш поковиряти сам фреймворк який використовуєш то варто просто мати їх під рукою
Бо якщо не використовуєш і вивчиш, то просто знову забудеш, або що ще гірше то почнеш тулити їх туди куди непотрібно
@@alex-kovalchuk Фреймвьорки не замінюють бізнес логіку. Я не розумію як ФВ можуть замінити патерни, вони тільки можуть під капотом використовувати, а вот бізнес логіка зовсім інша.
Відео ні про що. Суцільна вода.
Оо, відео
Так, я повернувся)
Поки розбирався що до чого коли вчив мову точно спробував-майже-зрозумів 3 патерни, як куа автоматизатор поки що тільки адапетарми користуюсь)))))🤯
Дайте пліз лінку на сайт, де зібрані патерни
Ось крутий сайт - refactoring.guru/uk/design-patterns/catalog