Java Beans: преувеличенные ассоциативные массивы?

На самом деле, да, волшебство происходит.

Это действительно тупой шаблон, но GUI bean-компоненты (которыми являются все компоненты) предназначались для рефлексивного анализа разработчиком GUI. Общедоступные поля set/get предназначены для использования в качестве «свойств», с которыми пользователь может работать при создании своего графического интерфейса.

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

Этот паттерн использовался и в других местах, и, как вы заметили, он очень похож на публичные поля. Я думаю, что это один из худших шаблонов, созданных солнцем при настройке java, но других очевидных решений не было (я думаю, что вся концепция была как бы придумана первыми людьми, пытавшимися создать первые сборщики графического интерфейса до выпуска java).

Теперь есть гораздо лучшее решение: используя аннотации для пометки закрытых полей, отражающий инструмент все еще может анализировать их и привязывать к элементам управления конструктора. Это было бы намного чище и не делало бы все ваши объекты настолько уязвимыми для внешних изменений состояния.

Как вы заметили, Java Beans - это довольно тривиальное соглашение о кодировании.

Полезная часть заключается в том, что они вообще были условностью. Это позволило создавать вспомогательные инструменты, основанные на (на тот момент) новых идеях, таких как указание точного имени геттеров и сеттеров и ожидание того, что определенные методы будут существовать без необходимости приписывать интерфейсу. Это обеспечивало достаточную гибкость, чтобы делать все, что вы хотели, но все же позволяло использовать графический интерфейс для сборки bean-компонентов.

На данный момент, когда полный самоанализ является нормой, другие языки имеют формализованную функциональность get/set и многие другие способы делать то, что делают Beans, я думаю, что это идея, время которой прошло.

Без сомнения, люди злоупотребляют глупыми геттерами/сеттерами.

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

Помните одно из основных правил объектно-ориентированного дизайна «Код для интерфейса, а не для реализации». Доступ к общедоступным полям класса, безусловно, относится ко второму варианту и значительно усложняет рефакторинг кода.

Вы не упускаете суть. Геттеры/сеттеры уродливы, но встроены во многие инструменты, которые делают предположения об именах классов/методов/полей (например, spring), что (помимо их очевидной ценности для инкапсуляции) они фактически стали почти обязательным требованием, если только вы не работает в очень ограниченном и частном контексте.

«Геттеры» и «сеттеры» отлично подходят, если вы хотите переопределить доступ к своим данным, например, для ведения журнала/безопасности или возврата значения, отличного от исходного класса.

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

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

     this.foo = foo;
}

с публичными членами вы не можете этого сделать. Во-вторых, в сеттере вы можете запускать события, которые могут прослушивать другие компоненты. И последнее, но не менее важное: вы можете обеспечить правильную проверку типов (как вы указали в своем вопросе).