Ну, думаю є переваги в:
1) Така модель набагато легше підлягає розширенню/зміни логіки.
2) Якщо серед всієї моделі даних один клас — складний і з методами, а інший — простий і з публічними змінними, втрачається одноманітність, користуватись буде важко.
А якщо проект закінчений, в ньому вся модель даних така та на рівні бізнес логіки в трирівневій архітектурі просто прокидуються дані на наступний рівень — ну то це просто схоже на використання болгарки для нарізання сирів.
В першому випадку ви змінюєте стан об’єкта через методи (інтерфейс), а самі дані інкапсульовані всередині об’єкта та є недоступними зовні. В коді який ви привели це виглядає непотрібним і незрозумілим, бо логіка цього об’єкту є дуже простою. А якщо Ви захочете перевіряти ім’я на null, або вік на <1? Або якщо Ви якось захочете модфікувати логіку в классі-насліднику? Використовуючи інкапсуляцію Ви миттєво зможете досягти бажаного, при цьому зберігши безпечність використання классу (Ви знатимете, що Ваш об’єкт міг змінитись через даний список методів), а виставляючи зовні змінні класу просто робите класс небезпечним для використання.
В туторіалах ми це бачимо, бо в туторілах зазвичай не реалізується складна логіка. Навпаки, такі приклади є об’єктами-заглушками для демонстрації всіляких спрінгів і інших комбайнів.
Не хотілось би показувати зверхність, та можливо варто почитати про ООП та місцями книжки Блоха, якщо є такі запитання.
Відповідно, якщо маєте чим заперечити — хочеться дізнатись чим:)
1) Якщо у тебе з’явиться додаткова логіка на сет/гет (наприклад, ти для кожного імені в своєму User’і захочеш приписувати ’Sir_’), а у тебе всюди просто публічні змінні. «І шо тоді робить?»
2. ? Якщо тобі в одному класі пакету писати все в змінні, а в іншому юзати методи — норм, то я цього зрозуміти поки не можу, давай агрументацію більше ніж з 1го слова.
3. en.wikipedia.org/...e#Three-tier_architecture