Более точно ниже пример может помочь вам понять, поэтому у меня есть один сотрудник Employee, и у него есть отношения с квалификацией и адресом, а bean доступны внутри объявления xml.
<bean id="qualification" class="com.Autowiring.constructor.Qualification">
<property name="highestQualification" value="BTech"/>
<property name="certifcations" value="SCJP"/>
</bean>
<bean name="address" class="com.Autowiring.constructor.Address">
<property name="city" value="Bangalore" />
<property name="zip" value="560054" />
<property name="building" value="Building One" />
</bean>
У нас есть 4 Конструкторы 1-й взять два аргумента, т.е. адреса и квалификации и второй принимает квалификации и третий конструктор принимает адрес, а затем четвёртую один берет на себя все поля, начиная от ид, имя, DOB, адрес и квалификацию.
// Конструктор - 1
public Employee(Address address, Qualification qualification) {
super();
System.out.println(1);
this.address = address;
this.qualification = qualification;
}
// Конструктор - 2
public Employee(Qualification qualification) {
super();
System.out.println(2);
this.qualification = qualification;
}
// Конструктор - 3
public Employee(Address address) {
super();
System.out.println(3);
this.address = address;
}
// Конструктор - 4
public Employee(int id, String name, Date dob, Address address,
Qualification qualification) {
super();
System.out.println(4);
this.id = id;
this.name = name;
this.dob = dob;
this.address = address;
this.qualification = qualification;
}
Case-1: Предположим, что конструктор 1 и 4 не объявлен, и у нас нет конструктора-arg в объявлениях компонента-компонента.
Поведение: конструктор 3 будет называться как это последний конструктор заявил, если мы изменим порядок определения Конструкторы т.е. поменять положение конструктора 2 с 3.
Case-2: Давайте предположим, что конструктор 4 не объявлен, и у нас нет конструктора-arg в объявлениях компонента-компонента.
Поведение: В этом случае конструктор 1 будет называться, как он может получить тип квалификацию и адрес, доступный в декларациях боба, так что это удовлетворяет условие для аргументов соответствия для конструктора 1.
Случай-3: Предположим, у нас нет конструктора-arg в объявлениях компонента-сотрудника.
Поведение: В этом случае также конструктор 1 будет называться, как он может получить тип квалификацию и адрес, доступный в декларациях боба, так что это удовлетворяет условие для аргументов соответствия для конструкторы 1, но это не будет способный вызвать 4-й конструктор, поскольку id, name и dob недоступны в файле объявления bean, поэтому первый конструктор является лучшим конструктором соответствия, так как мы имеем квалификацию и адрес, доступные в объявлении bean.
Case-4: Предположим, что у нас есть конструктор-arg в объявлениях bean-компонентов, и все конструкторы доступны.
Поведение: Он будет в состоянии назвать 4-й конструктора как идентификатор, имя, DOB, квалификация и адрес доступен в файле декларация боба, поэтому первый 3 аргумента будет поступать из конструктора арг и последние двух будет исходить от объявление самого компонента, поэтому будет вызываться все аргументы из 4-го конструктора, соответствующего, следовательно, 4-го конструктора. Заключение. Таким образом, случаи и поведение показывают, что в случае нескольких конструкторов весенний контейнер пытается проверить все зависимые свойства и проверять на основе всего доступного свойства, которое среди конструкторов можно использовать для создания объекта, где максимально возможные свойства могут быть инициализированы.
Почему он не должен знать, какой конструктор нужно назвать. Он определяет типы ввода, основанные на доступных конструкторах, выполняет проверку в контексте, какой конструктор может быть удовлетворен в лучшем случае и выполняет его. –
Тогда почему не был создан конструктор с 3 аргументами? –
Есть ли в наличии bean-тип 'SpellChecker2'? Без полной картины трудно сказать. –