Використовуй SOLID ПРАВИЛЬНО і дивись як КОД конкурентів ПАДАЄ

Рет қаралды 809

Күн бұрын

Це відео допоможе вам зрозуміти ці концепції 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 Заключення

Пікірлер: 27

@basilstr Ай бұрын

Дякую за роботу. Наразі мало україномовного контенту з програмування. Однозначно підписка та лайк

@oleksii_letscode Ай бұрын

Дуже вдячний за відгук та перегляд!

@igor1541 Ай бұрын

Дякую за вiдео. Будо корисно послухати про SOLID , з урахуванням прикладiв. Було б цiкаво ще полухати про таке. Сподiваюсь, Ви будети i далi писати подiбнi вiдео.

@oleksii_letscode Ай бұрын

Дуже радий, що це відео було корисним :) Дякую за перегляд!

@MityaEr 26 күн бұрын

комент в підтримку каналу, каєф

@oleksii_letscode 25 күн бұрын

Найкращі глядачі 🫶

@user-uo5nu6yu4o 11 күн бұрын

Дякую завідео. Особливо за PHP) Було б цікаво послухати про DRY і KISS . Ще хотілось би побачити освітлення найпопулярнішиих паттернів .

@oleksii_letscode 11 күн бұрын

Дякую за перегляд і коментар. Про DRY та KISS обовʼязково відео вийде на каналі. Поки думаю в якому форматі це зробити. Про паттерни що саме вам було б цікаво в першу чергу?

@user-uo5nu6yu4o 10 күн бұрын

@@oleksii_letscode Наприклад найпопулярніші паттерни з базової архітектури. Як я їх називаю допустимо для laravel repository,action,service,observer. Можливо розділити на окремі невеликі відео у вигляді каталогу паттернів. Це важлива інформація бо про базові конструкції мови багато відео а по паттернам ні

@bricolico Ай бұрын

Дуууже дякую. Саме те, що шукала. На технічних співбесідах ПОСТІЙНО запитують, а в деяких принципах плаваю. Тепер зрозумію що до чого😀

@oleksii_letscode Ай бұрын

Ой, як розумію. Сам довгий час плавав в деяких з них і не розумів навіщо той SOLID придумали. А потім ЯК ЗРОЗУМІВ! ))))

@lioness74 Ай бұрын

Супер! Поки не почнеш конкртено це все використовувати, то всеодно не одразу можна зрозуміти для чого ці принципи.

@oleksii_letscode Ай бұрын

О так! Практика - наше все.

@kostya4781 Ай бұрын

Я наче і знаю цей принцип і навіть використовую але завжди цікаво подивитися як це роблять інші, може я щось не так роблю або новому чомусь навчуся)

@oleksii_letscode Ай бұрын

І то правда. Варіантів реалізації принципів може бути багато. Я свого часу довго не розумів принципу Лісков. А потім як зрозумів!!!))

@kostya4781 Ай бұрын

@@oleksii_letscode Ви праві. В мене бувало читаєш загально все зрозуміло але один пункт було не зрозуміло поки сам не стикнувся і не розібрався. Так би мовити на практиці

@junveld4830 Ай бұрын

Open/Closed на мою думку не якісно описаний. З даного відео можна зробити висновок що open/closed відноситься тільки до абстрактного класу та що практика перевизначення реалізованих методів абстрактних класів являється антипатерном (що не є правдою). Це як раз один з тих принципів який особисто в мене викликає найбільшу кількість питань щодо того як його пояснити та привести приклад, бо завчена фраза "закритий для змін, відкритий для розширення" це прекрасно, але не має під собою ніякого підґрунтя не розуміючи прикладів застосування даного принципу. Прошу навести приклад з використанням звичайного класу, або надіслати лінку з якісним прикладом. Дякую!

@oleksii_letscode Ай бұрын

Дякую за відгук! Так. погоджусь в тому, що реалізовувати абстрактний клас не найкраще рішення з мого боку. Проте, неодноразово зустрічав таких підхід навіть у великих вендорів. Тож не всі вміють в реальні патерни )) . Та й їх використовувати на 100 відсотків ну зовсім не завжди виходить в реальних ентерпрайз проєктах. Нажаль... )) Щодо вашого питання. Суть принципу в тому, щоб зберегти функціональний код незмінним, окрім випадків виправлення багів. Тобто ситуація може бути такою, що ваш клас вже протещений всіми, хто за це відповідальний і може використовуватись дуже в різних місцях бізнес логіки і цей клас може бути залежністю інших класів, де його функціонал використовується. Для запобігання проблем з бізнес логікою у вашому проєкті та щоб не робити багато регресних тестів кожного разу, коли змінюєте цей клас, базовий клас слід розширювати функціоналом, не змінюючи сам клас. А найпростіший спjсіб це зробити - наслідуватись від цього класу. Напростіший приклад тут codesandbox.io/p/sandbox/open-close-princilpe-cxsq2m?file=%2Fsrc%2FAnotherCoolFeature.ts%3A4%2C28

@junveld4830 Ай бұрын

@@oleksii_letscode Sandbox not found

@oleksii_letscode Ай бұрын

Вибачаюсь, забув відкрити в паблік. А зараз? codesandbox.io/p/sandbox/open-close-princilpe-cxsq2m?file=%2Fsrc%2FAnotherCoolFeature.ts

@junveld4830 Ай бұрын

Питання стосовно останнього принципу. Припустимо що абстрактний клас використовує клас 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() {...} }

@oleksii_letscode Ай бұрын

Гарне питання. Тут все залежить від вашого завдання. Якщо у вас клас аналітики буде лише для одної системи, наприклад до Firebase і більше ніяких систем для аналітики не плануєте підключати, чи скрізь буде використовуватись лише ця аналітика, то сенсу впроваджувати окремий інтерфейс небагато. Мені здається це буде лише додаткового обтяжувати код зайвими абстракціями і тут принцип KISS може постраждати) Але, якщо у вас на льоту десь, може через конфігурації, використовуються різні системи аналітики і, відповідно, різні класи для них, то звичайно, наведений Вами хороший приклад буде правильним рішенням. І тоді, мені здається, у вас має бути interface Analytics, який ви далі будете імплементувати в свої класах аналітики і вже далі використувати їх як залежності у ваших інших класах з бізнес логікою.

@yurademchenko9924 Ай бұрын

Підписався. Але лайка не буде. Дуже багато хардкоду 4:26 Хардкод в абстарктному класі це ... ну ви розумієте)) "0.15" 9:24

@oleksii_letscode Ай бұрын

Згоден, є косяк )) Проте, якщо не додати хардкод, то то вже мав би бути інтерфейс )) Хоча і клас можна було б не абстрактити, а інтерфейс додати... У своє виправдання скажу лише, що неоднократно зустрічав хардкоди методів в абстрактних класах навіть у серйозних вендорів в їх SDK та пакетах )))

@yurademchenko9924 Ай бұрын

@@oleksii_letscode Та я вас розумію. Я, коли з індусами працював (не всі індуси косячать), то такого надивився у фреймворках, що волосся дибки. Проте, якщо таку серйозну тему зачіпаєте як SOLID то варто уникати хардкоду. Чисто ІМХО)) Успіхів вам із каналом.

@oleksii_letscode Ай бұрын

Повністю згоден. Дуже вдячний за підтримку!

@yurademchenko9924 Ай бұрын

@@oleksii_letscode І вам дякую за україномовний контент!