Что такое JavaBean?

JavaBean - это просто стандарт

1. Все свойства являются частными (используйте методы получения / установки)
2. Общедоступный конструктор без аргументов
3. Реализует Serializable.

Вот и все. Это просто условность. Однако от этого зависит множество библиотек.

Что касается Serializable, из документации API :

Сериализуемость класса обеспечивается классом, реализующим интерфейс java.io.Serializable. Классы, которые не реализуют этот интерфейс, не будут иметь сериализованного или десериализованного состояния. Все подтипы сериализуемого класса сами сериализуемы. Интерфейс сериализации не имеет методов или полей и служит только для определения семантики сериализации.

Другими словами, сериализуемые объекты могут быть записаны в потоки и, следовательно, в файлы, объектные базы данных, что угодно на самом деле.

Кроме того, нет синтаксической разницы между JavaBean и другим классом - класс является JavaBean, если он соответствует стандартам.

Для этого есть термин, потому что стандарт позволяет библиотекам программно делать что-то с экземплярами классов, которые вы определяете предопределенным способом. Например, если библиотека хочет передать любой объект, который вы ей передаете, она знает об этом, потому что ваш объект сериализуем (при условии, что библиотека требует, чтобы ваши объекты были правильными JavaBeans).

Есть термин, при помощи которого это звучит по-особенному. Реальность далеко не такая загадочная.

По сути, Бин:

• является сериализуемым объектом (то есть реализует _1 _, и делает это правильно), что
• имеет свойства, геттеры и сеттеры которых являются просто методами с определенными именами (например, getFoo() - это геттер для свойства Foo), и
• имеет общедоступный конструктор с нулевым аргументом (поэтому он может быть создан по желанию и настроен путем установки его свойств).

Что касается Serializable: это не что иное, как интерфейс маркера (интерфейс, который не объявляет никаких функций), который сообщает Java, что реализующий класс соглашается на (и подразумевает, что он способен) сериализацию - процесс, который преобразует экземпляр в поток байтов. Эти байты могут быть сохранены в файлах, отправлены через сетевое соединение и т. Д. И содержат достаточно информации, чтобы позволить JVM (по крайней мере, той, которая знает о типе объекта) восстановить объект позже - возможно, в другом экземпляре приложение, или даже на совершенно другой машине!

Конечно, для этого класс должен соблюдать определенные ограничения. Главный из них заключается в том, что все поля экземпляра должны быть либо примитивными типами (int, bool и т. Д.), Либо экземплярами некоторого класса, который также сериализуем, либо помечены как transient, чтобы Java не пыталась их включить. (Это, конечно, означает, что transient полей не переживут обход потока. Класс, имеющий transient полей, должен быть готов к их повторной инициализации в случае необходимости.)

Класс, который не может соблюдать эти ограничения, не должен реализовывать Serializable (и, IIRC, компилятор Java даже не разрешит это сделать.)

JavaBeans - это классы Java, которые придерживаются чрезвычайно простого соглашения о кодировании. Все, что вам нужно сделать, это

1. реализовать интерфейс java.io.Serializable - для сохранения состояния объекта
2. использовать общедоступный конструктор пустых аргументов - для создания экземпляра объекта
3. предоставить общедоступные методы получения / установки - для получения и установки значений частных переменных (свойств).

Свойства JavaBeans

JavaBean - это объект Java, удовлетворяющий определенным программным соглашениям:

1. Класс JavaBean должен реализовывать либо Serializable, либо Externalizable

2. Класс JavaBean должен иметь конструктор без аргументов.

3. Все свойства JavaBean должны иметь общедоступные методы установки и получения.

4. Все переменные экземпляра JavaBean должны быть закрытыми

Пример JavaBeans

@Entity
public class Employee implements Serializable{

   @Id
   private int id;
   private String name;   
   private int salary;  

   public Employee() {}

   public Employee(String name, int salary) {
      this.name = name;
      this.salary = salary;
   }
   public int getId() {
      return id;
   }
   public void setId( int id ) {
      this.id = id;
   }
   public String getName() {
      return name;
   }
   public void setName( String name ) {
      this.name = name;
   }
   public int getSalary() {
      return salary;
   }
   public void setSalary( int salary ) {
      this.salary = salary;
   }
}

Пояснение на примере.

1. import java.io.Serializable

Что касается сериализации, см. документацию.

2. частные поля

Поля должны быть закрытыми, чтобы внешние классы не могли легко изменять эти поля. Вместо прямого доступа к этим полям обычно используются методы получения / установки.

3. Конструктор

Открытый конструктор без аргументов.

4. геттер / сеттер

Методы получения и установки для доступа и изменения частных полей.

/** 1. import java.io.Serializable */
public class User implements java.io.Serializable {
    /** 2. private fields */
    private int id;
    private String name;

    /** 3. Constructor */
    public User() {
    }
    public User(int id, String name) {
        this.id = id;
        this.name = name;
    }

    /** 4. getter/setter */
    // getter
    public int getId() {
        return id;
    }
    public String getName() {
        return name;
    }
    // setter
    public void setId(int id) {
        this.id = id;
    }
    public void setName(String name) {
        this.name = name;
    }
}

Java Beans используется для меньшего количества кода и большего количества работы ...

Компоненты Java Beans используются в Java EE в качестве универсального контракта для обнаружения и доступа во время выполнения. Например, JavaServer Pages (JSP) использует Java Beans в качестве объектов передачи данных между страницами или между сервлетами и JSP. Java EE JavaBeans Activation Framework использует Java Beans для интеграции поддержки типов данных MIME в Java EE. API управления Java EE использует JavaBeans в качестве основы для инструментовки ресурсов, которыми нужно управлять в среде Java EE.

О сериализации:

При сериализации объекта объект может быть представлен как последовательность байтов, которая включает данные объекта, а также информацию о типе объекта и типах данных, хранящихся в объекте.

После того, как сериализованный объект был записан в файл, он может быть прочитан из файла и десериализован, то есть информация о типе и байты, которые представляют объект и его данные, могут быть использованы для воссоздания объекта в памяти.

Вы найдете сериализацию полезной при развертывании вашего проекта на нескольких серверах, поскольку bean-компоненты будут сохраняться и передаваться между ними.

JavaBeans является стандартом, и его основные синтаксические требования четко объяснены в других ответах.

Однако, IMO, это больше, чем простой стандарт синтаксиса. Настоящее значение или предполагаемое использование JavaBeans, вместе с различными инструментами, поддерживаемыми в рамках стандарта, заключается в том, чтобы облегчить повторное использование кода и разработку программного обеспечения на основе компонентов, то есть позволить разработчикам создавать приложения путем сборки существующих компонентов (классов) и без необходимости писать какой-либо код. (или просто написать небольшой код клея). К сожалению, эта технология недооценивается и недостаточно используется в отрасли, о чем можно судить по ответам в этой ветке.

Если вы прочитали руководство Oracle по JavaBeans, вы сможете лучше понять в этом.

Просто немного предыстории / обновления концепции фасоли. Во многих других ответах действительно есть «что», но не так много «почему».

Они были изобретены на ранней стадии разработки в Java как часть создания графического интерфейса пользователя. Они следовали шаблонам, которые инструментам было легко разобрать, позволяя им создавать панель свойств, чтобы вы могли редактировать атрибуты Бина. В общем, свойства Bean представляют собой элемент управления на экране (подумайте, x, y, ширина, высота, текст, ..)

Вы также можете думать об этом как о строго типизированной структуре данных.

Со временем они стали полезными для множества инструментов, которые использовали один и тот же тип доступа (например, Hibernate для сохранения структур данных в базе данных).

По мере развития инструментов они больше двигались к аннотациям, а не к разделению имен установщиков / получателей. Теперь большинству систем не требуются компоненты, они могут взять любой простой старый объект Java с аннотированными свойствами, чтобы сообщить им, как ими управлять.

Теперь я рассматриваю beans как аннотированные шары свойств - они действительно полезны только для аннотаций, которые они несут.

Сами по себе бобы не являются здоровым образцом. Они разрушают инкапсуляцию по своей природе, поскольку открывают все свои свойства для внешних манипуляций, и по мере их использования существует тенденция (ни в коем случае не требование) создавать код для внешнего управления компонентом вместо того, чтобы создавать код внутри компонента (нарушает закон. t спрашивать у объекта его значения, просить объект сделать что-нибудь для вас). Использование аннотированных POJO с минимальным количеством геттеров и без сеттеров - это намного больше, чем объектно-ориентированная инкапсуляция, восстанавливающая инкапсуляцию и с возможностью неизменности.

Между прочим, когда все это происходило, кто-то расширил эту концепцию до чего-то под названием Enterprise Java Beans. Это ... разные. и они достаточно сложны, чтобы многие люди чувствовали, что не понимают всей концепции Бина, и перестали использовать этот термин. Я думаю, поэтому вы обычно слышите, что бины называются POJO (поскольку каждый объект Java является POJO, это технически нормально, но когда вы слышите, как кто-то говорит POJO, они чаще всего думают о чем-то, что следует шаблону bean)

Согласно Википедии:

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

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

3. Класс должен быть сериализуемым. (Это позволяет приложениям и фреймворкам надежно сохранять, хранить и восстанавливать состояние компонента независимо от виртуальной машины и платформы.)

Для получения дополнительной информации перейдите по этой ссылке.

Что касается второй части вашего вопроса, сериализация - это механизм сохранения, используемый для хранения объектов в виде последовательности байтов со знаком. Выражаясь менее формально, он хранит состояние объекта, чтобы вы могли получить его позже путем десериализации.

Java Bean - это класс Java (концептуальный), который должен соответствовать следующим соглашениям:

1. У него должен быть конструктор без аргументов.
2. Он должен быть сериализуемым.
3. Он должен предоставлять методы для установки и получения значений свойств, известные как методы получения и установки.

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

Они сериализуемы, имеют конструктор с нулевым аргументом и разрешают доступ к свойствам с помощью методов получения и установки. Название Bean было дано, чтобы охватить этот стандарт, целью которого является создание многократно используемых программных компонентов для Java. Согласно Википедии.

Объекты, составляющие основу вашего приложения и управляемые контейнером IoC Spring, называются бобы. Компонент - это объект, который создается, собирается и иным образом управляется контейнером Spring IoC. В противном случае bean-компонент - это просто один из многих объектов вашего приложения. Согласно Spring IoC.

Java Bean - это любой класс Java, который удовлетворяет следующим трем критериям:

1. Он должен реализовывать сериализуемый интерфейс (интерфейс маркера).
2. Конструктор должен быть общедоступным и не иметь аргументов (то, что другие называют конструктором без аргументов).
3. У него должны быть геттеры и сеттеры.

Следует отметить, что поле serialVersionUID важно для поддержания состояния объекта.

Приведенный ниже код квалифицируется как bean-компонент:

public class DataDog implements java.io.Serializable {

private static final long serialVersionUID = -3774654564564563L;

private int id;
private String nameOfDog;

// The constructor should NOT have arguments
public DataDog () {}


/** 4. getter/setter */

// Getter(s)
public int getId() {
    return id;
}

public String getNameOfDog() {
    return nameOfDog;
}


// Setter(s)
public void setId(int id) {
    this.id = id;
}

public void setNameOfDog(String nameOfDog) {
    this.nameOfDog = nameOfDog;
}}

Компонент - это класс Java с именами методов, которые следуют за Рекомендации JavaBean (также называемые шаблонами проектирования) для свойств, методы и events. Таким образом, любой общедоступный метод класса bean-компонента, который не является частью определения свойства, является методом bean-компонента. Как минимум, Java-класс, даже со свойством в качестве единственного члена (конечно, требуются сопутствующие общедоступные методы получения и установки), общедоступный метод в качестве единственного члена или только один метод регистрации общедоступного прослушивателя событий, является Java-компонентом. Кроме того, свойство может быть либо свойством только для чтения (имеет метод получения, но не сеттером), либо свойством только для записи (имеет только метод установки). Компонент Java должен быть общедоступным классом, чтобы быть видимым для любого инструмента или контейнера beanbox. Контейнер должен быть в состоянии создать его экземпляр; таким образом, у него тоже должен быть общедоступный конструктор. Спецификация JavaBeans не требует наличия компонента публичный конструктор с нулевыми аргументами, явный или по умолчанию, для контейнера, чтобы создать его экземпляр. Если бы вы могли предоставить файл (с расширением .ser), содержащий сериализованный экземпляр, инструмент beanbox мог бы использовать этот файл для создания экземпляра компонента-прототипа. В противном случае компоненту потребуется общедоступный конструктор с нулевым аргументом, явный или используемый по умолчанию.

После создания экземпляра компонента JavaBean API (java.beans. *) Может проанализировать его и вызвать для него методы. Если класс SimpleBeanInfo, реализующий интерфейс BeanInfo или расширяющий реализацию BeanInfo, не доступен, интроспекция включает использование отражения (неявной интроспекции) для изучения методов, поддерживаемых целевым компонентом, а затем применение простых шаблонов проектирования (руководящие принципы) для вывода из те методы, какие свойства, события и общедоступные методы поддерживаются. Если доступен класс, реализующий интерфейс BeanInfo (для компонента Foo он должен называться FooBeanInfo), API обходит неявный интроспекцию и использует общедоступные методы (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) для получения Информация. Если доступен класс, расширяющий SimpleBeanInfo, в зависимости от того, какие из общедоступных методов SimpleBeanInfo (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) переопределяются, он будет использовать эти переопределенные методы для получения информации; для метода, который не переопределяется, по умолчанию используется соответствующая неявная интроспекция. Компонент должен быть создан в любом случае, даже если в нем не выполняется неявная интроспекция. Таким образом, требование общедоступного конструктора zeri-args. Но, конечно, для его распознавания не требуется интерфейс Serializable или Externalizable. Однако в спецификации Java Bean сказано: «Мы также хотели бы, чтобы он был« тривиальным »для общего случая крошечного Bean, который просто хочет сохранить свое внутреннее состояние и не хочет об этом думать». beans должен реализовывать интерфейс Serializable или Externalizable.

В целом спецификация JavaBeans не является точной и быстрой в отношении того, что представляет собой компонент. Написание компонентов JavaBeans на удивление легко. Вам не нужен специальный инструмент и не нужно реализовывать какие-либо интерфейсы. Написание bean-компонентов - это просто вопрос соблюдения определенных соглашений о кодировании. Все, что вам нужно сделать, это сделать ваш класс похожим на bean-компонент - инструменты, использующие bean-компоненты, смогут распознать и использовать ваш bean-компонент. Тривиально, даже следующий класс является Java-компонентом,

public class Trivial implements java.io.Serializable {}

Компоненты, описанные ниже, являются версиями Java EE версии Java SE (JavaBeans), описанной выше. Эти описания дополнительно иллюстрируют основные идеи, изложенные выше.

Весенние бобы

Скажем, у конструктора bean-компонента есть параметры. Предположим, что это простые типы. Контейнер может не знать, какие значения им присвоить; даже если это так, полученный экземпляр не может быть повторно использован. Это может иметь смысл только в том случае, если пользователь может настраивать (указывать значения), например, аннотациями или файлами конфигурации xml, как в Spring beans. И предположим, что некоторые параметры являются типами классов или интерфейсов. Опять же, контейнер может не знать, какие значения ему присвоить. Это может иметь смысл только в том случае, если пользователь может настроить (указать конкретные объекты), скажем, с помощью аннотаций или файлов конфигурации xml. Однако даже в Spring (через файлы конфигурации xml) назначение определенных объектов (со строковыми именами) аргументам конструктора (атрибуту или элементу аргументов конструктора) не является типизированным; это в основном похоже на инъекцию ресурсов. Ссылки на другие bean-компоненты Spring (называемые соавторами; через элемент в элементе аргумента конструктора) в основном являются внедрением зависимостей и, следовательно, безопасны для типов. Очевидно, что у зависимости (компонента-сотрудника) может быть конструктор с введенными параметрами; эти внедренные зависимости могут иметь конструктор с параметрами и так далее. В этом сценарии, в конечном итоге, вам понадобятся некоторые классы bean-компонентов (например, MyBean.class), которые контейнер может создать, просто вызвав новый MyBean (), прежде чем он сможет создать другие взаимодействующие bean-компоненты посредством внедрения зависимостей в конструкторы - таким образом, требование для у beans есть общедоступный конструктор с нулевым аргументом. Предположим, что если контейнер не поддерживает внедрение зависимостей и / или не позволяет назначать значения простого типа конструктору через некоторые аннотации или файлы конфигурации xml, как в Spring, конструкторы bean-компонентов не должны иметь параметров. Даже приложению компонентов Spring потребуются некоторые компоненты, чтобы иметь общедоступный конструктор с нулевым аргументом (например, в сценарии, где ваше приложение Spring не имеет bean-компонента с простыми типами в качестве аргументов конструктора).

Управляемые компоненты JSF

Управляемые компоненты JSF запускаются в веб-контейнере. Их можно настроить либо с помощью аннотации @ManagedBean, либо с помощью файла ресурсов конфигурации приложения managed-bean.xml. Однако он поддерживает инъекцию только через инъекцию ресурсов (не типизированную); не подходит для инъекций в конструкторы. Согласно спецификации JSF управляемые компоненты должны иметь общедоступные конструкторы без аргументов. Далее говорится: «Начиная с версии 2.3 этой спецификации, использование средств управляемого компонента, как указано в этом разделе, настоятельно не рекомендуется. Лучшее и более согласованное интегрированное решение для решения той же проблемы - использование внедрения контекстов и зависимостей (CDI), как указано в JSR-365. Другими словами, будут использоваться управляемые bean-компоненты CDI, которые предлагают безопасную инъекцию зависимостей для конструкторов, подобных Spring beans. Спецификация CDI принимает спецификацию Managed Beans, которая применяется ко всем контейнерам платформы JEE, а не только к веб-уровню. Таким образом, веб-контейнер должен реализовывать спецификацию CDI.

Управляемые компоненты

Вот выдержка из спецификации управляемого компонента «Управляемые компоненты - это объекты, управляемые контейнером с минимальными требованиями, иначе известные под аббревиатурой« POJO »(Обычные старые объекты Java)… их можно рассматривать как расширенную версию платформы Java EE компонентной модели JavaBeans, присутствующей в Java. Платформа SE…. Читатель не упустит из виду, что у Managed Beans есть предшественник в одноименном средстве, найденном в технологии JavaServer Faces (JSF) ... Управляемые Beans, как определено в этой спецификации, представляют собой обобщение тех, что есть в JSF; в частности, Managed Beans можно использовать в любом месте приложения Java EE, а не только в веб-модулях. Например, в базовой модели компонентов управляемые компоненты должны предоставлять конструктор без аргументов, но спецификация, основанная на управляемых компонентах, например CDI (JSR-299), может ослабить это требование и позволить управляемым компонентам предоставлять конструкторам больше сложные сигнатуры, если они следуют некоторым четко определенным правилам ... Управляемый компонент не должен быть: конечным классом, абстрактным классом, нестатическим внутренним классом. Управляемый компонент не может быть сериализуемым, в отличие от обычного компонента JavaBean ». Таким образом, спецификация для управляемых компонентов, также известных как POJO или POJO beans, допускает расширение, как в CDI.

Компоненты CDI

Спецификация CDI переопределяет управляемые bean-компоненты как: при работе в Java EE, Java-класс верхнего уровня является управляемым компонентом, если он отвечает требованиям:

• Это не внутренний класс. • Это не абстрактный класс или аннотируется @Decorator. • Он не реализует javax.enterprise.inject.spi.Extension. • Он не аннотирован @Vetoed или в пакете с аннотацией @Vetoed. • У него есть соответствующий конструктор: либо у класса есть конструктор без параметров, либо класс объявляет конструктор с аннотацией @Inject.

Все классы Java, отвечающие этим условиям, являются управляемыми компонентами, поэтому для определения управляемого компонента не требуется специального объявления. Или

если он определен как управляемый компонент в любой другой спецификации Java EE и если

• Он не аннотирован аннотацией, определяющей компонент EJB, и не объявлен как класс EJB-компонента в ejb-jar.xml.

В отличие от bean-компонентов Spring, он не поддерживает конструкторы с простыми типами, что могло бы быть возможно, если бы он поддерживал конфигурацию с файлами конфигурации xml, например Spring, или любыми аннотациями.

EJB-компоненты

EJB запускаются в контейнере EJB. Его спецификация гласит: «Компонент сеансового компонента - это управляемый компонент. «Класс должен иметь открытый конструктор, который не принимает аргументов», - говорится в нем как для сессионного компонента, так и для компонента, управляемого сообщениями. Кроме того, в нем говорится: «Класс сеансового компонента не требуется для реализации интерфейса SessionBean или интерфейса Serializable». По той же причине, что и компоненты JSF, что внедрение зависимостей EJB3 в основном является инъекцией ресурсов, компоненты JSF не поддерживают конструкторы с аргументами, то есть посредством внедрения зависимостей. Однако, если контейнер EJB реализует CDI, «Необязательно: класс может иметь дополнительный конструктор, аннотированный аннотацией Inject», это говорит как для сессионного компонента, так и для компонента, управляемого сообщениями, потому что «EJB упакован в архив bean-компонента CDI, а не аннотированный аннотацией javax.enterprise.inject.Vetoed, считается компонентом с поддержкой CDI ».

Чтобы понять JavaBean, вам нужно заметить следующее:

JavaBean концептуален и не может представлять класс конкретных вещей.

JavaBean - это инструмент разработки, который можно визуализировать в работе многократно используемых программных компонентов.

JavaBean основан на спецификации Sun JavaBeans и может быть компонентами многократного использования. Его самая большая особенность - возможность повторного использования.

POJO (простой старый объект Java): POJO - это обычные объекты Java без каких-либо ограничений, кроме тех навязанный языком Java.

Сериализация: используется для сохранения состояния объекта и отправки его по сети. Он преобразует состояние объекта в поток байтов. Мы можем воссоздать объект Java из байтового потока с помощью процесса, называемого десериализацией.

Сделайте так, чтобы ваш класс реализовал интерфейс java.io.Serializable. И используйте метод writeObject () класса ObjectOutputStream для достижения сериализации.

Класс JavaBean: это специальный объект POJO, имеющий некоторые ограничения (или соглашения).

1. Реализовать сериализацию
2. Иметь общедоступный конструктор без аргументов
3. Все свойства являются частными с общедоступными методами получения и установки.

Многие фреймворки, например Spring, используют объекты JavaBean.

Если вы знакомы с C / Golang, вы никогда не слышали C bean или Go bean, потому что у них есть ключевое слово struct, позволяющее разработчикам легко определять типы структур без написания сложных ключевых слов ООП.

type User struct {
  Name string
  Age int
}

var user User

user.Name = "name"
user.Age = 18

var bytes, err = json.Marshal(user)

Ошибка Java в том, что нехватка struct типов, и разработчики находят эту нехватку серьезной.

Затем был изобретен Java Bean как еще одно скучное правило, позволяющее class притворяться struct, чтобы ваш редактор или компилятор не плакал и не кричал о вашем небезопасном доступе к членам класса.

На практике Beans - это просто объекты, которые удобно использовать. Сериализация их означает возможность легко сохранять их (хранить в форме, которая легко восстанавливается).

Типичное использование фасоли в реальном мире:

• простые многоразовые объекты POJO (простые старые объекты Java)
• визуальные объекты
• Spring использует Beans для обработки объектов (например, объект User, который необходимо сериализовать в сеансе)
• EJB (Enterprise Java Beans), более сложные объекты, такие как JSF Beans (JSF - старая, довольно устаревшая технология) или JSP Beans

Фактически, Beans - это просто соглашение / стандарт, ожидающий от объекта Java чего-то, что он будет вести себя (сериализация), и дать некоторые способы его изменения (установщики свойств) определенным образом.

Как их использовать, это только ваше изобретение, но наиболее распространенные случаи я перечислил выше.

Java Bean - это компонент или базовый строительный блок в архитектуре JavaBeans. Архитектура JavaBeans - это компонентная архитектура, которая выигрывает от возможности повторного использования и взаимодействия компонентного подхода.

Допустимая архитектура компонентов должна позволять собирать программы из стандартных блоков программного обеспечения (в данном случае Beans), возможно, предоставляемых разными поставщиками, а также позволять архитектору / разработчику выбирать компонент (Bean), понимать его возможности и включать это в приложение.

Поскольку классы / объекты являются основными строительными блоками языка ООП, такого как Java, они естественным образом претендуют на роль Bean в архитектуре JavaBeans.

Процесс преобразования простого Java-класса в Java-компонент на самом деле является не чем иным, как превращением его в повторно используемый и совместимый компонент. Это приведет к тому, что класс Java будет иметь такие возможности, как:

1. управление свойствами, событиями и методами класса, доступными другому приложению. (У вас может быть класс BeanInfo, который сообщает только о тех свойствах, событиях и методах, которые необходимы внешнему приложению.)
2. постоянство (быть сериализуемым или извлекаемым - это также подразумевает наличие конструкторов без аргументов, использующих переходные процессы для полей)
3. возможность регистрироваться для событий, а также генерировать события (например, с использованием связанных свойств и ограничений)
4. настройщики (для настройки Bean через графический интерфейс или путем предоставления документации)

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

Почти все ведущие фреймворки и библиотеки в Java неявно придерживаются архитектуры JavaBeans, чтобы воспользоваться вышеуказанными преимуществами.

Аннотация Spring @Bean указывает, что метод создает компонент, которым управляет контейнер Spring.

Дополнительная ссылка: https://www.concretepage.com/spring-5/spring-bean-annotation

Выше 6 или 7 раз повторялось, что для JavaBeans требуется конструктор без аргументов.

Это НЕПРАВИЛЬНО, такого требования нет, особенно в контексте Java Spring.

Также нет упоминания об этом требовании в версии (1.01) спецификации, которая описывает API JavaBeanns (https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/). Более того, в этой спецификации «нулевой конструктор» упоминается только 2 раза в следующих контекстах: Каждый настройщик должен иметь нулевой конструктор. Каждый PropertyEditor должен иметь нулевой конструктор.

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

Бины. Объекты, составляющие основу вашего приложения и управляемые контейнером Spring IoC, называются бинами. Компонент - это объект, который создается, собирается и иным образом управляется контейнером Spring IoC. Эти bean-компоненты создаются с использованием метаданных конфигурации, которые вы передаете контейнеру.