Дякую за перегляд і коментар. Про DRY та KISS обовʼязково відео вийде на каналі. Поки думаю в якому форматі це зробити. Про паттерни що саме вам було б цікаво в першу чергу?
@@oleksii_letscode Наприклад найпопулярніші паттерни з базової архітектури. Як я їх називаю допустимо для laravel repository,action,service,observer. Можливо розділити на окремі невеликі відео у вигляді каталогу паттернів. Це важлива інформація бо про базові конструкції мови багато відео а по паттернам ні
Дякую за вiдео. Будо корисно послухати про SOLID , з урахуванням прикладiв. Було б цiкаво ще полухати про таке. Сподiваюсь, Ви будети i далi писати подiбнi вiдео.
@@oleksii_letscode Ви праві. В мене бувало читаєш загально все зрозуміло але один пункт було не зрозуміло поки сам не стикнувся і не розібрався. Так би мовити на практиці
Можете пояснити за тестуваня приватних методів? Багато разів бачив метод контролера, який наприклад, просто викликає приватний метод куди винесена логіка з контроллеру. Що мається на увазі за реалізацію у приватних методах, що саме в них рекомендовано писати щоб дійсно не було потреби в покритті тестами.
Ну дивіться. Тут з якого боку подивитись. Скоріше за все Ви бачили варіанти, коли розробники просто не хотіли писати тести на свій функціонал, тому викручувались саме закриттям логіки в приватних методах. Це не зовсім вірно з точки зору підтримки і тестування, але така собі лінива робоча схема. Я таке не підтримую. Але, хто заважає протестувати метод контроллера з урахуванням виклику певних логічних блоків в приватному методі? Якщо це Feature тестування, то таке не зробиш, бо то нелогічно. А от якщо ми тестуємо окремий метод класу через Unit тестування, то тут же ж можна як мінімум помокати сервіси чи інші класи, які в цьому приватному методі використовуються. Або ж поассертити якийсь результат. Таким чином всеодно косвенно мождна потетстити такі приватні методи ;)
Питання стосовно останнього принципу. Припустимо що абстрактний клас використовує клас 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, який ви далі будете імплементувати в свої класах аналітики і вже далі використувати їх як залежності у ваших інших класах з бізнес логікою.
Open/Closed на мою думку не якісно описаний. З даного відео можна зробити висновок що open/closed відноситься тільки до абстрактного класу та що практика перевизначення реалізованих методів абстрактних класів являється антипатерном (що не є правдою). Це як раз один з тих принципів який особисто в мене викликає найбільшу кількість питань щодо того як його пояснити та привести приклад, бо завчена фраза "закритий для змін, відкритий для розширення" це прекрасно, але не має під собою ніякого підґрунтя не розуміючи прикладів застосування даного принципу. Прошу навести приклад з використанням звичайного класу, або надіслати лінку з якісним прикладом. Дякую!
Дякую за відгук! Так. погоджусь в тому, що реалізовувати абстрактний клас не найкраще рішення з мого боку. Проте, неодноразово зустрічав таких підхід навіть у великих вендорів. Тож не всі вміють в реальні патерни )) . Та й їх використовувати на 100 відсотків ну зовсім не завжди виходить в реальних ентерпрайз проєктах. Нажаль... )) Щодо вашого питання. Суть принципу в тому, щоб зберегти функціональний код незмінним, окрім випадків виправлення багів. Тобто ситуація може бути такою, що ваш клас вже протещений всіми, хто за це відповідальний і може використовуватись дуже в різних місцях бізнес логіки і цей клас може бути залежністю інших класів, де його функціонал використовується. Для запобігання проблем з бізнес логікою у вашому проєкті та щоб не робити багато регресних тестів кожного разу, коли змінюєте цей клас, базовий клас слід розширювати функціоналом, не змінюючи сам клас. А найпростіший спjсіб це зробити - наслідуватись від цього класу. Напростіший приклад тут codesandbox.io/p/sandbox/open-close-princilpe-cxsq2m?file=%2Fsrc%2FAnotherCoolFeature.ts%3A4%2C28
Згоден, є косяк )) Проте, якщо не додати хардкод, то то вже мав би бути інтерфейс )) Хоча і клас можна було б не абстрактити, а інтерфейс додати... У своє виправдання скажу лише, що неоднократно зустрічав хардкоди методів в абстрактних класах навіть у серйозних вендорів в їх SDK та пакетах )))
@@oleksii_letscode Та я вас розумію. Я, коли з індусами працював (не всі індуси косячать), то такого надивився у фреймворках, що волосся дибки. Проте, якщо таку серйозну тему зачіпаєте як SOLID то варто уникати хардкоду. Чисто ІМХО)) Успіхів вам із каналом.