Зачем нам нужен конструктор без аргументов по умолчанию в Java?

Зачем нам нужен конструктор без аргументов по умолчанию во многих связанных с Java API? Как правило, все классы java bean-компонентов или классы сущностей (JPA и т. д.) или классы реализации JAX-WS требуют явного конструктора без аргументов.

Если по умолчанию Java предоставляет конструктор без аргументов, то почему большинство этих стандартов требуют явного конструктора?


java constructor default-constructor
person RRR_J    schedule 20.06.2010    source источник

Ответы (6)


arrow_upward
20
arrow_downward

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

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

Некоторые платформы могут поддерживать @ConstructorProperties в качестве альтернативы. .

person OrangeDog    schedule 20.12.2010

arrow_upward
11
arrow_downward

Я считаю, что фреймворки, которые требуют public nullary конструкторов, делают это, потому что они используют отражение для создания экземпляров типов, например. через Class.newInstance().

О том, почему конструктор default может не работать в этом случае, читайте в соответствующем разделе JLS:

Конструктор JLS 8.8.9 по умолчанию

Если class не содержит объявлений конструктора, автоматически предоставляется конструктор по умолчанию, который не принимает никаких параметров:

  • если class объявлен как public, то конструктору по умолчанию неявно присваивается модификатор доступа public;
  • если класс объявлен protected, то конструктору по умолчанию неявно присваивается модификатор доступа protected;
  • если класс объявлен private, то конструктору по умолчанию неявно присваивается модификатор доступа private;
  • в противном случае конструктор по умолчанию имеет доступ по умолчанию, подразумеваемый отсутствием модификатора доступа.

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

person polygenelubricants    schedule 20.06.2010
comment
Видимость не является проблемой, так как ее можно обойти с помощью API отражения. - person OrangeDog; 21.12.2012
comment
а как насчет вызова super() в конструкторе по умолчанию, играет ли он здесь роль? - person Macilias; 11.08.2015

arrow_upward
4
arrow_downward

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

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

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

person Peter Lawrey    schedule 20.06.2010

arrow_upward
3
arrow_downward

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

Стоит отметить, что это выбор дизайна разработчиком конкретной библиотеки, можно построить API/Framework, который может экстернализовать и воссоздавать объекты, которые не имеют конструктора без аргументов (определение отдельного фабричного класса является один подход). Шаблон требования конструктора без аргументов впервые появился в сериализации Java (я думаю) и был принят как стандартный подход де-факто в других библиотеках (например, JPA). Слабость этого подхода в том, что он не позволяет использовать неизменяемые объекты.

person Michael Barker    schedule 20.06.2010
comment
XStream, например, может сериализовать объекты в XML и не требует конструктора без аргументов. - person Mario Ortegón; 20.06.2010

arrow_upward
0
arrow_downward

Две причины: 1) чтобы избежать исключения NullPointerException, если поле данных экземпляра ссылочного типа данных не инициализировано. Предоставление явного конструктора даст вам возможность инициализировать такие поля данных, если они не были инициализированы при объявлении 2) для пользователей, которые хотели бы использовать конструкторы без аргументов; они не предоставляются автоматически, если существуют другие конструкторы

person Nana    schedule 14.01.2014

arrow_upward
0
arrow_downward

Многие из этих фреймворков основаны на более ранних идеях "POJO" и особенно JavaBeans. Наименьший полезный Java-объект по соглашению будет иметь конструктор без аргументов и каждый член, доступный через такие методы, как get/setProperty1 и is/setProperty1 для логических значений. Если классы следуют этому соглашению об интерфейсе, инструменты и фреймворки, использующие отражение, могут работать «из коробки».

person Axel Podehl    schedule 28.03.2019