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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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