Видео

А що з ними не так?_)

Мда. Воно реально валідацію не проходить. Виявляється, в мене автозаміна лапок була включена. Дякую :)

І так часу нормально не вистачає :(

На пару відео ще відкочусь на щось більш низькорівневе. А тоді назад в спрінг

Вбити вихідні на те, аби написати щось цікаве, але нікому не потрібне - то святе :)

Привіт. Напряму - скоріше поки ні. А так - foxminded.ua/java-1/. Якщо треба контакт - t.me/black220sun

Я раніше теж не задумувався. А потім рандомно прийшло в голову, і аж захотілось це в відео засунути😅

Ну отакі "базові" штуки в принципі достатньо загальні і не сильно від мови залежать. Круто, що не лише джавістам цікаво_)

Технічно, воно мало б бути "для новачків". Але я коли відео знімаю, я виходжу з того, що людина, яка буде дивитися його, знає все (ну або все, що потрібно) з того, що було в вже відзнятих відео Ну а саме тут мені і самому здавалось, що воно в результаті якось сильно заплутано і не дуже "просто" вийшло. Але вже як є :shrug:

Дякую_)

Я чотири з копійками роки розробкою трансляторів займався. Мені це просто подобається_) Місцями - так, спробувати реалізувати руками якісь фічі інших мов. Місцями - просто аби згадати щось, з чим я працював. Місцями - показати, як це працює "під капотом"

Та щось все руки до ютубу не доходили, буду виправлятись_) По Spring'у щось конкретне цікавить?

Планується. Але в мене зараз щось то часу немає, то натхнення...

@@FoxOwlet-IT Будемо сподіватись й тоді чекати ) Наснаги вам!

> Invocation of init method failed Це щось дивне. Якщо проблема в тому, про що я думаю (профілі) - мала б бути інша помилка. > У вас проект висвітлються як Application в настройках, а в мене Spring boot Можна змінити конфігурацію запуску. Але і з спрінг бутовою конфігурацією має працювати, просто треба включити один з профілів, або flowerShop, або fruitShop, аби в контекст всі необхідні біни потрапили. Це можна зробити або параметром командного рядка в стантарній Application конфігурації (як у відео), або в тій же ран конфігурації Spring boot вказати (ну або через мавен чи проперті файл)

Точно, дякую. Забув лінки в опис додати. github.com/FoxOwlet/Spring-demo

Якраз є в найближчих планах Spring Test, MVC та Boot А побажання - так, стараюсь враховувати_)

@@FoxOwlet-IT​ Тоді з нетерепінням чекаємо )

Happy New Year_)

Там ще що планів, що роботи - на пару років такими темпами😅 Але зараз вже в принципі готовий невеличкий інтерпретатор плюс базові конструкції - числа, арифметичні операції, змінні, функції, структури

Ну, туди вже не влізе... А от в окреме відео, разом з відмінностями інтерфейсу і абстрактного класу - можна буде_)

Так, може я це в відео не так подав, але з мого боку білдер вирішує (в перших прикладах) не скільки проблему великої кількості параметрів, скільки того, що в них однакові типи і ми можемо переплутати їх і передати щось "не туди" Якщо в нас, умовно, 10 параметрів, і всі різного типу - в нас такої проблеми немає. І білдер буде скоріше шкідливим. Ми не вирішуємо жодної проблеми, а лише ускладнюємо систему і робимо її більш вразливою до багів (складніше гарантувати, що ми передали всі значення, які треба) Ну і в загальному випадку - білдер вирішує проблему створення складних об'єктів, роблячи цей процес створення "покроковим". Якщо в нас немає ніякої проблеми з цим (або ми її не бачимо) - білдер нам не потрібний Інше питання, що завдяки ломбоку, білдер стає "швидким" і простим рішенням. І його можуть "на автоматі" додати просто аби був

Привіт TL;DR; З точки зору теорії - такий білдер програє за рахунок того, що юзер має бути мутабельним. З точки зору практики - в більшості випадків юзер і так буде мутабельним, тому це не проблема Ну і плюс цей білдер одноразовий, його інстанс не можна безпечно перевикористати Розгорнуто: Ось такий білдер простіший, так. Але є нюанс. Об'єкт, який створюється - потенційно мутабельний. В гіршому випадку в нас буде публічний сеттер (окей, хібернейт і інші фреймворки, які вимагають сеттер - окрема тема). А білдер дозволяє тримати мутабельний стан окремо від об'єкту, який він створює. Відповідно, у нас є гарантія, що після створення об'єкт вже не зміниться. А з іммутабельними об'єктами працювати простіше, вони безпечніші і призводять до меншої кількості проблем, особливо в багатопоточному середовищі. Це можна виправити приватним сеттером (ну або сетити в поле, що практично те саме). Або package-private сеттер. Суть та ж сама, просто потенційно більше класів можуть мати доступ до стану, це якось не по-ООПшному Проблема номер два. Стан об'єкту по суті зберігається в білдері. Якщо використати інстанс цього білдера для створення двох об'єктів... Результат навряд буде очікуваним - старий об'єкт теж зміниться. А це може бути не дуже приємно дебажити. Хороший білдер має або повертати новий об'єкт кожен раз, або бути одноразовим і при другому зверненні кидати ексепшн Але є простий варіант, як позбавити останньої проблеми твій білдер public User build() { User result = that; that = new User(); return result; } Але все ще лишається проблема потенційної мутабельності юзера Сказати, що це проблема - важко, бо, знов таки, хібернейт вміє працювати лише з мутабельними сутностями. Тому хочеш-не хочеш, а публічний сеттер робити доведеться (ну, не беремо до увагі ті унікальні проекти, де джава юзається без спрінга і хібера) Тут (з хібером) такий білдер скоріше має право на життя Білдер, який дублює стан (знов таки, в теорії) безпечніший. А ломбок якраз і "хороший" тим, що приховує це дублювання від нас. А оскільки він код генерує сам, нам не треба синхронізувати наші зміни в двох класах. Тому по суті дублювання є лише в результуючому коді, але не в сорцях. Відповідно, ніяких проблем, які властиві дублюванню коду, це не несе

@@FoxOwlet-ITДякую за таку розгорнуту відповідь, осягнув поки не все але зачерпнув багато. Ще мабуть "вузьке місце" щоб від створення that аж до методу build() цей стан що зберігається в білдері не змінувався де інде(в іншому потоці). Короче все воно добре "звідси аж до.. " потрібно знати де і коли використовувати і коли є своя реалізація можуть бути свої(не очевидні для гугла наприклад) проблеми/виключення. 👍

Ну проблема багатопоточності скоріше для будь-якого білдера буде актуальною, незалежно від реалізації. Але зазвичай білдер між потоками і шарити немає сенсу. Це ж по суті те саме, що намагатися виконання конструктора рознести на декілька потоків, що особливого сенсу не має

@@FoxOwlet-IT доречі, зараз подивився як я там тоді писав, я писав без сеттерів (внутрішній статичний клас бачить приватні поля, коли писав не задумовувався тому і перевірив зараз).

Це добре_) Я відоси в першу чергу і хочу простими і зрозумілими робити. Якщо виходить - вже непогано_)

Так, до SOLIDу теж колись руки дійдуть_)

Уф, про ALT - це прям вогонь, дякую_) А з приводу декомпілятора - якщо це залежність з мавену, (зазвичай) ідея пропонує сорці скачати. Тоді проблема має зникнути В мене з цим постійно схожа проблема - в стектрейсі номер рядка відрізняється завжди через відсутність коментарів Це якщо це про залежності. Якщо саме про внутрішні (inner) класи - я особисто не в курсі

Навряд... Я з ним особливо ніколи не працював, розказувати немає чого_)

Дяка))

Дякую_)

Проксі теж додає якусь нову функціональність. Інакше в ньому не було б сенсу. Тому це не те, що має бути ключовою відмінністю_) А от те, що цей клас "керує" життєвим циклом (кількістю викликів методу) - в принципі важливий і досить суттєвий момент