Використовуй SOLID ПРАВИЛЬНО і дивись як КОД конкурентів ПАДАЄ
2024 ж. 12 Мам.
822 Рет қаралды
Це відео допоможе вам зрозуміти ці концепції SOLID та зробить вас підкованими для технічних співбесід. Ми поглиблено розглянемо принципи: одиничної відповідальності, інверсії залежностей, підстановки Ліскова, сегрегації інтерфейсу та принцип відкритості/закритості, розглядаючи приклади коду, що наближені до реальних задач. Вивчайте SOLID з цим відео! #solidprinciples #solid #принциписolid #принципиПрограмування
Таймкоди:
0:00 Вступ
0:29 Що таке SOLID
0:48 Single responsibility principle
03:31 Open\close principle
06:36 Liskov substitution principle
10:03 Interface segregation principle
14:05 Dependency invertion principle
17:29 Заключення
Дякую за вiдео. Будо корисно послухати про SOLID , з урахуванням прикладiв. Було б цiкаво ще полухати про таке. Сподiваюсь, Ви будети i далi писати подiбнi вiдео.
Дуже радий, що це відео було корисним :) Дякую за перегляд!
Дякую за роботу. Наразі мало україномовного контенту з програмування. Однозначно підписка та лайк
Дуже вдячний за відгук та перегляд!
Дякую завідео. Особливо за PHP) Було б цікаво послухати про DRY і KISS . Ще хотілось би побачити освітлення найпопулярнішиих паттернів .
Дякую за перегляд і коментар. Про DRY та KISS обовʼязково відео вийде на каналі. Поки думаю в якому форматі це зробити. Про паттерни що саме вам було б цікаво в першу чергу?
@@oleksii_letscode Наприклад найпопулярніші паттерни з базової архітектури. Як я їх називаю допустимо для laravel repository,action,service,observer. Можливо розділити на окремі невеликі відео у вигляді каталогу паттернів. Це важлива інформація бо про базові конструкції мови багато відео а по паттернам ні
Дуууже дякую. Саме те, що шукала. На технічних співбесідах ПОСТІЙНО запитують, а в деяких принципах плаваю. Тепер зрозумію що до чого😀
Ой, як розумію. Сам довгий час плавав в деяких з них і не розумів навіщо той SOLID придумали. А потім ЯК ЗРОЗУМІВ! ))))
комент в підтримку каналу, каєф
Найкращі глядачі 🫶
Супер! Поки не почнеш конкртено це все використовувати, то всеодно не одразу можна зрозуміти для чого ці принципи.
О так! Практика - наше все.
Я наче і знаю цей принцип і навіть використовую але завжди цікаво подивитися як це роблять інші, може я щось не так роблю або новому чомусь навчуся)
І то правда. Варіантів реалізації принципів може бути багато. Я свого часу довго не розумів принципу Лісков. А потім як зрозумів!!!))
@@oleksii_letscode Ви праві. В мене бувало читаєш загально все зрозуміло але один пункт було не зрозуміло поки сам не стикнувся і не розібрався. Так би мовити на практиці
Open/Closed на мою думку не якісно описаний. З даного відео можна зробити висновок що open/closed відноситься тільки до абстрактного класу та що практика перевизначення реалізованих методів абстрактних класів являється антипатерном (що не є правдою). Це як раз один з тих принципів який особисто в мене викликає найбільшу кількість питань щодо того як його пояснити та привести приклад, бо завчена фраза "закритий для змін, відкритий для розширення" це прекрасно, але не має під собою ніякого підґрунтя не розуміючи прикладів застосування даного принципу. Прошу навести приклад з використанням звичайного класу, або надіслати лінку з якісним прикладом. Дякую!
Дякую за відгук! Так. погоджусь в тому, що реалізовувати абстрактний клас не найкраще рішення з мого боку. Проте, неодноразово зустрічав таких підхід навіть у великих вендорів. Тож не всі вміють в реальні патерни )) . Та й їх використовувати на 100 відсотків ну зовсім не завжди виходить в реальних ентерпрайз проєктах. Нажаль... )) Щодо вашого питання. Суть принципу в тому, щоб зберегти функціональний код незмінним, окрім випадків виправлення багів. Тобто ситуація може бути такою, що ваш клас вже протещений всіми, хто за це відповідальний і може використовуватись дуже в різних місцях бізнес логіки і цей клас може бути залежністю інших класів, де його функціонал використовується. Для запобігання проблем з бізнес логікою у вашому проєкті та щоб не робити багато регресних тестів кожного разу, коли змінюєте цей клас, базовий клас слід розширювати функціоналом, не змінюючи сам клас. А найпростіший спjсіб це зробити - наслідуватись від цього класу. Напростіший приклад тут codesandbox.io/p/sandbox/open-close-princilpe-cxsq2m?file=%2Fsrc%2FAnotherCoolFeature.ts%3A4%2C28
@@oleksii_letscode Sandbox not found
Вибачаюсь, забув відкрити в паблік. А зараз? codesandbox.io/p/sandbox/open-close-princilpe-cxsq2m?file=%2Fsrc%2FAnotherCoolFeature.ts
Питання стосовно останнього принципу. Припустимо що абстрактний клас використовує клас Analytics, але на проєкті прийнято всього використовувати лише один клас Аналітики. Чи має сенс тоді створювати окремий абстрактний клас без визначених абстрактних методів? Приклад (*певне поганий*): class DataWriter { void write(Analytics analytics); } class Analytics { void send() {...} } Приклад (*хороший*): class DataWriter { void write(Analytics analytics); } abstract class Analytics {} class FirebaseAnalytics implements Analytics { void send() {...} }
Гарне питання. Тут все залежить від вашого завдання. Якщо у вас клас аналітики буде лише для одної системи, наприклад до Firebase і більше ніяких систем для аналітики не плануєте підключати, чи скрізь буде використовуватись лише ця аналітика, то сенсу впроваджувати окремий інтерфейс небагато. Мені здається це буде лише додаткового обтяжувати код зайвими абстракціями і тут принцип KISS може постраждати) Але, якщо у вас на льоту десь, може через конфігурації, використовуються різні системи аналітики і, відповідно, різні класи для них, то звичайно, наведений Вами хороший приклад буде правильним рішенням. І тоді, мені здається, у вас має бути interface Analytics, який ви далі будете імплементувати в свої класах аналітики і вже далі використувати їх як залежності у ваших інших класах з бізнес логікою.
Підписався. Але лайка не буде. Дуже багато хардкоду 4:26 Хардкод в абстарктному класі це ... ну ви розумієте)) "0.15" 9:24
Згоден, є косяк )) Проте, якщо не додати хардкод, то то вже мав би бути інтерфейс )) Хоча і клас можна було б не абстрактити, а інтерфейс додати... У своє виправдання скажу лише, що неоднократно зустрічав хардкоди методів в абстрактних класах навіть у серйозних вендорів в їх SDK та пакетах )))
@@oleksii_letscode Та я вас розумію. Я, коли з індусами працював (не всі індуси косячать), то такого надивився у фреймворках, що волосся дибки. Проте, якщо таку серйозну тему зачіпаєте як SOLID то варто уникати хардкоду. Чисто ІМХО)) Успіхів вам із каналом.
Повністю згоден. Дуже вдячний за підтримку!
@@oleksii_letscode І вам дякую за україномовний контент!