Чому методи аксесуара із специфікації JavaBean стали еталоном для розробки Java?

JavaBeans Специфікація описує як JavaBean

Java Bean - це програмний компонент для багаторазового використання, яким можна візуально маніпулювати інструментом для збирання

Оскільки більшість написаних рядків коду, схоже, не мають нічого спільного з візуальним маніпулюванням у інструменті для побудови, чому саме специфікація JavaBean стала "способом" написання об'єктно-орієнтованого коду?

Я хотів би відмовитись від традиційного геттера / сеттера на користь плавних інтерфейсів у всьому коді, не тільки у будівельників, але бояться це робити, оскільки це традиційно не так, як на Java записується об'єктно-орієнтований код.

Доступ до стилів JavaBean виявився хорошим співвідношенням для всіх видів сценаріїв, схожих на оригінальний сценарій "інструмент для побудови" в одному з основних моментів: компоненти передаються навколо та маніпулюються загальними контейнерами та інструментами, а також кодом програми. На сервері додатків у вас є сервісні компоненти, до яких контейнер EJB або Spring додає транзакції та ін'єкції залежностей, стійкі моделі доменів, до яких ORM додає ледаче виявлення завантаження та зміни, і які можна серіалізувати в XML бібліотекою без конкретного коду.

Доступники надають загальний API, який дуже гнучкий у використанні компонента - він не забороняє порядок операцій. Кожен виклик доступу не залежить від інших, і всі вони відповідають одній схемі, тому ви можете легко додати загальні шари, що додають функціональність, не порушуючи призначений шаблон використання.

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

Тож JavaBeans та вільні інтерфейси мають переваги в різних сценаріях, і який вам слід використовувати. І ви могли навіть поєднати обидва.

Отже, оскільки специфікація JavaBeans, яку ви посилаєте, визначає конвенцію для доступу до властивостей, люди вирішили скористатися конвенцією і побудували навколо неї рамки. Деякі з цих рамок, такі як сплячка, були досить корисними і стали дуже популярними. Отже, оскільки люди використовували рамки, засновані на специфікації JavaBeans, javaBeans ставав дедалі більше всюдисущим, і навколо них створювались все нові й нові рамки.

Вільні інтерфейси - відмінна ідея, але чи добре вони грають із Spring або Struts 2? Биє мене.