Java Beans: Превъзхвалявани асоциативни масиви?

Всъщност, да, случва се магия.

Това е наистина тъп модел, но GUI bean-овете (каквито са всички компоненти) са предназначени да бъдат рефлективно анализирани от GUI builder. Публичните полета за задаване/получаване са предназначени да бъдат „Свойства“, с които потребителят може да се занимава, докато изгражда своя GUI.

Редактиране: В защита на слънцето трябва да кажа, че въпреки че моделът се оказа доста неприятен поради всички хора, които го копираха и започнаха да го използват в целия си не-bean код, той позволи на хората да интегрират класове с GUI builder без използване на външни метаданни. Нямате нужда от XML файл или файл със свойства за редактора, беше толкова лесно, колкото да разширите Button и да пуснете новия си обект върху палета.

Този модел е използван на други места и, както забелязахте, той е почти същият като да имате публични полета. Мисля, че това е един от най-лошите шаблони, създадени от слънцето при настройване на java, но нямаше други очевидни решения (мисля, че цялата концепция беше някак подхваната от първите хора, които се опитваха да създадат първите GUI builders преди пускането на java).

Сега има много по-добро решение: използвайки анотации за маркиране на частни полета, рефлективният инструмент все още може да ги анализира и да ги обвърже с контролите на компилатора. Това би било много по-чисто и няма да направи всичките ви обекти толкова уязвими към външни промени в състоянието.

Java Beans са, както посочвате, доста тривиална конвенция за кодиране.

Полезното е, че те изобщо бяха конвенция. Това позволи да се изградят спомагателни инструменти, които се основаваха на (по това време) нови идеи като уточняване на точното име на гетерите и сетерите и очакване, че специфични методи ще съществуват, без да е необходимо да се приписват на интерфейс. Това позволи достатъчно гъвкавост, за да правите каквото искате, но все пак ви позволи да използвате GUI за сглобяване на бобчета.

На този етап, тъй като пълната интроспекция е норма, а други езици имат формализирана функция за получаване/задаване и много други начини да правят това, което правят Beans, мисля, че те са идея, чието време е минало.

Хората използват прекомерно глупави гетери/сетери, без съмнение в това.

Представете си обаче колко болка трябва да преживеете 2 години по-късно, когато разберете, че трябва да премахнете интервали от низа във вашия setEmail(string email); метод и целият ви код е трудно свързан, за да използва публични полета вместо извикване на метод.

Запомнете едно от основните правила на обектно-ориентирания дизайн „Код към интерфейс, а не реализация“. Достъпът до публични полета на клас със сигурност е последният и ще направи преработването на кода много по-трудно.

Не пропускаш смисъла. Getters/Setters са грозни, но са вградени в толкова много инструменти, които правят предположения за имена на класове/методи/полета (напр. spring), че (освен очевидната им стойност за капсулиране) те на практика са се превърнали в почти изискване, освен ако не сте работа в много ограничен и частен контекст.

'getters' и 'setter' са страхотни, ако искате да замените достъпа до вашите данни, например за регистриране/сигурност или връщане на стойност, различна от оригиналния клас.

без сетер не можете да проверите за инварианти:

public void setFoo(Foo foo) { 
     if (foo == null) {
          throw new InvalidFoo();
     }

     this.foo = foo;
}

с публични членове не можете да направите това. Втора точка, в рамките на сетер можете да задействате събития, които други зърна могат да слушат. Не на последно място, можете да наложите правилна проверка на типа (както посочихте във вашия въпрос).